Technical Summary
The Domain Name System Security Extensions (DNSSEC) introduced the
NSEC resource record (RR) for authenticated denial of existence.
Though the NSEC RR meets the requirements for authenticated denial of
existence, it introduces a side-effect in that the contents of a zone
can be enumerated. This property introduces undesired policy issues.
A second problem is that the cost to cryptographically secure
delegations to unsigned zones is high for large delegation-centric
zones and zones where insecure delegations will be updated rapidly.
(Typically these are top level domains). For these zones, the costs of
maintaining the NSEC record chain may be extremely high relative to
the gain of cryptographically authenticating existence of unsecured
zones.
This document presents the NSEC3 Resource Record which can be used as
an alternative to NSEC to mitigate these issues.
This document introduces an alternative resource record, NSEC3, which
similarly provides authenticated denial of existence. However, it
also provides measures against zone enumeration and permits gradual
expansion of delegation-centric zones.
Working Group Summary
The OPT out feature of NSEC3 used to be a point of contention in the
DNSEXT working group. The working group did not bring OPT-OUT up as an
issue during the development of the draft or during last call. The
chairs are convinced that the feature was not introduced under the
radar and that the working group consents with the feature being
introduced.
The iterations count has been subject to discussion because it may be
used to trigger DOS attacks on resolvers. The WG consensus is to
recommend a limitation on the number of iterations that a resolver is
supposed to carry out.
Document Quality
During the development of the specification there were two workshops
organized in which, among others, 3 operators (Nominet, Verisign and
DENIC) and two Developers (ISC and NLnet) participated. During the
workshops serious signaling issues were discovered which lead to the
NSEC3PARAM RR.
The specification has been implemented, albeit not in production code,
in: BIND (authoritative server, validating resolver, caching name
server), NSD (authoritative only), LDNS (library and troubleshooting
tools),
UNBOUND Java (validating resolver), Sparta's library (validating
resolver), Net::DNS (Library, only parsing functions and helper methods)
and about
4 different zone signers.
Operators have indicated this specification to be imperative for
DNSSEC deployment.
Note to RFC Editor
Please see RFC Editor Instructions in the IANA Considerations section.
After type code assignments, some work will have to be done by the authors
of the document to regenerate text for the examples in the Appendix.