Problem w/ Forwarding Zone in Caching-Only Config

[Mark Andrews]

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 <fd2d7867-c934-de08-9e4b-90a0d07f8b08 at csub.edu>, "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
> bind-users at lists.isc.org
> 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: marka at isc.org