named.conf restored to hint zone for the root by default
Mark_Andrews at isc.org
Thu Aug 2 19:12:16 PDT 2007
> Jeremy Chadwick wrote:
> > On Thu, Aug 02, 2007 at 01:49:39PM -0700, Doug Barton wrote:
> >> Oliver Fromme wrote:
> >>> Hi,
> >>> Just for the record, I like the current solution, i.e. default
> >>> being a "hint" zone, and slave zones being commented out, ready
> >>> to be used for those who know what they're doing.
> > I second this. And although I like Doug's use of AXFR from the
> > roots (like others reported, it definitely speeds things up), I
> > also want to continue to respect rootserver operators and dns-ops's
> > concerns.
> Something that I haven't mentioned but I think is probably worth
> pointing out is that at least for Paul Vixie (operator of f.root) the
> concern is not for the root servers, it's for potential problems on
> the client side. The following is from
> i remain perplexed about the general perception that AXFR is bad for a
> root name server. it's not. RFC1035 describes some resource
> management techniques for TCP state blobs, which the root servers
> follow. the chance that an AXFR will be blown away by a TCP query is
> very high, and so, it's bad for clients to make production use of AXFR
> from busy servers.i remain perplexed about the general perception that
> AXFR is bad for a root name server. it's not. RFC1035 describes some
> resource management techniques for TCP state blobs, which the root
> servers follow. the chance that an AXFR will be blown away by a TCP
> query is very high, and so, it's bad for clients to make production
> use of AXFR from busy servers.
> The 3 zones in question are actually really small:
> -rw-r--r-- 1 bind wheel 1.6K Aug 2 14:25 arpa.slave
> -rw-r--r-- 1 bind wheel 23K Aug 2 14:24 in-addr.arpa.slave
> -rw-r--r-- 1 bind wheel 64K Aug 2 14:30 root.slave
> so I'm not sure how much of a problem this is in practice.
I also suspect that using accept filters will mitigate some
of the problem. If someone was to write a DNS accept filter
that would help.
> > So offering the template configuration to do so, but not enabling
> > it by default, is a very good thing. Thank you for doing this,
> > Doug.
> Glad to do it. I'm also glad to see that this topic is getting serious
> This .signature sanitized for your protection
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the freebsd-stable