Problem w/ Forwarding Zone in Caching-Only Config

Darcy Kevin (FCA) kevin.darcy at fcagroup.com
Tue Jun 27 22:37:01 UTC 2017


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:bind-users-bounces at lists.isc.org] On Behalf Of Michael W. Fleming
Sent: Tuesday, June 27, 2017 12:14 PM
To: bind-users at lists.isc.org
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
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


More information about the bind-users mailing list