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

2017-06-28 Thread Mark Andrews
In message , Tony Finch writes: > Mark Andrews 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

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

2017-06-28 Thread Tony Finch
Mark Andrews 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

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

2017-06-27 Thread 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

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

2017-06-27 Thread btb via bind-users
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

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

2017-06-27 Thread 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