On Oct 8, 2013, at 2:13 PM, Mark Andrews wrote: > > In message <93fdc4db-8835-482d-8b7d-7b58d09d5...@uci.edu>, Con Wieland writes: >> I am still trying to understand the empty zones and bind 9.8.5-P2 >> behaviour. The default shows 332 zones. With empty-zones-enable no; I >> get 253 zones, but with empty-zones-enable yes: I get 349 >> >> The difference between empty zones yes and no is the addition of zones: >> >> 10.IN-ADDR.ARPA >> & 16.172.IN-ADDR.ARPA thru 31.172.IN-ADDR.ARPA > > There are a lot more zone than these enabled by empty-zones-enable. See > the ARM for you version of named for the full list.
I understand, I am reconciling off the list in the ARM (great resource). And these are the additional ones that show up with the configuration set to: empty-zones-enable yes It was my understanding that the default configuration was empty-zones-enable yes so I am trying to understand the difference between explicitly setting it in named.conf and the default with it set to empty-zones-enable no I only have 253 zones so it is picking up the other ones correctly just not the range I listed above. > >> I am confused by the difference between these configurations. >> >> Also my understanding was that the empty zones prevent queries for these >> zones to the root servers and would be handled by the local nameserver. >> However with zones-enable yes: >> >> and a dig 10.IN-ADDR-ARPA > > Fix your typo. It is "10.IN-ADDR.ARPA" not "10.IN-ADDR-ARPA". (period vs > dash between "ADDR" and "ARPA") as you point out when I put the CORRECT info, I get: ; <<>> DiG 9.8.5-P2 <<>> 10.IN-ADDR.ARPA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55316 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.IN-ADDR.ARPA. IN A ;; AUTHORITY SECTION: 10.IN-ADDR.ARPA. 86400 IN SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 ;; Query time: 3 msec ;; SERVER: 128.195.182.10#53(128.195.182.10) ;; WHEN: Tue Oct 08 14:27:55 PDT 2013 ;; MSG SIZE rcvd: 68 so it would appear to be doing the correct thing. However dig +trace still goes to the root servers. The man page says: Toggle tracing of the delegation path from the root name servers for the name being looked up. so that would appear to be the right response correct? thanks con > >> I get the same answer as without the empty zone: >> >> ; <<>> DiG 9.8.5-P2 <<>> 10.IN-ADDR-ARPA >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43978 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;10.IN-ADDR-ARPA. IN A >> >> ;; AUTHORITY SECTION: >> . 10416 IN SOA a.root-servers.net. >> nstld.verisign-grs.com. 2013100801 1800 900 604800 86400 >> >> ;; Query time: 5 msec >> ;; SERVER: 128.195.182.10#53(128.195.182.10) >> ;; WHEN: Tue Oct 08 13:08:33 PDT 2013 >> ;; MSG SIZE rcvd: 108 >> >> >> which is querying the root servers. >> >> Any help in understanding this or pointing me in the right direction >> would be greatly appreciated. >> >> Con Wieland >> Office of Information Technology >> University of California at Irvine >> >> >> On Sep 13, 2013, at 11:42 PM, Mark Andrews wrote: >> >>> >>> Well they are documented in the current ARM. >>> >>> Named has some built-in empty zones (SOA and NS records only). >>> These are for zones that should normally be answered locally >>> and which queries should not be sent to the Internet's root >>> servers. The official servers which cover these namespaces >>> return NXDOMAIN responses to these queries. In particular, these >>> cover the reverse namespaces for addresses from RFC 1918, RFC >>> 4193, RFC 5737 and RFC 6598. They also include the reverse >>> namespace for IPv6 local address (locally assigned), IPv6 link >>> local addresses, the IPv6 loopback address and the IPv6 unknown >>> address. >>> >>> The address ranges are reserved in RFC 6598. >>> >>> http://ftp.isc.org/isc/bind9/cur/9.6/doc/arm/Bv9ARM.pdf >>> http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.pdf >>> http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf >>> >>> Mark >>> >>> In message <b0960a7d-28e4-44c5-b094-048a605a8...@uci.edu>, Con Wieland >> writes: >>>> I upgraded on of our servers from 9.6-ESV-R8 to 9.8.5-P2 and I am >> showing 66 >>>> more zones than I had before. >>>> >>>> I now have: >>>> >>>> < ; Zone dump of '64.100.IN-ADDR.ARPA/IN/internal' >>>> < ; >>>> < ; not implemented >>>> >>>> thru >>>> >>>> < ; Zone dump of '127.100.IN-ADDR.ARPA/IN/internal' >>>> < ; >>>> < ; not implemented >>>> >>>> when I do an rndc dumpdb -zones >>>> >>>> >>>> I do not have any xxx.100.IN-ADDR.ARPA zones configured. And these do >> not sho >>>> w up as empty zones that get created from the documentation I found >>>> >>>> any ideas would be greatly appreciated >>>> >>>> Con WIeland >>>> _______________________________________________ >>>> 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 >> > > -- > 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