Add PTR and NS Records to DNS Resolver possible?

  • @johnpoz:

    I sniffed the papercut ng box when it was running the test to try and see exactly what it was doing a query for so could put in the correct stuff in unbound to what it was looking for.  But I didn't see it do any queries.  It sent out a mdns query that the printer answered directly etc.  Which doesn't seem like a smart thing to do if what your running is a validation of the dns method, etc.

    Just a quick check…does the FQDN set in the box itself have to match the A record and NS record?

    e.g. When the box is assigned a static IP through the DHCP server and Unbound is set to record static DHCP entries. In the DHCP setting then should the hostname be set to "my-print-server" or can it be say "host1" and the additional custom options be added as well?

  • Hi,
    I am a developer from Mobility Print team at PaperCut Software. Here are some clarification about our documentation on setting up Mobility Print.

    ;---------------- Mobility Print records --------------
    b._dns-sd._udp       IN PTR pc-printer-discovery
    lb._dns-sd._udp      IN PTR pc-printer-discovery
    pc-printer-discovery IN NS  print-server-host
    print-server-host    IN A   XXX.XXX.XXX.XXX
    ;--------------- End of Mobility Print records --------- 

    Basically what we want is to set up a delegation to to the IP of the Mobility Print server. The two PTR records are defined by te DNS-SD RFC just for iOS and macOS devices

    Again, the syntax above is very specific to BIND. Here is the equivalent syntax but using FQDN:       IN PTR      IN PTR IN NS    IN A   XXX.XXX.XXX.XXX

    I am happy to answer any technical questions about how to setup Mobility Print in your environment.

  • Hello mobility_dev,

    Many thanks for joining the discussion and for clarifying the required records.

    I think the issue here is we need to find how best to create the required DNS records in 'Unbound' DNS (or 'DNS Resolver' as it is called in pfSense) so the Mobility Print App can successfully discover published printers.

    In order to do this I believe the resident 'DNS Resolver' experts would be interested in gaining a better understanding of how the DNS records are utilised by the client application, I'll ask the following questions in order to get the ball rolling, everyone else feel free to jump in …

    • Could you tell us how the client apps (Android, Windows, ChromeBook) search for the Mobility Print Server, do they specifically look for the subzone called 'pc-printer-discovery' with the same DNS suffix of the network the client device is connected to, or are the clients looking for the PTR records 'b._dns-sd._udp' & 'lb._dns-sd._udp' with the same DNS suffix of the network the client is connected to?

  • Hi trentuk,
    Here are are my answer:

    Could you tell us how the client apps (Android, Windows, ChromeBook) search for the Mobility Print Server, do they specifically look for the subzone called 'pc-printer-discovery' with the same DNS suffix of the network the client device is connected to, or are the clients looking for the PTR records 'b._dns-sd._udp' & 'lb._dns-sd._udp' with the same DNS suffix of the network the client is connected to?

    The Android, Windows will look for printers at a hard-coded URL: https://rpc.pc-printer-discovery:9164/printers (ChromeBook the URL is http://rpc.pc-printer-discovery:9163/printers). The OS will automatically append the search domain for you. If you setup the DNS delegation right, then this will return you a list of printer in JSON format.

    The first step of the 'DNS Discovery Checks' says to test the IPPS pointer records, but this record isn't mentioned prior to this point, is this record required? If so is this the first record the Mobility Print App looks for? Should this record be returned by the local DNS or the Mobility Print Server DNS -

    That record is "managed" by Mobility Print server itself (because it's under pc-printer-discovery subzone), so you should not add this record manually to your DNS server, you just need to setup the delegation subzone pc-printer-discovery under your search domain from your DNS server to Mobility Print server. That's it.
    If you have more questions, please ask.

  • LAYER 8 Global Moderator

    if they are looking for rpc.pc-printer-discovery.domain.tld

    And all your doing is pointing NS to the mobility then all that is needed in pfsense unbound would be a domain override for pc-printer-discovery.domain.tld.  What is the point of the PTRs? why can not just delegate _dns-sd._udp.domain.tld, etc.  unless your saying the mobility box won't respond to those - then why the need for the PTR at all  if they are just looking for


    Why can I Not just put in a host override of rpc.pc-printer-discovery and point it to the IP of the mobility box?  Which will serve up the xml? http(s)//:rpc.pc-printer-discovery.domain.tld:9164/printers

    Why do we need all this subdomain delegation.. unless they look for Othersuff.pc-printer-discovery.domain.tld

  • Thanks johnpoz for your input.
    Mobility Print supports many client device types: Android, Chromebook, Windows, iOS and macOS.
    If the customer need to:

    • Support Android and Chromebook, then you are right. They only need to put the rpc.pc-printer-discovery.domain.tld using host override feature of Unbound as you said and it should work.
    • Additionally support Windows, then they need to add another host override ipp.pc-printer-discovery.domain.tld to Unbound
    • To support iOS and macOS, our server need to implement the DNS-SD RFC ( because iOS and macOS using DNS-SD to discovery printers. So the two records b._dns-sd._udp.domain.tld PTR pc-printer-discovery.domain.tld and lb._dns-sd._udp.domain.tld PTR pc-printer-discovery.domain.tld are required.
      Here is a the DNS conversation of the iOS device with the DNS server (in this case Unbound) when it join a subnet with the search domain domain.tld and try to find the printers:
    • iOS devices: hey, in this search domain domain.tld, where should I browse for available services so that I can use?
        (then it sends the query b._dns-sd._udp.domain.tld PTR to Unbound)
    • Unbound: I don't know, but you can ask pc-printer-discovery.domain.tld
        (in this case we want Unbound to return the pc-printer-discovery.domain.tld as the data in the answer)
        Next, because the iOS device want to find printing services, which is defined as _ipps._tcp in DNS-SD RFC
    • The iOS device will ask: Can you give me a list of printers so that I can print to?
        (then it sends the query _ipps._tcp.pc-printer-discovery.domain.tld PTR TO Unbound and we expect Unbound forward this query to Mobility Print server. Mobility Print server will generate the answers returning to Unbound then Unbound returns the answers to the iOS device)

    This is how it works in the case of BIND and Windows DNS server.

    So it's just the matter to replicate this conversation by configuring Unbound.
    Input from Unbound expert is appricated!

    For more information about DNS-SD:

  • LAYER 8 Global Moderator

    That is great info thank you - how come that info is not listed on your site when looking to implement dns for your product?  Or is it and just didn't find that document?  If so could you provide link?

  • Just tried the host override in the web GUI.  Unbound doesn't seem to like the "dot" after the "rpc".  It returns an error in the staying "A valid hostname is specified, but the domain part should be omitted.

  • LAYER 8 Global Moderator

    you wouldn't put in a dot after

    The host would be rpc

    The domain would be pc-printer-discovery.domain.tld

    In your host override section.

  • Thanks for the clarification johnpoz.  Rookie mistake on my part.  I have all the records required for Android and two green check marks but I still can't seem to get the mobility app to find my printers.

  • LAYER 8 Global Moderator

    I have gotten a bit side tracked..  I will try and find some time here tmrw morning to bring up the mobility on box on one of my wifi segments with printer and papercut ng on different segment to get this working..  And will turn off the functionality on the printer directly, etc.

    Per this
    "Support Android and Chromebook, then you are right. They only need to put the rpc.pc-printer-discovery.domain.tld using host override feature of Unbound as you said and it should work."

    All you should need is the override pointing to the IP of your box running the mobility.. As long as the mobility has your printer(s) setup, etc.

  • I did exactly that.

    However, I'm not sure if the following makes a difference.

    -papercut and mobility print are on the same machine
    -printrr is on same subnet as above
    -android phone is on a different subnet

  • Hi thehammer86,
    Can you access the URL http://rpc.pc-printer-discovery:9163/printers from a browser on your Android device?
    It should return to you some JSON if you have some printers on your Mobility Print server.

  • It returns JSON if I add

    I must be missing something in my unbound config?

  • What is the search domain (DNS suffix) on your Android device?

  • I don't seem to have that option available in my wifi.  Running Android 6.0.1.

    I have my search domain set in my DHCP server on pfSense.

    I've also manually added it to my windows PCs.  For the windows PCs I know the search domain is working because I don't have to add the example.xom part when I do an NS lookup.

  • Hello everybody,

    I was wondering: was this issue solved in the end?
    We are facing the same problem configuring Resolver with the Mobility records.
    Checking the records using the Mobility application, we keep getting errors on the PTR records (the other 2 are working fine).
    Screenshot of working DNS entries would be really great!

  • Not yet with the Unbound resolver.  I ended up setting up a separate sever just for bind9.  I have everything working with that setup.

  • Is it possible to post the actual records you used (as an example/syntax)?
    Screenshot of dns settings?

  • LAYER 8 Global Moderator

    And what did you setup exactly – that has been the whole question... See you can for sure setup PTR records on unbound...

    The person from Mobility print was suppose to be answering those questions.. Which I do not recall ever got answered.

  • I can tell this:

    we are working on this issue with 2 experienced engineers. We have setup the 4 records as requested by the mobility print software.
    nslookup confirms the 4 records are active and correct. After checking the records with the mobility software, we keep getting an error on the PTR records.
    Fortunately we have an active Papercut license (it is a new install with 150 users), we created a support ticket…hope to get quick response.
    If anyone has fixed this PTR issue, I would really like to see the DNS entries...
    We also suggested a change to the mobility print client: a possibility to enter an ip-address instead of using the autodiscover option...

  • Posting my named.conf file shortly for bind. Just obfuscating the IPs and domains.

    Also, tech support was kind enough a few weeks ago to spend 2-3 hours on the phone with me to try an figure out the problem with unbound.  I found something in Mobility Print's log files that may be of use.

    Hold tight.

  • LAYER 8 Global Moderator

    From what I recall the client was not looking for what they said to create on their website.. But I can till you for fact is that unbound can create PTR records…

    Here is simple PTR query for IP on unbound... Answers just fine...

    > dig -x
    ; <<>> DiG 9.11.2 <<>> -x
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37198
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ; EDNS: version: 0, flags:; udp: 4096
    ;      IN      PTR
    ;; ANSWER SECTION: 1635  IN      PTR     Storage.local.lan.
    ;; Query time: 9 msec
    ;; SERVER:
    ;; WHEN: Tue Jan 16 11:31:45 Central Standard Time 2018
    ;; MSG SIZE  rcvd: 84

    What exactly is going to be queried and what should be the answer and we can validate whatever that something is can be entered into unbound.  But 100% for sure unbound can answer for a PTR query.

  • OK, let´s wait for the named.conf file thehammer86 was going to post…
    Also curious about this: "I found something in Mobility Print's log files that may be of use."

  • LAYER 8 Global Moderator

    I played with this for a bit - I could never get the client to actually do a ptr query like they said it should.. Their docs from what I remember are not very clear.  My trial ran out and attempted to run the mobility client on the same box the server was run on.

    I could try to setup it up again on some other machines - But once we know what actual query be it PTR or some other we can work out how to setup (if possible) for unbound to respond.  What I can tell you for 100% fact is the unbound can respond with a PTR… And NS records, so there is something missing in the puzzle here.

  • Here's the relevent config from a bare-metal machine I installed bind9 on.  Please make sure the domain and search list your dhcp server is handing out matches your domain for the mobility print entries.  Three different files below:

    options {
    directory "/etc/bind";
    pid-file "/var/run/bind/run/ /var/run/ /var/run/named/ /var/run/bind/run/named/";
    forwarders {;;
    forward first;
    allow-query {;

    zone "." {
    type hint;
    file "/etc/bind/db.cache";

    zone "" {
    type master;
    file "/var/lib/bind/192.168.rev";
    key rndc-key {
    algorithm hmac-md5;
    controls {
    inet port 953 allow {; } keys { rndc-key; };
    zone "" {
    type master;
    file "/var/lib/bind/";

    /var/lib/bind/192.168.rev  IN      SOA (
                            38400 )  IN      NS      IN      PTR


    $ttl 38400      IN      SOA (
                            38400 )      IN      NS        IN      A        IN      A  IN      NS        IN      PTR      IN      PTR

  • LAYER 8 Global Moderator

    Problem with that config is that your SOA for is

    But I take it cloud5 is the mobility server but its a domain ns, so do cloud1 and cloud5 the NS for have the same records?

    What does actually resolve too?  Since from your config I should be able to answer either cloud1 the SOA for or cloud5 for this A record.

  • Both PaperCutNG and the MobilityPrint Server are on the same machine (cloud5).  I can't seem to track down the log entry from MobilityPrint but its starting to come back to me now.  Something about the log error hinted at a permission issue with Unbound.  Because Unbound is set up as an authoritative name server for, it didn't like being an authoritative name server for the subdomain

    Does that help?

    I coundn't get any further with unbound so that's why I ditched it and went to bind.

  • LAYER 8 Global Moderator

    and when you do a query for, is this a A record query TXT, SRV what?

    Seems pretty pointless to set it up that way..  Why could you not just setup to be resolved by unbound directly? Be it A record or TXT or SRV, etc.  Seems stupid to do it that way.. I see no point to it.

    Actually goes against dns practice to delegate like that. Why sure could be sub domain and delegated to a different NS.  you would then look fror something like in the subdomain.

    Unbound is not actually meant to be an authoritative NS.. So that is prob why there are some issues - but you could for sure just put in the entry for directly in unbound so it could resolve it without having to delegate that to cloud5..

    Unbound is a validating, recursive, and caching DNS resolver.  It is not actually meant to be an authoritative NS… While it can answer specific records, from a local database - it has issues with cnames as well, etc.  Since its not actual designed to be an authoritative NS.

    But if the client wants to do a PTR query and then a query for that fqdn that is returned it for sure could answer a A, TXT, SRV record etc... for the actual fqdn that gets queried.

  • I just got feedback from Papercut support:


    I apologize but presently we don't have a documented method to set up the DNS records for Mobility Print using Unbound with PFSense. However, I do want to point out that other customers with PFsense routers that want to use DNS Discovery for Mobility Print have reached out to us to see if this is something that can be achieved.  I previously created a to-do item in our feature tracking system for our developers to take a look at whether this is feasible. I have also linked this support ticket to the feature request so that we can notify you by email in the future if this is something we are able to document. I can't say when we would be able to answer this however.

    In the short term I would also like to point out that there are several other methods for setting up Mobility Print, even for environments with multiple subnets and VLANs. For example, you can connect multiple network interfaces to your Mobility Print server and allow it to broadcast mDNS to advertise printers to clients in each network. Alternatively if your router supports Bonjour Forwarding, then you could set it up to allow mDNS traffic to pass from your server VLAN to your client VLANs.

    Let me know if you have any questions at all or if you would like to discuss some of the alternate methods I mentioned above.


  • LAYER 8 Global Moderator

    You could most likely just use the avahi package with pfsense.. It does mDNS/DNS-SD

  • LAYER 8 Netgate

    DNS Resolver Custom Options:

    local-zone: "" transparent
    local-data: "b.dns-sd._udp IN PTR"
    local-data: "lb.dns-sd._udp IN PTR"
    local-data: " IN NS"
    local-data: " IN A"

    Test queries:

    [2.4.2-RELEASE][]/var/unbound: dig +short +search @localhost PTR b.dns-sd._udp
    [2.4.2-RELEASE][]/var/unbound: dig +short +search @localhost PTR lb.dns-sd._udp
    [2.4.2-RELEASE][]/var/unbound: dig +short +search @localhost NS pc-printer-discovery
    [2.4.2-RELEASE][]/var/unbound: dig +short +search @localhost A print-server-host

    From there it is up to the client to ask the DNS server on the mobility print server at whatever it needs to ask about the pc-printer-discovery zone.

    It looks to me like this should work. It implies the client is pointed EXCLUSIVELY at unbound (and/or a similarly-configured server) and has a correct search domain set for "".

    I did not try to get a Mobility Print environment working.

  • LAYER 8 Netgate

    Note that unbound agrees with my prior assessment of the wackiness of the name-keyed PTR records. They have a local-data-ptr option for setting PTR records:

    local-data-ptr: "IPaddr name"
                Configure local data shorthand for a PTR record with the  reversed
                IPv4  or  IPv6  address and the host name.  For example "
      ".  TTL can be  inserted  like  this:  "2001:DB8::4

    If you try something like:

    local-data-ptr: "b.dns-sd._udp"

    It barfs with:

    The generated config file cannot be parsed by unbound. Please correct the following errors:
    [1516213033] unbound-checkconf[27521:0] error: syntax error: cannot parse address: b.dns-sd._udp
    /var/unbound/test/unbound.conf:86: error: local-data-ptr could not be reversed
    read /var/unbound/test/unbound.conf failed: 1 errors in configuration file

  • LAYER 8 Global Moderator

    Where the problem is I do not believe the client follows through with looking up

    When NS is authoritative its different - same issue with a cname in unbound.  You can for sure put in a cname record.. But it doesn't follow through and finish, its up the client to follow the query when the not using authoritative ns, etc.

    If the client actually does a query for you could just put that record in unbound directly..

  • LAYER 8 Netgate

    It looks to me like is a subdomain. Those records/that zone will be found on the mobility print server itself.

    At least that's what it looks like to me.

    I am really not in the mood to install it and see.

    It looks like the above config is what is necessary to get the records papercut say need to be there in there.

  • LAYER 8 Global Moderator

    "It looks like the above config is what is necessary to get the records papercut say need to be there in there."

    Yeah went through that while back - doesn't work, because yes is a subdomain delegation… Its hokey setup to be sure.. Trying to put these records into unbound make no sense at all..  The whole thing is designed for the authoritative NS for the domain in question which is not what unbound running on pfsense is

    You really should be able to get away with a domain override for the domain

    Point via NS record to the mobility print server let the client do whatever it wants via a domain override.

    I would think it just much easier to setup avahi..

    If user really wants to use this setup and run it on pfsense, then they should be using the bind package that gives them full authoritative nameserver software on pfsense - with a gui to boot to manage ;)

  • Unfortunately, I already tried avahi. The mobility app under android and windows returns an error that I haven't been able to sort out with the Paperacut team.

  • LAYER 8 Netgate

    Then pcap the DNS traffic and see where the breakdown is.

  • LAYER 8 Global Moderator

    Can for sure make unbound answer pretty much anything that gets queried for.. But its not going to do some of the stuff an actual authoritative NS does for a zone its authoritative for, etc.

    If you do a sniff and see what is queried - pretty freaking sure can make unbound answer with the answer you want for the specific query and type.

  • I can confirm Avahi is not working. Just tested it.
    The mobility print setup does not find any printers in another VLAN.