NSEC3 support for BIND

[Mark Andrews]

> On Fri, Nov 09, 2007 at 08:16:43AM +0100,
>  Måns Nilsson <mansaxel at kthnoc.net> wrote 
>  a message of 23 lines which said:
> 
> > Zone enumeration is normally not a problem. If you experience
> > performance issues from zone walkers (not likely) set up a sacrifice
> > server (whose name/address is not in the relevant NS RRSET), which
> > allows the world AXFR, or, more manual work, set up a ftp server
> > where registered users can get the zone OOB. Problem solved.
> 
> *Technical* problem solved. But zone enumeration may be a problem, but
> not a technical one (for instance, a policy one; I say "policy" and
> not "security" because, as Mark reminded, "security" is way too
> overloaded).
> 
> My problem is rather to keep policies in synch. If a domain allows
> AXFR, it makes sense to allow enumeration through NSEC. If it does not
> allow AXFR, it is foolish to deploy NSEC, because it would contradict
> the policy.

	A => B does not mean that B => A.

	The root zone is a classic counter example.  AXFR is denied
	but NSEC is fine.  In fact people would be right to complain
	bitterly if NSEC3 was deployed in the root as all it does
	is put additional load on the validating resolvers for zero
	benifit.  The root zone content is freely available from
	other sources.

	You need to do the risk analysis before deploying NSEC3.

	Just because something is "good/bad" for the root or a TLD
	does not mean that it is "good/bad" elsewhere in the DNS
	heirarchy.

	Wildcards would be very bad in the root.  They are perfectly
	fine in end user zones.

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