Domain Naming Conventions

Bonjour names for service instances and service types are related to Domain Name System (DNS) domain names. This section explains DNS domain names, the Bonjour local “domain,” and the naming rules for Bonjour service instances and service types.

Domain Names and DNS

DNS uses a specific-to-general naming scheme for domain names. The most general domain is . (“dot”), called the root domain, which is akin to the root directory / in a UNIX file system. Every other domain falls in a hierarchy below the root domain. For example, the name www.apple.com. is within the second-level domainapple.com., which is within the top-level domaincom., which in turn is part of . (“dot”), the root domain. Figure 1 shows an abridged version of this hierarchy.

Figure 1 Part of the Internet Domain Name System, augmented for Bonjour

At the top of the inverted tree is the root domain. Below it are some of the top-level domains: com., edu., and org., and the local Bonjour “domain” local., discussed further in “Bonjour and the Local Link.” Below the top level are a few second-level domains, apple, darwin, and zeroconf. The tree can extend infinitely downward with, for example, www, at the third level.

You may have noticed that the trailing dot is left off of most domain names. The trailing dot does, however, have meaning. A domain name ending in a trailing dot, such as www.apple.com., is known as a fully qualified domain name, much like an absolute path (such as /usr/bin) in a UNIX file system.

If you type wibble.apple.com into your Web browser (without the trailing dot), the system will treat it as an unqualified (partial) name and append the names from your list of search domains, such as apple.com., earthlink.net., myschool.edu., etc. The system will first try to append . (“dot,” the root domain), but if the name wibble.apple.com. doesn’t exist, it will continue down the list and try wibble.apple.com.apple.com., wibble.apple.com.earthlink.net., wibble.apple.com.myschool.edu., and so on, which is almost certainly not what you wanted.

Bonjour and the Local Link

Bonjour protocols deal in large part with the part of the network called the local link. A host’s local link, or link-local network, includes itself and all other hosts that can exchange packets without IP header data being modified. In practice, this includes all hosts not separated by a router.

On Bonjour systems, local. is used to indicate a name that should be looked up using an IP multicast query on the local IP network.

Note that local. is not really a domain. You can think of local. as a pseudo-domain. It differs from conventional DNS domains in a fundamental way: names within other domains are globally unique; link-local domain names are not. There is only one logical DNS entry in the world named www.apple.com., and because of the way DNS works, there can be only one. Host names ending in local., on the other hand, are managed by a collection of Multicast DNS responders on the local network, so the naming scope is just that: local. There can easily be two hosts named meow.local. in the world, or even the same building, just not on the same local network.

Globally unique names are important and useful—in fact, they are one of the significant achievements of the Internet—but they require a certain level of administrative effort to set up and maintain. Local names are useful only on the local network, but in cases where that is adequate, they provide a way to refer to network devices using names instead of IP numbers, and of course they require less effort and expense to coordinate than globally unique names.

Locally unique names are particularly useful on networks that have no connection to the global Internet, either by design or because of interruption, and on small, temporary networks, such as a pair of computers linked by a crossover cable, or a few people playing network games using laptops on the wireless network of a home or cafe.

If a name collision on the local network occurs, a Bonjour host finds a new name automatically (in the case of a device without a screen) or by asking the user (in the case of a personal computer).

Bonjour Names for Existing Service Types

Bonjour services are named according to the existing Internet standard for IP services. The website http://www.dns-sd.org keeps a registry of TCP and UDP protocol names and ports assigned to each, and Bonjour services are named according to this list. The list used by Mac OS X can be found in /etc/services, and the most current version of the list is available athttp://www.dns-sd.org/ServiceTypes.html.

Bonjour service names combine service types and transport protocols to form a registration type. The registration type is used to register a service and create DNS resource records for it. To distinguish registration types from domain names in DNS resource records, registration types use underscore prefixes to separate the components that make up a registration type. The format is

_ServiceType._TransportProtocolName.

The service type is the official IANA-registered name for the service, for example, ftp, http or printer. The transport protocol name is tcp or udp, depending on the transport protocol the service uses. An FTP service running over TCP would have a registration type of _ftp._tcp. and would register a DNS PTR record named _ftp._tcp.local. with its hosts’ Multicast DNS responder.

Bonjour Names for New Services

If you are designing a new protocol to advertise as a Bonjour network service, you should register it at http://www.dns-sd.org/ServiceTypes.html.

The IANA currently requires that every registered service be associated with a “well-known port” or range of well-known ports. For example, http is assigned port 80, so that whenever you visit a website in your web browser, the application assumes that the HTTP service is running on port 80 unless you specify otherwise. This way, the port number for a website need only be memorized if the website is configured in a non-standard way.

With Bonjour, however, you don’t have to know about port numbers. Because client applications can discover your service with a simple query for the service type, well-known ports are unnecessary.

Bonjour Names for Service Instances

Service instance names are intended to be human-readable strings. As such, you should name them descriptively, and let the user override whatever default name you provide. Because they are intended to be browsed rather than typed, service instance names can be any Unicode string encoded with UTF-8, up to 63 octets (bytes) in length.

For example, an application for sharing music over the network might use the local user’s name for a music sharing service, such as Ed's Music Library, by default. The user could override the default and name the service Zealous Lizard's Tune Studio, and the application would register a DNS SRV record named Zealous Lizard's Tune Studio._music._tcp.local., assuming the application’s music sharing protocol was associated with the name music.

Figure 2 illustrates the organization of the name of a Bonjour service instance. At the top level of the tree is the domain, such as local. for the local network. Below the domain is the registration type, which consists of the service type preceded by an underscore (_music) and the transport protocol, also preceded by an underscore (_tcp). At the bottom of the tree is the human-readable service instance name, such as Zealous Lizard’s Tune Studio. The complete name is a path along the tree from bottom to top, with each component separated by a dot.

Figure 2 Organization of a Bonjour service name

< Previous PageNext Page >

Hide TOC

Did this document help you?
Yes: Tell us what works for you. It’s good, but: Report typos, inaccuracies, and so forth. It wasn’t helpful: Tell us what would have helped.