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 domain
apple.com., which is within the top-level domain
com., which in turn is part of
. (“dot”), the root domain. Figure 2-1 shows an abridged version of this hierarchy.
At the top of the inverted tree is the root domain. Below it are some of the top-level domains:
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,
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 treats it as an unqualified (partial) name and appends the names from your list of search domains, such as
example.edu, and so on. The system first tries to append
. (“dot,” the root domain), but if the name
wibble.apple.com. doesn’t exist, it continues down the list and tries
wibble.apple.com.example.edu., and so on. Although this search domain feature is often useful, it is probably not what you intended in this case.
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.
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 iOS or any device without a screen) or by asking the user (in the case of a personal computer).
Bonjour and Unicast DNS
In addition to multicast DNS, Bonjour supports advertising and discovering services over traditional unicast DNS using wide-area Bonjour. Unicast DNS is outside the scope of this document. To learn more about configuring unicast domain name servers for use with Bonjour, see the DNS-SD website.
Bonjour Names for Existing Service Types
Bonjour services are named according to the existing Internet standard for IP services (described in RFC 2782). 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
The service type is the official IANA-registered name for the service, for example,
printer. The transport protocol name is
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 with IANA.
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
Émille'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
Figure 2-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.