A better BIND Mobility record setup, a better you

“Help! I’m one of those cool kids that uses a BIND DNS server. I heard about PaperCut’s Mobility feature, so can you guys help me set up the DNS records in BIND so that my C suite can print from their iDevices?” Hey, how’s it going! We’re glad to hear the cool kids haven’t forgotten about us here at PaperCut. We’re also super looking forward to getting your BIND DNS server up and running with Mobility printer advertisement records as straightforwardly as possible. Let’s jump right in. BIND environmental variables Everyone’s BIND server config looks different from the next. It’s more likely than not that the file names and directories we use in this article won’t exactly match yours, but that’s okay. Hopefully, you can make sense of our KB by understanding the assumptions we made: That your BIND options config file has a name like named.conf.options. That your local BIND configuration file has a name like named.conf.local. That your named.conf.options and named.conf.local files are in the /etc/bind/ directory. That your sample zone files, like db.local or db.127, are in /etc/bind/. That your production zone file directory is /etc/bind/zones/. Other variables Also, don’t you hate it when you find a tutorial that doesn’t describe all of its random IP addresses? Well, hate no more, friend: Our pretend subnet: 10.1.1.0 Our pretend Mobility server: 10.1.8.101 Our pretend BIND DNS server: 10.1.9.69 Create the reverse zone file Here, we’ll write the reverse zone file corresponding to the subnet hosting your Apple devices. Let’s say the subnet is 10.1.1.0. We’ll call the new reverse zone file rev.0.1.1.10 and base it on the sample db.127 zone file. Copy the sample to the production zones folder with the following commands: cd /etc/bind/ sudo cp db.127 ./zones/rev.0.1.1.10 Next, we’ll start editing our new reverse zone file: cd /etc/bind/zones sudo nano rev.0.1.1.10 Here’s what the file looks like at first: File: /etc/bind/zones/rev.0.1.1.10 ; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. 1.0.0 IN PTR localhost. Change the SOA to replace the first “localhost” with your BIND server’s FQDN and replace “root.localhost” with your contact info. Also, delete the default PTR record. Then, add your name server record. You’ll end up with something like this: File: /etc/bind/zones/rev.0.1.1.10 ; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA dns.paper.cut. admin.dns.paper.cut. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; name server - NS records IN NS dns.paper.cut. At the end of the file, add the PTR records that Apple devices will use to discover Mobility printers. Note that the data column has our subnet’s IP address in reversed octet order, just like the file name. Don’t forget to update the serial! You should have something like this: File: /etc/bind/zones/rev.0.1.1.10 ; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA dns.paper.cut. admin.dns.paper.cut. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; name server - NS records IN NS dns.paper.cut. ; PTR Records b._dns-sd._udp IN PTR 0.1.1.10.pc-printer-discovery. ; b record for 10.1.1.0 lb._dns-sd._udp IN PTR 0.1.1.10.pc-printer-discovery. ; lb record for 10.1.1.0 Save and close the new reverse zone file. Yay! Edit the local config file Let’s have a quick chat about what’s coming next. The forward-only zone helps Apple devices complete queries with the b and lb PTR records. The forward-only zone is also what Android, Windows, and Chrome clients directly use to find the Mobility server. In other words, Apple devices need help finding Mobility advertisements from the reverse zone file as well as forward-only zone while Android, Windows, and Chrome clients can do it with the forward-only zone alone. Okay, now we’ll go to the BIND local config file, named.conf.local, and specify our new reverse zone and add a forwarder. sudo nano /etc/bind/named.conf.local Add the reverse zone using these lines: File: /etc/bind/named.conf.local zone “0.1.1.10.in-addr.arpa” { type master; file “/etc/bind/zones/rev.0.1.1.10”; }; Add the forward-only zone using these lines. 10.1.8.101 is the Mobility server’s IP address stand-in: File: /etc/bind/named.conf.local zone “pc-printer-discovery” { type forward; forward only; forwarders { 10.1.8.101; }; }; Save and close the local config file. Edit the options file Next, open the BIND options file named.conf.options. sudo nano /etc/bind/named.conf.options If you have dnssec options set to auto, set them to yes like so: File: /etc/bind/named.conf.options dnssec-enable yes; dnssec-validation yes; Then add a new entry to disable dnssec security for the pc-printer-discovery forward-only zone: File: /etc/bind/named.conf.options dnssec-must-be-secure pc-printer-discovery no; Save and close the options file. Restart BIND and check the status Restart BIND: sudo systemctl restart bind9 Check status: sudo systemctl status bind9 Hopefully, you’re free and clear of any problems, so your output should look like so: coolkid@BINDSERVER:~$ sudo systemctl status bind9 bind9.service - BIND Domain Name Server Loaded: loaded (/etc/systemd/system/bind9.service; enabled; vendor preset: enabled) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf-$named.conf Active: active (running) since Fri 2019-08-23 15:22:12 PDT; 6s ago Docs: man:named(8) Process: 1300 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS) Main PID: 1306 (named) Tasks: 4 Memory: 9.5M CPU: 20ms CGroup: /system.slice/bind9.service └─1306 /usr/sbin/named -f -u bind -4 Aug 23 15:22:12 dns named[1306]: configuring command channel from ‘/etc/bind/rndc.key’ Aug 23 15:22:12 dns named[1306]: command channel listening on 127.0.0.1#953 Aug 23 15:22:12 dns named[1306]: managed-keys-zone: loaded serial 41 Aug 23 15:22:12 dns named[1306]: zone 0.in-addr.arpa/IN: loaded serial 1 Aug 23 15:22:12 dns named[1306]: zone 0.1.1.10.in-addr.arpa/IN: loaded serial 12 Aug 23 15:22:12 dns named[1306]: zone 127.in-addr.arpa/IN: loaded serial 1 Aug 23 15:22:12 dns named[1306]: zone 255.in-addr.arpa/IN: loaded serial 1 Aug 23 15:22:12 dns named[1306]: zone localhost/IN: loaded serial 2 Aug 23 15:22:12 dns named[1306]: all zones loaded Aug 23 15:22:12 dns named[1306]: running Okay, let’s confirm we didn’t just waste several minutes. It wouldn’t help to have all of these shiny, new DNS records on your BIND server if they didn’t resolve to anything, so let’s make sure they work. Make sure the forward-only zone works Use the following nslookup query to confirm the forward-only zone is, well, forwarding: nslkookup rpc.pc-printer-discovery What’s the nslookup asking, and what does the right answer look like? The nslookup asks the BIND server to identify the Mobility server’s primary rpc record. The BIND server forwards the request to Mobility by matching the query’s pc-printer-discovery string to the forward-only zone, and Mobility replies with its IP address: coolkid@BINDSERVER:~$ nslookup rpc.pc-printer-discovery Server: 10.1.9.69 Address: 10.1.9.69#53 Non-authoritative answer: Name: rpc.pc-printer-discovery Address: 10.1.8.101 Make sure the PTR records in the reverse zone work Use the nslookup chain below to confirm BIND can reply with the correct b and lb record data. The query has to include the subnet in reverse octet notation, just like the reverse zone file name, and the PTR records in it: nslookup -query=ptr b._dns-sd._udp.0.1.1.10.in-addr.arpa && nslookup -query=ptr lb._dns-sd._udp.0.1.1.10.in-addr.arpa What’s the nslookup asking, and what does the right answer look like? So, this nslookup determines whether the reverse zone has the PTR records that help Apple devices discover printer advertisements through Mobility. “But wait,” I can imagine you exclaiming indignantly, “you still haven’t explained this business with the b and lb records?” Well, dear reader, I’ll let our homeboy Stewart Cheshire explain it in his own words here: https://tools.ietf.org/html/rfc6763#page-28 . Anyway, here’s a successful query showing the b and lb records pointing to the right name data: coolkid@BINDSERVER:~$ nslookup -query=ptr b._dns-sd._udp.0.1.1.10.in-addr.arpa && nslookup -query=ptr lb._dns-sd._udp.0.1.1.10.in-addr.arpa Server: 10.1.9.69 Address: 10.1.9.69#53 b._dns-sd._udp.0.1.1.10.in-addr.arpa name = 0.1.1.10.pc-printer-discovery. Server: 10.1.9.69 Address: 10.1.9.69#53 lb._dns-sd._udp.0.1.1.10.in-addr.arpa name = 0.1.1.10.pc-printer-discovery Finally, let’s find printer advertisements Last but not least, let’s do the nslookup to ask the BIND server to find a printer list using the _ipps._tcp service type. You should recognize the printers in the name record data. nslookup -query=ptr _ipps._tcp.pc-printer-discovery coolkid@BINDSERVER:~$ nslookup -query=ptr _ipps._tcp.pc-printer-discovery Server: 10.1.9.69 Address: 10.1.9.69#53 Non-authoritative answer: _ipps._tcp.pc-printer-discovery name = library._ipps._tcp.pc-printer-discovery. _ipps._tcp.pc-printer-discovery name = reception._ipps._tcp.pc-printer-discovery. Do you still have questions? Let us know! We love chatting about BIND, Mobility, and what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.