The IESG has approved the following document: - 'DNSSEC Hashed Authenticated Denial of Existence ' <draft-ietf-dnsext-nsec3-13.txt> as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-13.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
