Setting up Mobility DNS records for Infoblox DDI

“Help, I’m an Infoblox DDI admin and, while I read your introductory BIND DNS and Advanced BIND articles, I still need a hand configuring Mobility DNS-SD records to enable printer discovery.”


Hey, there, and thanks for reaching out! Infoblox DNS and BIND DNS share many elements under-the-hood, but Mobility record configuration is not one of them. Please continue reading to learn about setting up Mobility records for PaperCut State’s Infoblox DDI. 

Infoblox DDI environmental variables

Everyone’s Infoblox DDI config looks different from the next. The names and addresses we use in this article won’t match yours, but that’s okay. Hopefully, you can make sense of our KB by understanding the assumptions we made:

Our pretend elementThe element’s value
Default search
Other search,,
Mobility server’s
Apple device subnets:,

But first, an important note

Because these steps require putting a forwarding zone in your forward-mapping zones, these DNS zones must be part of your device’s DNS domain search list. In other words, we assume your Infoblox DHCP will set connected devices into their correct subdomains using options 15 or 119. 

Creating the pc-printer-discovery Forwarding Zone

By default, this forwarding zone is all that Windows, Android, and Chrome devices need to discover the Mobility printer advertisements. Apple devices will need this zone along with a PTR record in the appropriate reverse mapping zone, but we’ll get to that part in a bit. 

1. Sign in to the Infoblox interface then navigate to Data Management > DNS > then Zones. 
2. From there, click the + icon to add a Forward Zone.
3. Specify “Add a forward-mapping zone” and click Next. 
4. Name the new Forward Zone “”. Infoblox automatically adds the trailing dot.
5. Enter the Mobility server’s FQDN ( and IP:
6. Choose which Grid Members have the responsibility to respond for the new Forward Zone and click next.
7. Save and close. Then, restart Infoblox when prompted for the new settings to apply.  

But what if my DHCP clients don’t all get the same DNS search list?

Well, fret not, dear Infoblox admin. The trick to supporting network clients that don’t get the search domain is to add a pc-printer-discovery forwarding zone for the related domains. In other words, please follow the steps in the “Creating the pc-printer-discovery Forwarding Zone” for each DNS zone that DHCP options 15 or 119 deliver as the domain name that clients should use when resolving hostnames via DNS. As an example, you might end up with NS RR data that looks like so: NS NS NS NS

Okay, let’s confirm we didn’t just waste several minutes

It wouldn’t help to have this shiny, new forwarding zone on your Infoblox DDI if it didn’t resolve to anything, so let’s make sure it works. Try running the following commands from a Terminal or command prompt window. 

1. First, flush the DNS cache to make sure we’re using only the freshest DNS records:
  • In Windows: ipconfig /flushdns
  • In fancyOS: sudo killall -HUP mDNSResponder
  • In Linux: Well, consult your distribution’s documentation since some implementations don’t even cache DNS by default. 
2. Let’s do a query to find a printer list using the _ipps._tcp service type. You should recognize the printers in the name record data.
nslookup -query=ptr

At this point, printer discovery should work from Windows, Android, and Chrome clients that get the search domain, but not iOS and macOS. Try running the respective clients to confirm. And now, a question: 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 “Infoblox Mobility printer discovery for Apple devices.” However, if you answered, “No, 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. You’re all done. Get a hot or cold beverage of your choice, because you deserve it. 

Infoblox DNS Mobility printer discovery for Apple devices

macOS and iOS devices require an Apple-specific lb PTR record to find Mobility printer advertisements in the reverse-mapping zones correspondent to their current subnets. This section assumes that reverse-mapping zones for the and subnets already exist. Create these PTR records using the nsupdate command-line utility. The tool is native to macOS and Linux. To install nsupdate on Windows, see here: 

1. Navigate to Grid Manager > DNS > Services and check the box next to the Grid Master. Click the edit button and select Updates. From there, add the IP address of the system sending the nsupdate commands, AKA source system.
2. From the source system, enter the following commands to add the lb PTR record in the existing wireless subnet reverse mapping zone. This example assumes DHCP hands the Apple devices our default search domain, 
FANCYOS:~ coolkid$ nsupdate -d
> server
> add 14400 IN PTR
> send

> server
> add 14400 IN PTR
> send

Note: To accommodate Apple devices with a different domain search list, supplement your nsupdate command with the correct forwarding zone. For example:

> add 14400 IN PTR
3. Verify that the records show up in the zones and Flush your DNS cache, and try the following nslookup chain:
FANCYOS:~ coolkid$ nslookup -type=ptr && nslookup -type=ptr
The results should look like so:
Address: name =

Address: name =
4. Ensure the records replicate across all DNS servers. 

And that’s it. Now, Apple devices in the and subnets can use the lb PTR record, in conjunction with the pc-printer-discovery forwarding zones, to discover Mobility printer advertisements. 

Executive summary, or TL;DR

  • We set up pc-printer-discovery forwarding zones for each DNS zone corresponding to a domain name the client should use when resolving hostnames via DNS.
    • Remember: This forwarding zone is all that Windows, Android, and Chrome devices need to discover the Mobility printer advertisements.
  • We set up lb PTR records for the subnets hosting Apple devices. 
    • Remember: macOS and iOS require an Apple-specific lb PTR record in the reverse-mapping zones correspondent to their current subnets.
  • We used a couple of NSLOOKUPS to check our work. 

Stop, collaborate, and listen

This article was a team effort, and being able to publish it sooner rather than later is due in large part to Rod Eldridge, Network Engineering Team, Iowa State University. His charitable behavior extends beyond helping the humble author of this article as he is also willing to offer limited help to other universities with their PaperCut Mobility Print implementation, with regards to DNS and DHCP, and as time permits. Reach him at

Do you still have questions?

Let us know! We love chatting about DNS, Mobility, and what’s going on under the hood. Talk nerdy to us. Feel free to leave a comment below or visit our Support Portal for more help.

Categories: How-to Articles, Mobility Print

Keywords: Secret squirrel , Mobility Print, DNS Records, DNS-SD, Linux, BIND, NAMED, Cool Kids, Delegated Subzone, Conditional Forwarder, Infoblox