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:

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
validating resolver.

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
child zone.

- 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
appear bogus.

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.

Proposed Resolution:

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 with
the word 'unsubscribe' in a single line as the message text body.