Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt

In message <20120313080731.GA12019@miek.nl>, Miek Gieben writes:
> [ Quoting <scottr.nist@gmail.com> at 09:08 on Mar 12 in "Re: [dnsext] I-D A=
> ct..." ]
> > One reason we made it three unique options was so clients could mix
> > and match if they wanted. Especially since there is only one NSEC3
> > hash algorithm code assigned for now.
> 
> Upgrading hashes in NSEC3 is hard, upgrading NSEC3 (to whatever) is harder
> still.
> 
> How about an extra option that lists which authenticated denial of existence
> records are understood. Something along the lines:
> 
> An option code that signals which negative resource records an resolver
> can handle. When DNSSEC was first designed NXT, was defined, this was
> later renamed to NSEC. Later still NSEC3 was defined. Upgrading to a new
> authenticated denial of existence record is very hard. The upgrade to NSEC3
> involved an algorithm roll, which is not desirable as we only have 8 bits in
> the algorithm field. So we define to following:
> 
> NXU                         (NXDOMAIN Understood)
> 2                           (length is always 2 octect)
> Type code of the highext NX=20
> record understood.
>    =20
> This defaults to '50'.
> 
>  Regards,
> 
> --=20
>     Miek Gieben

If you want to solve upgrading NSEC3's hash algorithm or BNAME etc.
then that needs to be carried in the DS record so the zone can be
treated as insecure.  Defining DS hash types which have additional
fields would be one way forward that is backwards compatible.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext