This is a discussion on NSEC3 Issue 8: NSEC3 Signaling Mechanism - DNS ; Issue: Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow signal this to NSEC3-unaware DNSSEC applications? Example: if an NSEC3-unaware validating resolver queries for a non-existent RRset in an NSEC3 zone, the response will contain ...
Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow
signal this to NSEC3-unaware DNSSEC applications?
Example: if an NSEC3-unaware validating resolver queries for a
non-existent RRset in an NSEC3 zone, the response will contain one or
more NSEC3 RRs in place of the expected NSEC RR(s). In RFC 4035,
omission of NSEC RRs in a No Data/Name Error response is a protocol
violation [Section 3.1.3]; consequently, the resolver will mark it
Several approaches have been considered for handling this:
1. Use a full type code rollover (a.k.a. `DNSSECter')
- Fully independent DNSSEC scheme (third one, if RFC 2535 is
- Four new RRs:
DNSKEY -> DNSKEY2
RRSIG -> RRSIG2
NSEC -> NSEC3
DS -> DS2
- All RR formats identical except for NSEC vs NSEC3
- NSEC3-unaware validators see only DNSSECbis RRs. In NSEC3 zones
only new RRs are used. Either or both validation schemes may be
used independently without reference to one another.
- A validating resolver must have special (non-RFC 4033-35) rules
for recognising and processing DS2 RRs in DNSSECbis zones, e.g.
when a DNSSECter-only zone has a DNSSSECbis-only parent.
Otherwise the DS2 RR will not be identified as part of any
validation chain. So while a type-code rollover may at first
glance appear to be an elegant solution, it only works if one or
another set of type codes is used exclusive DNSSECbis zone.
- If the KSK of the NSEC3 is a trust anchor, care must be taken not
to use it in the `trusted-keys' store of a non-NSEC3-aware
3. Use a new DS message digest number
- Use the DS message digest field for signaling both:
a. that NSEC3 is in use in the child zone, and
b. which hash algorithm is in use by the NSEC3 RRs in the
- Proposed in this post to namedroppers:
- Only works if all subsequent children are NSEC3. If the chain of
trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will
4. Use an unknown algorithm identifier
- Described in draft-ietf-dnsext-dnssec-experiments-01.txt
- Use algorithm identifiers in RRSIG and DS RRs that would not be
recognised by NSEC3-unaware validating resolver, so that
No Data/Name Error responses would appear insecure rather than
- Would require the use of multiple algorithm identifiers for the
same algorithm, at least until NSEC3 was folded into a revised
version of DNSSECbis. This would mean SHA-1 (and probably
SHA-256) would have two identifiers each. This is mitigated by
the fact that:
- the algorithm identifier is an 8-bit number out of which
only 10 assignments have been made:
- The rate of new assignments is expected to be low.
5. Do nothing
No Data/Name Error responses for queries that have NSEC3 somewhere in
the validation chain will be marked bogus.
- If DNSSEC deployment is sufficiently minimal before NSEC3 (or
other NSEC++) is available, this may have a negligible impact.
- DNS operators considering the deployment of DNSSEC might choose
to wait until NSEC3 is available, or, conversely,
- DNSSEC deployment might become sufficiently advanced that
operators will be unwilling to deploy NSEC3.
Approach #4 appears to be the most promising. Thorough testing will be
required to determine whether any non-obvious issues exist, though it's
been shown to work in previous testing.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.