Re: Problem w/ Forwarding Zone in Caching-Only Config
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 domain where the _dns-sd._udp subdomains > > reside. > > > > lb._dns-sd._udp.0.43.168.136.in-addr.arpa PTR > > 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.wirelessPTR 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 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: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem w/ Forwarding Zone in Caching-Only Config
Mark Andrewswrote: > > 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 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 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem w/ Forwarding Zone in Caching-Only Config
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 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/; }; }; 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, "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@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: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem w/ Forwarding Zone in Caching-Only Config
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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Problem w/ Forwarding Zone in Caching-Only Config
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-boun...@lists.isc.org] On Behalf Of Michael W. Fleming Sent: Tuesday, June 27, 2017 12:14 PM To: bind-users@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@lists.isc.org 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users