RFC 6303 and bind 9.9.0
Mark Andrews
marka at isc.org
Thu Mar 1 03:20:56 UTC 2012
Mark Andrews writes:
>
> 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>";
Missed a underscore.
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
--
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