Problem w/ Forwarding Zone in Caching-Only Config

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problem w/ Forwarding Zone in Caching-Only Config

Michael W. Fleming
We're setting up a wireless printing service that uses
Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's
own dns server for a private, on-campus only zone (presto.). We're
running bind 9.9 with a master server, three slaves and two caching-only
servers (anycasted to 136.168.255.2). We have the following in
named.conf (as per the vendor) on the caching-only servers.

zone "presto." {
      type forward;
      forward only;
      forwarders { 136.168.2.66; };
};

I manually added some required dns entries in our zone (as per vendor),
e.g.:

dig +short ptr b._dns-sd._udp.0.43.168.136.in-addr.arpa
0.43.168.136.dnssd.presto.

However, when I query the presto address, the query is sent to the
roots, not the presto server:

$ dig ptr 0.43.168.136.dnssd.presto.

; <<>> DiG 9.11.1 <<>> ptr 0.43.168.136.dnssd.presto.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46445
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.43.168.136.dnssd.presto. IN PTR

;; AUTHORITY SECTION:
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017062002
1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 136.168.255.2#53(136.168.255.2)
;; WHEN: Tue Jun 20 10:04:25 PDT 2017
;; MSG SIZE  rcvd: 129

I am by no means a bind wizard. Any help would be appreciated.

Many thanks.

--
Michael Fleming, IT Networking, Datacenter & Telecom, CSU, Bakersfield
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Problem w/ Forwarding Zone in Caching-Only Config

Darcy Kevin (FCA)
You have a trailing dot in the zone definition. It makes a difference.

Personally, I wouldn't use forwarding at all, and I'd build this for scalability. Define a master zone for, say, 168.136.dnssd.presto, and then delegate from that to whatever address ranges you deploy Presto to in the future (43.168.136.dnssd.presto today, maybe 99.168.136.dnssd.presto later). When I say "define a master zone", of course, I mean do that on one of the servers. The other one would then slave it.

Note that if you have global forwarding enabled, and if you're using any zone type other than "forward" (e.g. master, slave, stub), you'll need to disable the global forwarding for the part of the namespace you want to resolve internally, by putting "forwarders { };" in the relevant zone definition.

{RANT ON}

This Presto thing is a terrible product, from a DNS perspective, if (as appears from the admin guide at https://download.collobos.com/en/presto2/files/administrator_guide.pdf) there is no option to set the domain name for resolution of resource names. It seems dnssd.presto is hard-coded into the product, yet generally speaking, it's a bad practice to make TLDs up out of thin air and use them an IP network. A TLD that is "private" today (as .presto happens to be) can become "public" tomorrow, if ICANN decides to award a TLD assignment to, say, the Presto which makes kitchen appliances and gadgets (https://www.gopresto.com/), which is certainly *much* more well-known than the networking company, and thus has a stronger claim to the TLD. Suddenly, then, your devices could be confused between the internal and external versions of the TLD. This is a mistake *many* administrators regretted later.

It is better to use a subdomain of one's *unique*, publically-registered domain name. But, apparently, this product doesn't allow that.

{RANT OFF}
                                                                                                - Kevin



-----Original Message-----
From: bind-users [mailto:[hidden email]] On Behalf Of Michael W. Fleming
Sent: Tuesday, June 27, 2017 12:14 PM
To: [hidden email]
Subject: Problem w/ Forwarding Zone in Caching-Only Config

We're setting up a wireless printing service that uses Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's own dns server for a private, on-campus only zone (presto.). We're running bind 9.9 with a master server, three slaves and two caching-only servers (anycasted to 136.168.255.2). We have the following in named.conf (as per the vendor) on the caching-only servers.

zone "presto." {
      type forward;
      forward only;
      forwarders { 136.168.2.66; };
};

I manually added some required dns entries in our zone (as per vendor),
e.g.:

dig +short ptr b._dns-sd._udp.0.43.168.136.in-addr.arpa
0.43.168.136.dnssd.presto.

However, when I query the presto address, the query is sent to the roots, not the presto server:

$ dig ptr 0.43.168.136.dnssd.presto.

; <<>> DiG 9.11.1 <<>> ptr 0.43.168.136.dnssd.presto.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46445 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.43.168.136.dnssd.presto. IN PTR

;; AUTHORITY SECTION:
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017062002
1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 136.168.255.2#53(136.168.255.2) ;; WHEN: Tue Jun 20 10:04:25 PDT 2017 ;; MSG SIZE  rcvd: 129

I am by no means a bind wizard. Any help would be appreciated.

Many thanks.

--
Michael Fleming, IT Networking, Datacenter & Telecom, CSU, Bakersfield _______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem w/ Forwarding Zone in Caching-Only Config

Bind-Users forum mailing list
In reply to this post by Michael W. Fleming
On 6/27/17 12:13 PM, Michael W. Fleming wrote:

> We're setting up a wireless printing service that uses
> Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's
> own dns server for a private, on-campus only zone (presto.). We're
> running bind 9.9 with a master server, three slaves and two caching-only
> servers (anycasted to 136.168.255.2). We have the following in
> named.conf (as per the vendor) on the caching-only servers.
>
> zone "presto." {
>        type forward;
>        forward only;
>        forwarders { 136.168.2.66; };
> };

on a slightly side note, i'd use a stub or static-stub zone for this,
not a forward zone.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem w/ Forwarding Zone in Caching-Only Config

Mark Andrews
In reply to this post by Michael W. Fleming

There should be NO need for this if you setup service discovery
properly for the network.  If done properly you go from IP address
and netmask to a delegated forward domain which accepts update
requests from the devices on the network.  Unfortunately the Presto
documentation sucks when it comes to explaining how to setup service
discovery properly.  They hard code "presto" in their examples
rather than saying to use a forward zone you control.

See https://tools.ietf.org/html/rfc6763 for details of how it is
designed to work.  Section 11 shows how to go from IP address and
netmask to the forward domain where the _dns-sd._udp subdomains
reside.

lb._dns-sd._udp.0.43.168.136.in-addr.arpa PTR <A DOMAIN YOU CONTROL>

e.g.
lb._dns-sd._udp.0.43.168.136.in-addr.arpa. PTR example.com.

and

b._dns-sd._udp.example.com. PTR example.com.
b._dns-sd._udp.example.com. PTR dnssd.example.com.
dr._dns-sd._udp.example.com. PTR dnssd.example.com.
lb._dns-sd._udp.example.com. PTR example.com.
lb._dns-sd._udp.example.com. PTR dnssd.example.com.

zone dnssd.example.com {
        ....
        allow-update { 136.168.43.0/<length>; };
};

Now if the devices are truly capable of doing service discovery
properly this is all you should need to do beyound rebooting the
devices to get them to register themselves.  Hopefully I haven't
left anything out or got something wrong as I am yet to do this
in real life.

Mark

In message <[hidden email]>, "Michael W. Fleming
" writes:

> We're setting up a wireless printing service that uses
> Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's
> own dns server for a private, on-campus only zone (presto.). We're
> running bind 9.9 with a master server, three slaves and two caching-only
> servers (anycasted to 136.168.255.2). We have the following in
> named.conf (as per the vendor) on the caching-only servers.
>
> zone "presto." {
>       type forward;
>       forward only;
>       forwarders { 136.168.2.66; };
> };
>
> I manually added some required dns entries in our zone (as per vendor),
> e.g.:
>
> dig +short ptr b._dns-sd._udp.0.43.168.136.in-addr.arpa
> 0.43.168.136.dnssd.presto.
>
> However, when I query the presto address, the query is sent to the
> roots, not the presto server:
>
> $ dig ptr 0.43.168.136.dnssd.presto.
>
> ; <<>> DiG 9.11.1 <<>> ptr 0.43.168.136.dnssd.presto.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46445
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;0.43.168.136.dnssd.presto. IN PTR
>
> ;; AUTHORITY SECTION:
> . 86400 IN SOA a.root-servers.net. nstld.veris
> ign-grs.com. 2017062002
> 1800 900 604800 86400
>
> ;; Query time: 2 msec
> ;; SERVER: 136.168.255.2#53(136.168.255.2)
> ;; WHEN: Tue Jun 20 10:04:25 PDT 2017
> ;; MSG SIZE  rcvd: 129
>
> I am by no means a bind wizard. Any help would be appreciated.
>
> Many thanks.
>
> --
> Michael Fleming, IT Networking, Datacenter & Telecom, CSU, Bakersfield
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem w/ Forwarding Zone in Caching-Only Config

Tony Finch
Mark Andrews <[hidden email]> wrote:
>
> See https://tools.ietf.org/html/rfc6763 for details of how it is
> designed to work.  Section 11 shows how to go from IP address and
> netmask to the forward domain where the _dns-sd._udp subdomains
> reside.
>
> lb._dns-sd._udp.0.43.168.136.in-addr.arpa PTR <A DOMAIN YOU CONTROL>

At Cambridge my colleagues have an experimental DNS-SD setup for printing
from eduroam. Rather than the reverse DNS option, we're using the forward
option where clients get the domain from DHCP, so I just needed to add a
few records to the DNS and try not to worry too much about how competent
the print server is at DNS. The forward option greatly simplifies wireless
subnet allocation, and is conveniently v4/v6 agnostic.

$ORIGIN private.cam.ac.uk
b._dns-sd._udp.wireless PTR pc-printer-discovery.wireless
lb._dns-sd._udp.wireless PTR pc-printer-discovery.wireless
pc-printer-discovery.wireless NS papercut-test.ds

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Northerly or northeasterly 4, occasionally 5 in Viking.
Slight or moderate. Fair. Good.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem w/ Forwarding Zone in Caching-Only Config

Mark Andrews

In message <[hidden email]>, Tony Finch writes:

> Mark Andrews <[hidden email]> wrote:
> >
> > See https://tools.ietf.org/html/rfc6763 for details of how it is
> > designed to work.  Section 11 shows how to go from IP address and
> > netmask to the forward domain where the _dns-sd._udp subdomains
> > reside.
> >
> > lb._dns-sd._udp.0.43.168.136.in-addr.arpa PTR <A DOMAIN YOU CONTROL>
>
> At Cambridge my colleagues have an experimental DNS-SD setup for printing
> from eduroam. Rather than the reverse DNS option, we're using the forward
> option where clients get the domain from DHCP, so I just needed to add a
> few records to the DNS and try not to worry too much about how competent
> the print server is at DNS. The forward option greatly simplifies wireless
> subnet allocation, and is conveniently v4/v6 agnostic.

The proceedure also works for IPv6 where for 99.99% of networks it
will be the reverse of the leading 64 bits.

e.g.
        lb._dns-sd._udp.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA

but these are all alternatives.

> $ORIGIN private.cam.ac.uk
> b._dns-sd._udp.wireless PTR pc-printer-discovery.wireless
> lb._dns-sd._udp.wireless PTR pc-printer-discovery.wireless
> pc-printer-discovery.wireless NS papercut-test.ds
>
> Tony.
> --
> f.anthony.n.finch  <[hidden email]>  http://dotat.at/  -  I xn--zr8h punycode
> Viking, North Utsire: Northerly or northeasterly 4, occasionally 5 in Viking.
> Slight or moderate. Fair. Good.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Loading...