[dns-operations] How can BIND find itself that I used NSEC3 with opt-out?
Mark Andrews
marka at isc.org
Wed Nov 18 22:46:36 UTC 2009
In message <a06240800c729aeac63b7@[10.31.201.134]>, Edward Lewis writes:
> At 0:35 +1100 11/19/09, Mark Andrews wrote:
>
> >Mind you it would make more sense to have optout in the NSEC3PARAM
> >record. There is no useful purpose to being able to switch optout
> >on and off in a NSEC3 chain and we don't provide a method to do so
> >but will preserve a zone that does do so.
>
> This is an opinion that is specific to an implementation's design choice.
>
> You don't have to opt-out an unsigned delegation, but the apparent
> assumption made in BIND is that if opt-out is used in a zone (toggle
> on/off) then all unsigned cu tpoints are opted-out. When the work
> was done to prepare RFC 5155, there wasn't a global setting for
> opt-in/opt-out, it was anticipated to be a per cut point decision.
> The issue is that implementations don't let you specify "make this
> out-out" or not when adding a cut point, coders generally prefer to
> infer behavior than ask the user.
Then why use optout at all? You want to be able to prove that some
of the insecure delegations exist but not others? It would be a
very strange parent that needed this level of specifics and at least
with simple-secure-update there is no mechanism defined to signal this.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations
mailing list