+trace ALWAYS goes to the root servers. It will bypass your DNS server completely.
Steve On 8 October 2013 22:37, Con Wieland <cwiel...@uci.edu> wrote: > > 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 _______________________________________________ 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
