Bonjour zeroconf! It's a rendezvous.
© 2013 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later
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.
In this example configuration we use example.com as our domain. The printserver is called printserver.example.com and is known as 192.168.1.55 on our server network. The printer is known as printer02.example.com and can be reached at 192.168.10.2.
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):
$ORIGIN example.com $TTL 3600 ; 1 hour printserver A 192.168.1.55 printer102 A 192.168.10.2
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: 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.
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 printer02._ipp._tcp.example.com.This feature tells a client that IPP (port 631) over TCP is provided by a printer called printer02._ipp._tcp.example.com..
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: http://www.dns-sd.org/ServiceTypes.html.
_cups._sub._ipp.tcp PTR printer02._ipp._tcp.example.com.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?
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 printer02._ipp._tcp.example.com.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.
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 printserver.example.com.This tells the client that our IPP printer can be reached at printserver.example.com on port 632.
And finaly there is a TXT record for printers. Within a TXT record additional information is provided concerning the printer.
printer102._ipp._tcp TXT ( "txtvers=1" "qtotal=1" "rp=printers/printer102" "adminurl=ipp://printserver.examle.com:631/printers/printer102" "product=(Xerox WorkCentre 7556)" "note=Room.120" "ty=Xerox WorkCentre 7556" "pdl=application/postscript" )I kept it simple. The printer can be found on the printserver, and I only added the most essential parts:
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.comThis 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
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.