Advanced BIND DNS Mobility record setup

“Help! I’m one of those Cool Kids that read the Better BIND setup KB, and now I need to know about fancier things like accommodating multiple Mobility servers or subnet filtering.”

Oh, boy, Cool Kids. If it’s not one thing, it’s another with you. Let’s jump right in.

Environmental Variables

The assumptions we make about your BIND server file names and directories in this article are the same ones we made in the original Better BIND article. So, if you haven’t taken a look at the first KB, this is your gentle, but stern, reminder to do so.

As for our pretend Mobility servers and subnets, please see below:

• Our pretend subnets: 10.1.1.0, 10.2.1.0, and 10.3.1.0.
• Our pretend Mobility servers: 10.1.8.101, 10.1.8.102, 10.1.8.103
• Our pretend BIND DNS server: 10.1.9.69

But first, an important note

Nearly all of the advice in this article assumes your client device deployment includes a complement of Apple devices. In other words, do you - now, or will you at any point in the future - have a requirement to share printer advertisements with iOS devices like iPads or iPhones, or macOS devices like MacBooks, iMacs, Mac Minis, and Mac Pros? If you answered yes, congratulations! Please fast-forward to “Multiple Mobility Servers for mixed fleets of Android, Apple, Chrome, and Windows devices” as you are the primary beneficiary of this article’s advice. However, if you answered, “No, absolutely not. I have no plans to support Mobility printer discovery for Apple devices now or at any point in the future,” then I congratulate you too because I just saved you several minutes, at least. Please fast-forward to the next section: “For admins that don’t support Apple devices.”

For admins that don’t support Apple devices

Admins without the need to support Apple devices with multiple Mobility servers or across multiple subnets have it relatively easy when it comes to BIND DNS records. All that your Windows, Android, and Chrome OS devices need from your BIND DNS server are the appropriate forward-only zones. Forget entirely about reverse zones. Let’s jump right in:

Multiple Mobility Servers with or without subnet filtering

As we know from the Mobility Print Help Center’s advice for setting up Windows DNS records for up to 20 Mobility servers, one has to “Set up the DNS records so a Conditional Forwarder for each of the pc-printer-discovery-# zones points to a different Mobility Print server.” The Windows DNS advice applies here as well. In other words, the requirement as it pertains to us BIND Cool Kids is to set up a pc-printer-discovery forward-only zone for one Mobility server, a pc-printer-discovery-1 forward-only zone for the next Mobility server, and so on.

In this example, launch your named.conf.local file and add the forward-only zones for each Mobility server using these lines:

cd /etc/bind/
sudo nano named.conf.local

File: /etc/bind/named.conf.local
zone “pc-printer-discovery” {
type forward;
forward only;
forwarders { 10.1.8.101; };
};
zone “pc-printer-discovery-1” {
type forward;
forward only;
forwarders { 10.1.8.102; };
};
zone “pc-printer-discovery-2” {
type forward;
forward only;
forwarders { 10.1.8.103; };
};

Save and close the local config file.

Next, launch the named.conf.options file and add new entries to disable dnssec security for each Mobility server’s forward-only zone:

File: /etc/bind/named.conf.options
dnssec-must-be-secure pc-printer-discovery no;
dnssec-must-be-secure pc-printer-discovery-1 no;
dnssec-must-be-secure pc-printer-discovery-2 no;

Save and close the options config file, and restart BIND. You’re all done as far as editing BIND DNS records.

You can check your work using a couple of nslookup chains

Use the following nslookup chain to confirm the forward-only zones are, well, forwarding:

nslookup rpc.pc-printer-discovery && nslookup rpc.pc-printer-discovery-1 && nslookup rpc.pc-printer-discovery-2

The output should look like so:

coolkid@BINDSERVER:~$ nslookup rpc.pc-printer-discovery && nslookup rpc.pc-printer-discovery-1 && nslookup rpc.pc-printer-discovery-2
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
Name:   rpc.pc-printer-discovery
Address: 10.1.8.101
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
Name:   rpc.pc-printer-discovery-1
Address: 10.1.8.102
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
Name:   rpc.pc-printer-discovery-2
Address: 10.1.8.103

Next, make sure to “Set the Index Number on each Mobility Print server” as advised in the Mobility Print Help Center. Then, if you need to restrict printer access per subnet, refer to the Help Center’s article here. Those of you without the glorious burden of having to support Mobility Print advertisements for Apple devices are all done with DNS records. Go have a cold or hot beverage of your choice to celebrate, and imagine it’s on us.

Multiple Mobility Servers for mixed fleets of Android, Apple, Chrome, and Windows devices

Making multiple Mobility servers visible to multiple subnets

Okay, Cool Kids, this example assumes you have several subnets that need to see printer advertisements from multiple Mobility servers.

Here, we’ll write the reverse zone files corresponding to each subnet hosting your Apple devices. Let’s say the subnets are 10.1.1.0, 10.2.1.0, and 10.3.1.0. We’ll call the new reverse zone files rev.0.1.1.10, rev.0.1.2.10, and rev.0.1.3.10 and base them 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
sudo cp db.127 ./zones/rev.0.1.2.10
sudo cp db.127 ./zones/rev.0.1.3.10

Each reverse zone file will look exactly the same up top. This example uses rev.0.1.1.10. 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.

Next, we’ll edit each reverse zone file’s bottom half. 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. You should have something like this for rev.0.1.1.10:

File: /etc/bind/zones/rev.0.1.1.10
; PTR Records for Mobility server 1
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
; PTR Records for Mobility server 2
b._dns-sd._udp       IN PTR 0.1.1.10.pc-printer-discovery-1.    ; b record for 10.1.1.0
lb._dns-sd._udp      IN PTR 0.1.1.10.pc-printer-discovery-1.    ; lb record for 10.1.1.0
; PTR Records for Mobility server 3
b._dns-sd._udp       IN PTR 0.1.1.10.pc-printer-discovery-2.    ; b record for 10.1.1.0
lb._dns-sd._udp      IN PTR 0.1.1.10.pc-printer-discovery-2.    ; lb record for 10.1.1.0;

Here’s rev.0.1.2.10:

File: /etc/bind/zones/rev.0.1.2.10
; PTR Records for Mobility server 1
b._dns-sd._udp       IN PTR 0.1.2.10.pc-printer-discovery.    ; b record for 10.2.1.0
lb._dns-sd._udp      IN PTR 0.1.2.10.pc-printer-discovery.    ; lb record for 10.2.1.0
; PTR Records for Mobility server 2
b._dns-sd._udp       IN PTR 0.1.2.10.pc-printer-discovery-1.    ; b record for 10.2.1.0
lb._dns-sd._udp      IN PTR 0.1.2.10.pc-printer-discovery-1.    ; lb record for 10.2.1.0
; PTR Records for Mobility server 3
b._dns-sd._udp       IN PTR 0.1.2.10.pc-printer-discovery-2.    ; b record for 10.2.1.0
lb._dns-sd._udp      IN PTR 0.1.2.10.pc-printer-discovery-2.    ; lb record for 10.2.1.0;

And rev.0.1.3.10:

File: /etc/bind/zones/rev.0.1.3.10
; PTR Records for Mobility server 1
b._dns-sd._udp       IN PTR 0.1.3.10.pc-printer-discovery.    ; b record for 10.3.1.0
lb._dns-sd._udp      IN PTR 0.1.3.10.pc-printer-discovery.    ; lb record for 10.3.1.0
; PTR Records for Mobility server 2
b._dns-sd._udp       IN PTR 0.1.3.10.pc-printer-discovery-1.    ; b record for 10.3.1.0
lb._dns-sd._udp      IN PTR 0.1.3.10.pc-printer-discovery-1.    ; lb record for 10.3.1.0
; PTR Records for Mobility server 3
b._dns-sd._udp       IN PTR 0.1.3.10.pc-printer-discovery-2.    ; b record for 10.3.1.0
lb._dns-sd._udp      IN PTR 0.1.3.10.pc-printer-discovery-2.    ; lb record for 10.3.1.0;

Using rev.0.1.1.10, here’s an example of what both halves look like all together:

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 for Mobility server 1
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
; PTR Records for Mobility server 2
b._dns-sd._udp       IN PTR 0.1.1.10.pc-printer-discovery-1.    ; b record for 10.1.1.0
lb._dns-sd._udp      IN PTR 0.1.1.10.pc-printer-discovery-1.    ; lb record for 10.1.1.0
; PTR Records for Mobility server 3
b._dns-sd._udp       IN PTR 0.1.1.10.pc-printer-discovery-2.    ; b record for 10.1.1.0
lb._dns-sd._udp      IN PTR 0.1.1.10.pc-printer-discovery-2.    ; lb record for 10.1.1.0;

Make sure to update your serials before saving and closing each zone file! 😃

Next, we’ll edit the local config file to include the new reverse zones and forward-only zones for each Mobility server. Launch the named.conf.local file for editing:

sudo nano /etc/bind/named.conf.local

Add the reverse zones 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”;
};
zone “0.1.2.10.in-addr.arpa” {
type master;
file “/etc/bind/zones/rev.0.1.2.10”;
};
zone “0.1.3.10.in-addr.arpa” {
type master;
file “/etc/bind/zones/rev.0.1.3.10”;
};

Next, using the following lines, add the forward-only zones for each of our Mobility servers; 10.1.8.101, 10.1.8.102, and 10.1.8.103.

File: /etc/bind/named.conf.local
zone “pc-printer-discovery” {
type forward;
forward only;
forwarders { 10.1.8.101; };
};
zone “pc-printer-discovery-1” {
type forward;
forward only;
forwarders { 10.1.8.102; };
};
zone “pc-printer-discovery-2” {
type forward;
forward only;
forwarders { 10.1.8.103; };
};

Save and close the local config 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 new entries to disable dnssec security for each Mobility server’s forward-only zone:

File: /etc/bind/named.conf.options
dnssec-must-be-secure pc-printer-discovery no;
dnssec-must-be-secure pc-printer-discovery-1 no;
dnssec-must-be-secure pc-printer-discovery-2 no;

You can check your work using a couple of nslookup chains

Use the following nslookup chain to confirm the forward-only zones are, well, forwarding:

nslookup rpc.pc-printer-discovery && nslookup rpc.pc-printer-discovery-1 && nslookup rpc.pc-printer-discovery-2

The output should look like so:

coolkid@BINDSERVER:~$ nslookup rpc.pc-printer-discovery && nslookup rpc.pc-printer-discovery-1 && nslookup rpc.pc-printer-discovery-2
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
Name:   rpc.pc-printer-discovery
Address: 10.1.8.101
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
Name:   rpc.pc-printer-discovery-1
Address: 10.1.8.102
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
Name:   rpc.pc-printer-discovery-2
Address: 10.1.8.103

Save and close the options file, restart BIND, and check the status. You should be all set concerning the DNS records.

Next, chain the nslookups to confirm the b and lb PTR records resolve. For the sake of brevity, the following example only uses the output for the 10.1.1.0 subnet. Make sure to test the other subnets using each subnet-specific reversed octet notation.

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

Output:

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

Last but not least, let’s do the nslookup chain to ask the BIND server to find printers from all of our Mobility servers using the _ipps._tcp service type. You should recognize the printers in the name record data.

nslookup -query=ptr _ipps._tcp.pc-printer-discovery && nslookup -query=ptr _ipps._tcp.pc-printer-discovery-1 && nslookup -query=ptr _ipps._tcp.pc-printer-discovery-2

coolkid@BINDSERVER:~$ nslookup -query=ptr _ipps._tcp.pc-printer-discovery &&  nslookup -query=ptr _ipps._tcp.pc-printer-discovery-1 &&  nslookup -query=ptr _ipps._tcp.pc-printer-discovery-2
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.
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
_ipps._tcp.pc-printer-discovery-1   name = konica._ipps._tcp.pc-printer-discovery-1.
_ipps._tcp.pc-printer-discovery-1   name = hpf2651b._ipps._tcp.pc-printer-discovery-1.
_ipps._tcp.pc-printer-discovery-1   name = bigxerox._ipps._tcp.pc-printer-discovery-1.
Server:     10.1.9.69
Address:    10.1.9.69#53
Non-authoritative answer:
_ipps._tcp.pc-printer-discovery-2   name = legal._ipps._tcp.pc-printer-discovery-2.

Only now should you go on to “Set the Index Number on each Mobility Print server” as advised in the Mobility Print Help Center.

Subnet Filtering

Dang, Cool Kids. Okay, so now, let’s use everything we covered to set the printers from Mobility server 10.1.8.103 to only advertise to the clients in subnet 10.3.1.0.

Your rev.0.1.3.10 zone file should look like so:

File: /etc/bind/zones/rev.0.1.3.10
;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     dns.paper.cut. admin.dns.paper.cut. (
4         ; Serial
604800         ; Refresh
86400         ; Retry
2419200         ; Expire
604800 )       ; Negative Cache TTL
; name server - NS records
IN      NS      dns.paper.cut.
; PTR Records for Mobility server 3
b._dns-sd._udp       IN PTR 0.1.3.10.pc-printer-discovery-2.    ; b record for 10.3.1.0
lb._dns-sd._udp      IN PTR 0.1.3.10.pc-printer-discovery-2.    ; lb record for 10.3.1.0;

Next, refer to the Mobility Print Help Center article here. In it, you’ll learn that your Mobility server 10.1.8.103’s printer.conf.toml file should look like so:

File: /PaperCut Mobility Print/data/config/printer.conf.toml
DefaultEnabled = true
[DisabledPrinters]
[EnabledPrinters]
[[SubnetFilterRule]]
PrinterName = “Legal”
Subnets = [“10.3.1.0/22”]
[Authentication]
PerJob = []
PerPrinter = []
Default = “per-printer”

Wow. You did it, Cool Kid. You learned all about setting up Mobility records on your BIND DNS server to support subnet filtering for mixed fleets of Android, Apple, Chrome, and Windows devices. You earned yourself a hot or cold beverage of your choice. Well done!

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.