RFC 6303 and bind 9.9.0

[Mark Andrews]

In message <7610864823C0D04D89342623A3ADC9DE2E339B1F at hopple.countryday.net>, "S
pain, Dr. Jeffry A." writes:
> >> Changing the second line ('@ 10800 IN NS @') to '@ 10800 IN NS localhost=
> .' eliminates the errors.
> > The built in empty zone processing is aware of the special case of NS rec=
> ords without address records.  The generic zone processing rules treat this=
>  as a error condition.
> 
> Just for clarification, do I understand correctly that if none of the empty=
>  zones described in RFC 6303 are set up explicitly in the bind 9.9.0 config=
> uration file, then bind 9.9.0 will process them as such anyway using built-=
> in generic zone processing rules?

Yes.  It does do some sanity checks to work out if it is sensible
to enable them.  You can disable them individually or as a group.
You can force them to enabled with.

zone <name> {
	type master;
	database "builtin empty <server> <contact>";
	dialup no;
	notify no;
};

Note: you are still subject to NS must have a address checks doing
it this way.

> >> (Empty zone 255.255.255.255.in-addr.arpa (RFC 6303) vs. 255.in-addr.arpa=
> . (RFC 1912)
> > BCP 163 (RFC 6303) is based on BCP 153 (RFC 5735) which trumps RFC 1912.
> 
> RFC 5735 allocates 240.0.0.0/4, which would include 255.0.0.0/8 except for =
> 255.255.255.255, as "Reserved for Future Use". Based on this, it makes sens=
> e to me not to have an empty zone for 255.in-addr.arpa.
> 
> Thanks. Jeff.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org