BIND 9.4.x empty zones

[Mark Andrews]

> I have been looking at the new "built-in empty zone" stuff in 9.4.x
> (specific experiments with 9.4.2rc1), partly with a view to getting
> our production 9.3.x setup in line so that the transition is not too
> traumatic. Comparing them with the "server information" (class CHAOS)
> "version.bind" zone and friends is also instructive.

	You may want to look at the draft-ietf-dnsop-default-local-zones
	drafts and discussions in the dnsop working group.

> Here is a summary of what I have found so far, with some questions
> arising.
> 
> 1. SOA.mname (and single NS record) has the same name as the zone
>     (modifiable for the empty-zones by the "empty-server" option,
>     fixed for the server-info zones). Does this actually make sense?
>     Maybe it's just harmless.

	The default is answered by the empty zone itself.
 
> 2. SOA.rname is "." for empty-zones (modifiable by the "empty-contact"
>     option) but "hostmaster.[zone-name]" for the server-info zones
>     (not modifiable). I actually rather like the idea of "." as
>     indicating "there isn't any contact address, get lost", but can
>     that be justified from the RFCs?

	There was lots of discussion over this one.

> 3. The remaining SOA parameters are fixed at "0 28800 7200 604800 86400"
>     for both sorts of zones. I suppose only the negative TTL might be
>     something one could conceivably want to modify.
> 
> 4. Queries against the empty-zones seem always to be allowed, while those
>     against the server-info zones respect the "allow-query" setting in
>     the "options" statement. This seems to me to be a bug.

	This one needs to be addressed.
 
> 5. Zone transfers on either sort of zone seem never to be allowed, but
>     exactly what errors one gets and how or whether they depend on the
>     "allow-transfer" setting in the "options" statement is currently
>     still obscure to me.
> 
> One additional issue that occurs to me is whether onew should try and
> make one's almost-empty zones "localhost" and "0.0.127.in-addr.arpa"
> (traditional here, at least, but maybe one should go with blocking
> the whole of "127.in-addr.arpa" in line with 9.4.x) look like the new
> empty-zones in respect of SOA & NS contents.

	127/8 is how the address space is allocated.
 
> And also, why doesn't the built-in empty-zones list include
> "0.in-addr.arpa" and "255.in-addr.arpa" (also traditional here)
> or at least enough to cover reverse lookups on IPv4 addresses
> 0.0.0.0 and 255.255.255.255?

	0.IN-ADDR.ARPA is just missing.
	255.255.255.255.IN-ADDR.ARPA covers the broadcast address
 
> That's enough for now ;-)
> 
> -- 
> Chris Thompson
> Email: cet1 at cam.ac.uk
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org