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