--- Begin Message ---
Victor,
> On Jan 19, 2021, at 10:53 AM, Viktor Dukhovni <[email protected]> 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 <[email protected]>
Verisign Fellow Verisign Product Engineering
--- End Message ---
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
