--- 1/draft-ietf-dnsop-nsec-aggressiveuse-09.txt 2017-05-24 15:14:09.755182306 -0700 +++ 2/draft-ietf-dnsop-nsec-aggressiveuse-10.txt 2017-05-24 15:14:09.787183075 -0700 @@ -1,61 +1,61 @@ Network Working Group K. Fujiwara Internet-Draft JPRS Updates: 4035 (if approved) A. Kato Intended status: Standards Track Keio/WIDE -Expires: October 1, 2017 W. Kumari +Expires: November 25, 2017 W. Kumari Google - March 30, 2017 + May 24, 2017 Aggressive use of DNSSEC-validated Cache - draft-ietf-dnsop-nsec-aggressiveuse-09 + draft-ietf-dnsop-nsec-aggressiveuse-10 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 resilience to certain DoS attacks in some circumstances. This document updates RFC4035 by allowing validating resolvers to - generate negative answers based upon NSEC/NSEC3 records (and positive - answers in the presence of wildcards). + generate negative answers based upon NSEC/NSEC3 records and positive + answers in the presence of wildcards. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, - etc. They will be removed before publication.This document is being - collaborated on in Github at: https://github.com/wkumari/draft-ietf- - dnsop-nsec-aggressiveuse. The most recent version of the document, - open issues, etc should all be available here. The authors + etc. RFC Editor, please remove before publication. This document is + being collaborated on in Github at: https://github.com/wkumari/draft- + ietf-dnsop-nsec-aggressiveuse. The most recent version of the + document, open issues, etc should all be available here. The authors (gratefully) accept pull requests.] Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 October 1, 2017. + This Internet-Draft will expire on November 25, 2017. Copyright Notice 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 @@ -72,32 +72,32 @@ 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 . . . . . . . . . . . . . . . . . . . . . 8 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 - 11.1. Change History . . . . . . . . . . . . . . . . . . . . . 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 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 12.2. Informative References . . . . . . . . . . . . . . . . . 14 + 11.1.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 . 14 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 12.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Detailed implementation notes . . . . . . . . . . . 15 - Appendix B. Procedure for determining ENT vs NXDOMAN with NSEC . 15 + Appendix B. Procedure for determining ENT vs NXDOMAN with NSEC . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction A DNS negative cache exists, and is used to cache the fact that an RRset does not exist. This method of negative caching requires exact matching; this leads to unnecessary additional lookups, increases latency, leads to extra resource utilization on both authoritative and recursive servers, and decreases privacy by leaking queries. @@ -233,22 +233,23 @@ 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 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. + NSEC3 and wildcard records to synthesize answers as described in this + document. 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 query name. If denial of existence can be determined according to the rules set out in Section 5.4 of [RFC4035], using NSEC records in the cache, then the resolver can immediately return an NXDOMAIN or NODATA (as @@ -418,20 +419,30 @@ standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya JINMEI for extensive review and comments, and also Mark Andrews, Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent pull requests!) and Ondrej Sury. 11.1. Change History RFC Editor: Please remove this section prior to publication. + -09 to -10: + + o Addressed IESG comments at https://datatracker.ietf.org/doc/draft- + ietf-dnsop-nsec-aggressiveuse/ballot/ + + o Main change "the resolver SHOULD use NSEC, NSEC3 and wildcard + records aggressively." -> "HOULD use NSEC, NSEC3 and wildcard + records to synthesize answers as described in this document" + (Mirja) - aggressively wasn't really described... + -08 to -09: o Made RFC5074 Informative (after discussions with chairs. o Addressed SecDir comments. o Addressed OpsDir comments. -06 to -08: