empty zones and higher zone count after upgrading
Steven Carr
sjcarr at gmail.com
Tue Oct 8 21:39:06 UTC 2013
+trace ALWAYS goes to the root servers. It will bypass your DNS server
completely.
Steve
On 8 October 2013 22:37, Con Wieland <cwieland at uci.edu> wrote:
>
> 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
>
> _______________________________________________
> 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
More information about the bind-users
mailing list