Service Records

The SRV record maps the name of the service instance to the information needed by a client to actually use the service. Clients then store the service instance name as a persistent way to access the service, and perform a DNS query for the host name and port number when it’s time to connect. This additional level of indirection provides for two important features. First, the service is identified by a human-readable name instead of a domain name and port number. Second, clients can access the service even if its port number, IP address, or host name changes, as long as the service name remains the same.

The SRV record contains two pieces of information to identify a service:

• Host name

• Port number

The host name is the domain name where the service can currently be found. The reason a host name is given instead of a single IP address is that it could be a multi-homed host with more than one IP address, or it could have IPv6 addresses as well as IPv4 addresses, and so on. Identifying the host by name allows all these cases to be handled gracefully.

The port number identifies the UDP or TCP port for the service.

SRV records are named according to the following convention:

<Instance Name>.<Service Type>.<Domain>

<Instance Name>, the name of a service instance, can be any UTF-8-encoded Unicode string, and is intended to be human readable.

<Service Type> is a standard IP protocol name, preceded by an underscore, followed by the host-to-host transport protocol (TCP or UDP), also preceded by an underscore. For example, a Trivial FTP service running over UDP would have a service type of _tftp._udp, and an IPP printing service running over TCP would register under the _ipp._tcp service type. The list of official protocol names is maintained by IANA; see Domain Naming Conventions for more information.

<Domain> is a standard DNS domain. This may be a specific domain, such as apple.com., or the generic suffix local. for a service accessible only on the local link.

Here is an example of the SRV record (in the standard DNS record format) for a print spooler named PrintsAlot running on TCP port 515:

PrintsAlot._printer._tcp.local. 120 IN SRV 0 0 515 blackhawk.local.

This record would be created on the Multicast DNS responder of a printer called blackhawk.local. on the local link. The initial 120 represents the time-to-live (TTL) value which is used for caching. The two zeros are weight and priority values, used in traditional DNS when choosing between multiple records that match a given name; for multicast DNS purposes, these values are ignored.

For more information about domain, service, and instance names, see Domain Naming Conventions.

Pointer Records

PTR records enable service discovery by mapping the type of the service to a list of names of specific instances of that type of service. This record adds yet another layer of indirection so services can be found just by looking up PTR records labeled with the service type.

The record contains just one piece of information, the name of the service instance (which is the same as the name of the SRV record). PTR records are accordingly named just like SRV records but without the instance name:

<Service Type>.<Domain>

Here is an example of a PTR record for a print spooler named PrintsAlot:

_printer._tcp.local. 28800 PTR PrintsAlot._printer._tcp.local.

Again, the 28800 is the time-to-live (TTL) value, measured in seconds.

Text Records

The TXT record has the same name as the corresponding SRV record, and can contain a small amount of additional information about the service instance, typically no more than 100–200 bytes at most. This record may also be empty. For example, a network game could advertise the name of the map being used in a multiplayer game, and a chat program could advertise the availability of the user (for example, idle, away, or available). If you need to transmit larger amounts of data, the host should establish a connection with the client and send the data directly.

Historically, this record has been used for multiple services running on the same port at the same IP address, for example multiple print queues running on the same print server. In this case additional information in the TXT record can be used to identify the intended print queue, as shown in this example:

This kind of practice was necessary because service types have historically been associated with well known ports. Designers of new Bonjour protocols are encouraged to run each instance of their service on a different dynamically allocated port number, instead of trying to run them all on the same well known port number and using extra information to specify which instance the client is trying to talk to.

The nature and format of the data in the TXT record are specific to each type of service, so each new service type needs to also define the format of data for its associated TXT record (if any), and publish this format as part of the protocol specification.

Publication: An Example

For a concrete example, consider a hypothetical device that shares music over a local network—an IP-enabled jukebox. Suppose that its transport protocol is TCP and its application protocol goes by the name music. When someone plugs the device into an Ethernet hub, a number of things happen, as shown in Figure 4-1.

In step 1, the device randomly selects the link-local IP address 169.254.150.84, randomly selected from the IPv4 link-local range 169.254.0.0 with a subnet mask of 255.255.0.0, and announces it to the network. Because no devices respond to the announcement, the device takes the address as its own. In step 2, it starts up its own Multicast DNS responder, requests the host name eds-musicbox.local., verifies its availability, and takes the name as its own. Next, in step 3, the device starts up a music sharing service on TCP port 1010. Finally, in step 4, it publishes the service, of type _music._tcp, under the name Ed’s Party Mix, in the local. domain, first making sure that no service exists under the same name. This creates two records:

• An SRV record named Ed’s Party Mix._music._tcp.local. that points to eds-musicbox.local. on TCP port 1010

• A PTR record named _music._tcp.local. that points to the Ed’s Party Mix._music._tcp.local. service.