empty zones and higher zone count after upgrading

[Mark Andrews]

In message <ADC42079-57B7-498C-BD1C-DF836057E31F at uci.edu>, Con Wieland writes:
> 
> On Oct 8, 2013, at 2:13 PM, Mark Andrews wrote:
> 
> >=20
> > 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
> >>=20
> >> The difference between empty zones yes and no is the addition of =
> zones:
> >>=20
> >> 10.IN-ADDR.ARPA
> >> & 16.172.IN-ADDR.ARPA thru 31.172.IN-ADDR.ARPA
> >=20
> > 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

The explict setting tells named that you *know* about empty-zones
so named enables the RFC 1918 empty zones.  These were disabled in
earlier maintenance releases and to avoid a POLA violation named
uses the explict setting to tell it that enabling RFC 1918 empty
zone should not cause unexpected problems.

With BIND 9.9.0 onwards named treats the RFC 1918 empty zones the
same as any other empty zone as we expect operators to read the
change notes when changing between different functional releases,
e.g. 9.8.x to 9.9.x.

> 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.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org