1. What is Bonjour?

Bonjour, also known as zero-configuration networking, enables automatic discovery of computers, devices, and services on IP networks. Bonjour uses industry standard IP protocols to allow devices to automatically discover each other without the need to enter IP addresses or configure DNS servers. Specifically, Bonjour enables automatic IP address assignment without a DHCP server, name to address translation without a DNS server, and service discovery without a directory server. Bonjour is an open protocol which Apple has submitted to the IETF as part of the ongoing standards-creation process. To learn more, check out the Bonjour Protocol Specifications which detail the technologies that make up Link-Local and Wide-Area Bonjour.

2. What is mDNSResponder?

mDNSResponder is a Bonjour system service that implements Multicast DNS Service Discovery for discovery of services on the local network, and Unicast DNS Service Discovery for discovery of services anywhere in the world. mDNSResponder is built into OS X and iOS and can be downloaded as part of Bonjour for Windows. Applications like iTunes, iPhoto, Messages and Safari use mDNSResponder to implement zero-configuration network music sharing, photo sharing, chatting and file sharing, and discovery of remote user interfaces for hardware devices like printers and web cameras. mDNSResponder is also used to discover and print to Bonjour printers and USB printers connected to the AirPort Extreme and Express base stations. mDNSResponder is open source, and hardware device manufacturers are encouraged to embed the mDNSResponder source code directly into their products to benefit from zero-configuration networking.

3. Does Bonjour work between multiple subnets?

Yes. The first release of DNS Service Discovery (DNS-SD) for OS X concentrated on Multicast DNS (mDNS) for single-link networks because this was the environment worst served by IP software. Bonjour uses Dynamic DNS Update (RFC 2316) and unicast DNS queries to enable wide-area service discovery.

4. When I disconnect a device from a network, does it remain visible?

Yes, for a while. Eventually, the DNS record reaches its time-to-live interval and disappears. As an app developer, if you connect to a host using Bonjour and the connection fails, you can ask the Bonjour to reconfirm the record. This process is described further in NSNetServices and CFNetServices Programming Guide.

5. What do I have to do to support Bonjour over Bluetooth in iOS?

In iOS 5 and later, apps must explicitly opt in to doing service discovery over Bluetooth, and must resolve services using the low-level DNS Service Discovery C API. For more information, see Bonjour over Bluetooth on iOS 5 and Later.

6. How long should I leave service browsers running?

Browsers consume resources, so you should not keep them running if you don’t expect to ever use the data. However, keeping a service browser running while connecting to a service is generally a good idea. If that connection fails, the presence of a running browser encourages Bonjour to more aggressively revalidate potentially stale service entries, which can make the list of services more accurate.

As a rule, if you are not showing any user interface elements that contain the list, and if you are not actively connecting to any service, you should probably stop the browser. However, this is just a general recommendation; in all cases, you should do whatever results in the best experience for your users.

7. Does Bonjour support "SOAP" RPC over HTTP?

Yes. Bonjour defines a new protocol for discovering services (DNS-SD), however, it places no restrictions on the type of services you discover. Thus you can discover SOAP services just as easily as you can discover Messages buddies and iTunes music libraries. In other words, Bonjour supports SOAP over HTTP as well as every other application protocol layered on top of TCP/IP or UDP/IP.

8. Does Bonjour have any kind of subscription or notification mechanism?

Yes. The reason that many people seem to be unaware that Bonjour also does notification is probably because it is simply an intrinsic property of the discovery protocol. With a well-designed discovery protocol, the same protocol that you use to discover some piece of information is also used to discover changes to that information. Discovery of static information, and discovery of variable information, and discovering when variable information changes are all just different points on the same spectrum. For an example of an application using Bonjour "notifications", check out Messages. When you change your Status from "Available" to "Away" or type in a status message, all other Messages clients on the local network are notified of the change.

This technique is described further in NSNetServices and CFNetServices Programming Guide.

9. What should I pass in for the "name" parameter when registering a service?

By default, you should choose a human-readable name that uniquely describes the service. iTunes, for example, chooses a default music sharing name by combining the computer user's first and last name, as in "Isaac Newton's Music". For most hardware devices, the default service name should be the full make and model of the product. For example, something like "Apple MacBook Pro". Remember, this is only the default name given out of the box, and the user should be allowed to customize the service name to differentiate multiple devices or services on the network.

For OS X application developers that are registering services, it may make sense to have one instance of that service on a given computer (as opposed to one per instance of an application that may be running in multiple accounts). In that case, rather than having your application present its own user-interface for the user to enter the name of the advertised service, it's more convenient to register using the system-provided default name known as the "Computer Name" in the Sharing Preference Panel. If you pass in an empty string ("") for the service name when registering, the system will automatically use the "Computer Name". Passing in an empty string will also handle name conflicts by automatically appending a digit to the end of the name.

However, there are services where multiple instances may be hosted on the same computer. For example, a print server with three printers should advertise each printer as a first-class entity. Each printer should be advertised using a descriptive name that usefully identifies the printer itself. This is important, because the printer called "Marketing's Transparency Printer" might get moved to a different print server in the future, but the user shouldn't have to be aware of those operational details. They should still see the same service advertised on the network under the same name, even though it's on a different print server now.

10. What should I pass in for the "type" parameter when registering a service?

You must pass a string of the form "_applicationprotocol._transportprotocol". Currently "_transportprotocol" must be either "_tcp" or "_udp". Your "applicationprotocol" must be 15 characters or less and should be registered with with IANA so they can add you to the list of registered protocol names and port numbers. Please see QA1312 for the list of service types used by OS X.

11. What should I pass in for the "domain" parameter when registering a service?

If you pass an empty string (""), then your service is registered using link-local multicast and in a user-chosen unicast DNS domain as well, if applicable.

If you pass in "local", then your service is registered only using link-local multicast, and not in any user-chosen unicast DNS domains.

Except for the "local" domain, you only need to pass a specific string if you have some particular reason to want to register your service in a specific remote domain.

12. What should happen when two devices on the network both use the same service name?

In the rare case where a name collision occurs, your device should add a digit to the end of the name, for example:

"Apple Mac mini (2)"

Applications and devices that call Bonjour APIs like DNSServiceRegister and CFNetServiceRegisterWithOptions will automatically get this name changing behavior when name conflicts occur. For devices that have a screen and are capable of user input, instead of appending a number, you could optionally decide to prompt the user for a more unique name.

13. What is the TXT record used for?

The specific nature of the TXT record and how it is to be used is service type dependent. Each service type will define zero or more name/value pairs used to store meta-data about each service. These name/value pairs should be formatted as described in Section 6 of DNS-Based Service Discovery. Please see QA1306 for information on how TXT records should be formatted when using the OS X and iOS APIs. Also, the DNS-SD Web Site has information regarding the currently defined name/value pairs for common service types.

14. After the user browses the network in my application and selects the service instance they wish to use, I should save that IP address in my application's preference file, right?

Wrong. This is a common mistake. With DHCP (and with link-local addressing) it is not safe to assume that the service instance will have the same IP address tomorrow. Addresses can change. Service names are the intended stable identifiers for a service instance. Save the instance name (name, type, and domain) in your application's preference file, then resolve it on demand each time the user accesses the service. Note also that you should not store the host name and port number, because you shouldn't assume that the service instance will necessarily be running on the same port number tomorrow. Instead of storing the host name, store the service instance name (name, type, and domain) and then when you resolve the service instance name at the time of use you are sure to get the up-to-date IP address and port number.

15. My hardware device has a built-in web server used for configuration. Should I register it using Bonjour?

Yes. You should register every service running on your device, for example, HTTP, FTP, SSH, Telnet. On OS X, the Safari web browser can discover web servers advertised with Bonjour, and Internet Explorer on Windows can discover web servers when Bonjour for Windows is installed. Also, the Terminal application in OS X can discover FTP, SSH, and Telnet servers.