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

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/09/2012 01:54 PM, Dave Hart wrote:
>> 
>> I would say deny requests by default.
>> 
>> We live in a security-conscious world, so I think that the
>> general philosophy should be "anything that is not explicitly
>> allowed is denied" rather than "anything that is not explicitly
>> denied is allowed".
> 
> We live in a world of idiots who think they understand security
> but have a lack of foresight.  Deny all, then allow only what's
> needed to unbreak the items you care about, is a great recipe in
> firewalls, no? I'm sure NIST would say so.  So would the credit
> card company auditors.  In some cases, it may even be defensible
> (where the zone is not in fact open to public querying, or where
> there is an active firewall administrator paying attention to
> breakage and acting on it). But it's also a great recipe for people
> writing new protocols to do everything on top of HTTP and HTTPS,
> because those are the least impeded by idiots with firewalls.  If
> you want an internet reduced to HTTP(S), go for it.  I don't.
> 

IMO there is quite a difference between defaults for features that can
specifically be disabled (either for security or other reasons), and
software that drops or denies things 'by default' because it simply
does not understand them (usually in the name of security too).

DNS itself is an example here too; the later expansions have often had
to go through weird and annoying hoops in order to be backwards
compatible. Not only to actually work with outdated implementations,
but also often because extensions were denied by firewalls and
gateways that mucked with things they shouldn't have. The former tends
to be a result of not putting future expansions in a protocol, the
latter a result of software reaching out of its scope.

However, whether denying XFR by default is not such a case, and though
I agree with the sentiment here, IMO it should not be applicable for
this choice. Even if someone comes up with a nice shiny new thing to
build on top of XFR (I can actually think of a few), this would most
probably still be something that needs to be set up anyway, and could
never rely on it being available for every zone on every server.

I myself don't even think of allowing XFR to be a security choice in
the first place, btw. I allow it on my own zones, unless there is a
technical reason not to. I tend to disallow it on the zones I
secondary for other people (it's their choice). Of course, I don't
have to deal with contracts on the data on my personal servers :)

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8zyPcACgkQ4nZCKsdOncVYfQCgjQ8fq2a90/bGcNl5pGxBeCZ8
L5gAn0Uz5+6LeETjJDq4EaApgbROIAEv
=2xjl
-----END PGP SIGNATURE-----