FreeBSD violates RFC2870 [was: Re: Problems with named default configuration in 6-STABLE]

[Volker]

On 07/17/07 13:45, Jeremy Chadwick wrote:
> On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote:
>> As I think having a default to hint root zone is better, I'll
>> file a PR about that.
> 
> Which leads me to ask:
> 
> Why hasn't anyone recommended using stub zones for this?  It seems
> the goal is to cache NS records from the rootservers, and stub
> zones don't utilise AXFR/IXFR.
> 

Jeremy,

good point.

According to Bind9 ARM:

> A stub zone is similar to a slave zone, except that it replicates
> only the NS records of a master zone instead of the entire zone.
> Stub zones are not a standard part of the DNS; they are a feature
> specific to the BIND implementation.
> 
> Stub zones can be used to eliminate the need for glue NS record in
> a parent zone at the expense of maintaining a stub zone entry and a
> set of name server addresses in named.conf. This usage is not
> recommended for new configurations, and BIND 9 supports it only in
> a limited way. In BIND 4/8, zone transfers of a parent zone
> included the NS records from stub children of that zone. This meant
> that, in some cases, users could get away with configuring child
> stubs only in the master server for the parent zone. BIND 9 never
> mixes together zone data from different zones in this way.
> Therefore, if a BIND 9 master serving a parent zone has child stub
> zones configured, all the slave servers for the parent zone also
> need to have the same child stub zones configured.
> 
> Stub zones can also be used as a way of forcing the resolution of a
> given domain to use a particular set of authoritative servers. For
> example, the caching name servers on a private network using
> RFC1918 addressing may be configured with stub zones for
> 10.in-addr.arpa to use a set of internal name servers as the
> authoritative servers for that domain.

Using the root zone as type "stub" should work (even while ARM says
it's not DNS standard). But ARM says, it's not recommended for new
configurations (I have no idea why it does state that).

On the other side, the old (outfashioned?) way of caching the root
zone NS records worked for years and will continue to work. To get a
fresh zone NS record copy is easy by using 'dig @a.root-servers.net NS
. >/etc/namedb/named.root` and you're done.

If anything is in /etc/namedb/named.conf, it needs to be edited
manually (or overwritten by mergemaster).

The possibilities for the root zone are:

1) make root zone of type hint, cache root NS records in
/etc/namedb/named.root (the way it was for years and is reliable)

2) make root a slave zone and rely only on 5 root DNS servers
(named.conf modification required if root zone changes) - be aware of
the RFC2870 regulations

3) make root zone a stub zone and configure all 13 root servers in
named.conf - be aware of Bind9 ARM warnings

Currently all three ways will work.

It's not the question what works or not. To me the question is, what
should be the (reliable) default configuration even for the
inexperienced user? An experienced admin will ever be able to solve
anything DNS related and find a way if things won't work and is free
to change to a configuration serving him best. The default
configuration should always and ever just work.

Volker