--- 1/draft-ietf-dnsop-nsec-aggressiveuse-07.txt 2017-01-12 02:13:08.113136138 -0800 +++ 2/draft-ietf-dnsop-nsec-aggressiveuse-08.txt 2017-01-12 02:13:08.149137153 -0800 @@ -1,21 +1,21 @@ Network Working Group K. Fujiwara Internet-Draft JPRS Updates: 4035 (if approved) A. Kato Intended status: Standards Track Keio/WIDE -Expires: June 16, 2017 W. Kumari +Expires: July 16, 2017 W. Kumari Google - December 13, 2016 + January 12, 2017 - Aggressive use of NSEC/NSEC3 - draft-ietf-dnsop-nsec-aggressiveuse-07 + Aggressive use of DNSSEC-validated Cache + draft-ietf-dnsop-nsec-aggressiveuse-08 Abstract The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a range, and positive answers from wildcards. This increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. It may also help increase @@ -41,25 +41,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 16, 2017. + This Internet-Draft will expire on July 16, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -71,22 +71,22 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Aggressive use of Cache . . . . . . . . . . . . . . . . . . . 6 5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. Consideration on TTL . . . . . . . . . . . . . . . . . . 7 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Update to RFC 4035 . . . . . . . . . . . . . . . . . . . . . 8 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Change History . . . . . . . . . . . . . . . . . . . . . 10 11.1.1. Version draft-fujiwara-dnsop-nsec-aggressiveuse-01 . 13 11.1.2. Version draft-fujiwara-dnsop-nsec-aggressiveuse-02 . 13 11.1.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 . 13 11.2. new section . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14 @@ -229,28 +229,22 @@ of this technique, a lookup for the exact name could have come in during this interval, and so a negative answer could already be cached (see [RFC2308] for more background). This means that zone operators should have no expectation that an added name would work immediately. With DNSSEC and Aggressive NSEC, the TTL of the NSEC/ NSEC3 record and the SOA.MINIMUM field are the authoritative statement of how quickly a name can start working within a zone. 5. Aggressive use of Cache - Section 4.5 of [RFC4035] says that "In theory, a resolver could use - wildcards or NSEC RRs to generate positive and negative responses - (respectively) until the TTL or signatures on the records in question - expire. However, it seems prudent for resolvers to avoid blocking - new authoritative data or synthesizing new data on their own. - Resolvers that follow this recommendation will have a more consistent - view of the namespace". This document relaxes this this restriction, - see Section 7 for more detail. + This document relaxes the restriction given in Section 4.5 of + [RFC4035], see Section 7 for more detail. If the negative cache of the validating resolver has sufficient information to validate the query, the resolver SHOULD use NSEC, NSEC3 and wildcard records aggressively. Otherwise, it MUST fall back to send the query to the authoritative DNS servers. 5.1. NSEC The validating resolver needs to check the existence of an NSEC RR matching/covering the source of synthesis and an NSEC RR covering the @@ -600,22 +595,22 @@ o Updated pseudo code 11.2. new section 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, .