Extending DNS with DNS-SD

Bonjour zeroconf! It's a rendezvous

© 2013 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later


    1. Introduction
    2. Do we provide service records?
    3. What services do we provide
    4. An IPP example
    5. Testing DNS-SD


To support your Mac OS X clients (especially 10.8 and up in combination with printing), your DNS server should tell your network which services are available on your network. This document details the basic stuff you need to add to your DNS server to make DNS-SD (DNS Service Discovery) work.

Do we provide service records?

From this point on it is important to understand and to keep in mind that a client is trying to find services, so it is not looking for e.g. a specific printer or IP address, but it is searching for a service that provides e.g. printing. PTR records are used to point a client looking for a service to the device providing that service.

Before a client will gather information from a DNS server, and starts looking for Service Discovery records, it will check to see if the zone is able to provide the information. The check is done by looking up one of two special entries in the DNS zone:

$ORIGIN example.com.
b._dns-sd._udp       PTR @
lb._dns-sd._udp      PTR @
These two records inform clients that they should check the DNS zone for advertised services. The b stands for "browse domain" and lb for "legacy browse domain". There is also an r domain that tells the client that registering is possible, meaning the zone can do dynamic updates. See: http://www.dns-sd.org/ServerSetup.html for more information about the different domains.

The @ can of course also be replaced by the full domain part that this zone is responsible for like: example.com., but since we declared our $ORIGIN, we know for sure the @ contains that already.

What services do we provide

Now that our domain allows a client to browse for services, we need to tell the client which services we provide. This is again done by using PTR records. An example record looks like this:

_services._dns-sd._udp  PTR    _ipp._tcp.example.com.
This tells a client that we provide IPP printing records through DNS-SD service records.

To make the DNS configuration easier to read, I used the bind $INCLUDE directive:

$INCLUDE /var/named/com/example/services.zone _services._dns-sd._udp.example.com.
This will include the file mentioned and sets the $ORIGIN to the provided domain (_services._dns-sd._udp.example.com.)

The services.zone file can then look like this to provide services to our clients:

@		PTR	_ipp._tcp.example.com.
@		PTR	_ldap._tcp.example.com.
The @ expands to the $ORIGIN that is given with the $INCLUDE directive.

An IPP example

The last step in the set up of DNS-SD is to provide information about the services. It is not enough to tell the client we can do IPP, it also needs to know where it can find the server or printer that does IPP. In this section we provide a little example. We will again use an additional file to $INCLUDE our IPP services. The file we create is called service.ipp.zone and contains:

@               PTR     printer01._ipp._tcp.example.com.
_cups._sub      PTR     printer01._ipp._tcp.example.com.
_universal._sub PTR     printer01._ipp._tcp.example.com.
printer01   TXT (
                "product=(hp LaserJet 4350)"
                "ty=HP LaserJet 4350"
                "note=2.201 (coffee corner 2nd floor)"
printer01   SRV 0 0 613	ipp.example.com.

This zone is then included in our main configuration by using:

$INCLUDE /var/named/com/example/service.ipp.zone _ipp._tcp.example.com.

Testing DNS-SD

The simpest test you can do is by requesting the PTR records from your DNS server to see if it works:

host -t PTR _ipp._tcp.example.com
This will show all printer capable of doing IPP over TCP. If this works your basic setup works.

If you have avahi installed you can run the same check like this:

avahi-browse -t -d example.com _ipp._tcp