empty zones and higher zone count after upgrading

Con Wieland cwieland at uci.edu
Tue Oct 8 21:37:05 UTC 2013


On Oct 8, 2013, at 2:13 PM, Mark Andrews wrote:

> 
> In message <93FDC4DB-8835-482D-8B7D-7B58D09D5930 at 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-048A605A8B8B at 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 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
>> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list