CUPS and DNS-SD printing

Bonjour zeroconf! It's a rendezvous.

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


    1. Introduction
    2. Configuring DNS
      1. Do we provide service records?
      2. The printing services
      3. Sub CUPS
      4. Sub Universal
      5. The SRV record
      6. The TXT record
      7. Testing the setup
    3. Connecting Mac OS X


We have a CUPS server running with CUPS 1.4.3. This machine has a PPD for every printer it has, so it is the source of all printing for us.

GNU/Linux machines print to this server by setting Browsing to On and the BrowsePoll setting to our printserver in their cupsd.conf, and off they go.

This same procedure worked up till Mac OS 10.7 for Mac OS X machines, however with introduction of 10.8 the BrowsePoll is removed, so we can not use this anymore. The solution is to provide the printer information through the use of mDNS. Our printers, clients and printservers are however located in different subnets, so multicast will not work. The solution is to use DNS-SD, DNS Service Directives, and that is what this document is about.

Configuring DNS

In this example configuration we use as our domain. The printserver is called and is known as on our server network. The printer is known as and can be reached at

First I added the standard A-record settings so DNS works as should be (the ORIGIN and TTL settings are just their for clarity, and testing purposes):

$TTL 3600 ; 1 hour
printserver          A
printer102           A

Do we provide service records?

From this point on it is important to understand and keep in mind that I client is trying to find services, so it is not looking for e.g. a specific printer, but just a service that provides 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:

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, but we do not allow that here. See: 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:, but since we declared our $ORIGIN, we know for sure the @ contains that already.

The printing services

Next I added a PTR record for our IPP capable printer, or better it is a printer connected to a CUPS server that provides IPP printing to our users:

_ipp._tcp            PTR
This feature tells a client that IPP (port 631) over TCP is provided by a printer called

Other printing related services are _printer._tcp which is standard LPR (port 515) printing and _pdl-datastream._tcp used for socket printing (port 9100). List of PDLs (page description languages) supported by a given printer is indicated by the "pdl" key in the TXT record. And there also something called HTTP printer with a service type of _printer._sub._http._tcp FIXME is this correct?.

For a complete list of Service Types supported by DNS-SD see:


_cups._sub._ipp.tcp      PTR
FIXME I can not find any information for this line. My idea is that it tells the client that there is a CUPS service... but does the client care?

Sub Universal

The following line enables AirPrint, an Apple feature for iOS based products like the iPad and the iPhone. This way these devices can find our printers.

_universal._sub._ipp.tcp PTR
FIXME: but what are the details that a client expects, when searching for AirPrint services?

The _universal._sub entry is available for AirPrint functionality as provided by the iOS devices.

The SRV record

Now that we told our clients that our printer can do IPP, AirPrint and that it is a CUPS printer, we need to tell the client where the printer is located and we do this by using a SRV record:

printer102._ipp._tcp SRV 0 0 631
This tells the client that our IPP printer can be reached at on port 632.

The TXT record

And finaly there is a TXT record for printers. Within a TXT record additional information is provided concerning the printer.

printer102._ipp._tcp TXT ( 
			   "product=(Xerox WorkCentre 7556)"
			   "ty=Xerox WorkCentre 7556"
I kept it simple. The printer can be found on the printserver, and I only added the most essential parts:
A required field that must be 1
The amount of queues present for this printer
The relative path to the printer, without the leading slash (/)
The URL that the client should use to get more information, FIXME: atleast that is what I think
Information I grepped (ModelName) from the printer PPD
The location of the printer
Same as the product string
Page Description Language, which language does our "printer" support. Since we are printing to CUPS, we only want PostScript (other options are: application/octet-stream, application/pdf, image/jpeg, image/png, image/urf
More information on these settings can be found in Bonjour Printing 1.0.2 and cs-ippeve10-20130128-5100.14.pdf.

Testing the setup

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

host -t PTR
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 _ipp._tcp

Connecting Mac OS X

With everything in place one can go to the System Preferences, select Printers and Faxes, click on the + sign, and select the printer. This will automatically install the driver, and everything works as expected.