[bind10-dev] allow/deny xfr requests by default?

[Mark Andrews]

In message <m2sjijua0a.wl%jinmei at isc.org>, JINMEI Tatuya / =?ISO-2022-JP?B?GyRC
P0BMQEMjOkgbKEI=?= writes:
> At Thu, 9 Feb 2012 12:16:23 +0100,
> Shane Kerr <shane at isc.org> wrote:
> 
> > > Do people have an opinion about whether BIND 10 should allow/deny
> > > AXFR/IXFR requests by default?  Currently b10-xfrout allows xfr
> > > requests by default just like BIND 9 does so.
> > 
> > > There's even (at least an instance of) a root server that accepts xfr
> > > requests from anyone: F.
> > 
> > Well, the "security" motivation hardly applies for root servers, since
> > the zone is published in several ways. I'm not sure why any of the root
> > servers block XFR actually - it makes little sense, although I suppose
> > it is one less code path that can introduce bugs.
> 
> Perhaps one compelling reason for disabling xfr by default in terms of
> "security" is this one (less code path to bugs).  In practice an xfr
> is only needed by secondary servers, so I see the point in the
> argument it makes sense to restrict the access to "the code" that
> provides xfr, not necessarily the zone content provided by the xfr.
> 
> BTW, I found this in RFC5936:
> 
>    A general-purpose implementation SHOULD NOT have a default policy for
>    AXFR requests to be "open to all".  For example, a default could be
>    to restrict transfers to addresses selected by the DNS
>    administrator(s) for zones on the server.
> (In section 5)
> 
> It doesn't explain why, but if we want to conform to the "SHOULD NOT"
> as a "reference implementation" (regardless of whether it makes sense
> or not), the choice will be to deny it by default.

This is a religious issue to some and it just wan't worth fighting about
and make little or no difference except to debugging.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org