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.