[dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)
davidb at verisign.com
Tue Jan 19 18:47:08 UTC 2021
> On Jan 19, 2021, at 10:53 AM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> Indeed for .COM the NSEC3PARAM RR does not match the actual policy, it
> shows the opt-out bit off.
> com. IN NSEC3PARAM 1 0 0 -
> while actual DoE proofs carry the opt-out bit:
> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. IN NSEC3 (
> 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A
> NS SOA RRSIG DNSKEY NSEC3PARAM )
> It seems that the authoritative servers know to use opt-out via
> some other mechanism.
Please read RFC 5155 Section 4.1.2. OK, I'll quote it here and save folks some time (note that section 4 is about the NSEC3PARAM record itself):
"4.1.2. Flag Fields
The Opt-Out flag is not used and is set to zero.
All other flags are reserved for future use, and must be zero.
NSEC3PARAM RRs with a Flags field value other than zero MUST be
IIRC, setting the "Opt-Out" bit in the NSEC3PARAM record is a BIND-ism needed to tell the inline signer to use Opt-Out. It isn't officially part of the standard, though.
The use of Opt-Out does not define a new NSEC3 chain, unlike changing the hash algorithm, salt, or iterations. While is generally makes no sense to do so, you could mix Opt-Out and non-Opt-Out NSEC3 records in a single zone and still comply with the standard.
Also note that NSEC3PARAM records have no use to recursive servers -- in no case does a DNSSEC validator use NSEC3PARAM. They are intended to be consumed by authoritative servers so they can pick a NSEC3 chain.
David Blacka <davidb at verisign.com>
Verisign Fellow Verisign Product Engineering
More information about the dns-operations