[dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)

[Blacka, David]

Victor,

> 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
   ignored."

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