draft-ietf-dnsop-nsec-aggressiveuse-09.txt   draft-ietf-dnsop-nsec-aggressiveuse-10.txt 
Network Working Group K. Fujiwara Network Working Group K. Fujiwara
Internet-Draft JPRS Internet-Draft JPRS
Updates: 4035 (if approved) A. Kato Updates: 4035 (if approved) A. Kato
Intended status: Standards Track Keio/WIDE Intended status: Standards Track Keio/WIDE
Expires: October 1, 2017 W. Kumari Expires: November 25, 2017 W. Kumari
Google Google
March 30, 2017 May 24, 2017
Aggressive use of DNSSEC-validated Cache Aggressive use of DNSSEC-validated Cache
draft-ietf-dnsop-nsec-aggressiveuse-09 draft-ietf-dnsop-nsec-aggressiveuse-10
Abstract Abstract
The DNS relies upon caching to scale; however, the cache lookup The DNS relies upon caching to scale; however, the cache lookup
generally requires an exact match. This document specifies the use generally requires an exact match. This document specifies the use
of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers
to generate negative answers within a range, and positive answers to generate negative answers within a range, and positive answers
from wildcards. This increases performance / decreases latency, from wildcards. This increases performance / decreases latency,
decreases resource utilization on both authoritative and recursive decreases resource utilization on both authoritative and recursive
servers, and also increases privacy. It may also help increase servers, and also increases privacy. It may also help increase
resilience to certain DoS attacks in some circumstances. resilience to certain DoS attacks in some circumstances.
This document updates RFC4035 by allowing validating resolvers to This document updates RFC4035 by allowing validating resolvers to
generate negative answers based upon NSEC/NSEC3 records (and positive generate negative answers based upon NSEC/NSEC3 records and positive
answers in the presence of wildcards). answers in the presence of wildcards.
[ Ed note: Text inside square brackets ([]) is additional background [ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings, information, answers to frequently asked questions, general musings,
etc. They will be removed before publication.This document is being etc. RFC Editor, please remove before publication. This document is
collaborated on in Github at: https://github.com/wkumari/draft-ietf- being collaborated on in Github at: https://github.com/wkumari/draft-
dnsop-nsec-aggressiveuse. The most recent version of the document, ietf-dnsop-nsec-aggressiveuse. The most recent version of the
open issues, etc should all be available here. The authors document, open issues, etc should all be available here. The authors
(gratefully) accept pull requests.] (gratefully) accept pull requests.]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Aggressive use of Cache . . . . . . . . . . . . . . . . . . . 6 5. Aggressive use of Cache . . . . . . . . . . . . . . . . . . . 6
5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Consideration on TTL . . . . . . . . . . . . . . . . . . 7 5.4. Consideration on TTL . . . . . . . . . . . . . . . . . . 7
6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Update to RFC 4035 . . . . . . . . . . . . . . . . . . . . . 8 7. Update to RFC 4035 . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 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.1. Version draft-fujiwara-dnsop-nsec-aggressiveuse-01 . 13
11.1.2. Version draft-fujiwara-dnsop-nsec-aggressiveuse-02 . 13 11.1.2. Version draft-fujiwara-dnsop-nsec-aggressiveuse-02 . 13
11.1.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 . 13 11.1.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Detailed implementation notes . . . . . . . . . . . 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
A DNS negative cache exists, and is used to cache the fact that an 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 RRset does not exist. This method of negative caching requires exact
matching; this leads to unnecessary additional lookups, increases matching; this leads to unnecessary additional lookups, increases
latency, leads to extra resource utilization on both authoritative latency, leads to extra resource utilization on both authoritative
and recursive servers, and decreases privacy by leaking queries. and recursive servers, and decreases privacy by leaking queries.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
NSEC3 record and the SOA.MINIMUM field are the authoritative NSEC3 record and the SOA.MINIMUM field are the authoritative
statement of how quickly a name can start working within a zone. statement of how quickly a name can start working within a zone.
5. Aggressive use of Cache 5. Aggressive use of Cache
This document relaxes the restriction given in Section 4.5 of This document relaxes the restriction given in Section 4.5 of
[RFC4035], see Section 7 for more detail. [RFC4035], see Section 7 for more detail.
If the negative cache of the validating resolver has sufficient If the negative cache of the validating resolver has sufficient
information to validate the query, the resolver SHOULD use NSEC, information to validate the query, the resolver SHOULD use NSEC,
NSEC3 and wildcard records aggressively. Otherwise, it MUST fall NSEC3 and wildcard records to synthesize answers as described in this
back to send the query to the authoritative DNS servers. document. Otherwise, it MUST fall back to send the query to the
authoritative DNS servers.
5.1. NSEC 5.1. NSEC
The validating resolver needs to check the existence of an NSEC RR The validating resolver needs to check the existence of an NSEC RR
matching/covering the source of synthesis and an NSEC RR covering the matching/covering the source of synthesis and an NSEC RR covering the
query name. query name.
If denial of existence can be determined according to the rules set 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, out in Section 5.4 of [RFC4035], using NSEC records in the cache,
then the resolver can immediately return an NXDOMAIN or NODATA (as then the resolver can immediately return an NXDOMAIN or NODATA (as
skipping to change at page 9, line 51 skipping to change at page 10, line 9
standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya
JINMEI for extensive review and comments, and also Mark Andrews, JINMEI for extensive review and comments, and also Mark Andrews,
Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon
Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent
pull requests!) and Ondrej Sury. pull requests!) and Ondrej Sury.
11.1. Change History 11.1. Change History
RFC Editor: Please remove this section prior to publication. 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: -08 to -09:
o Made RFC5074 Informative (after discussions with chairs. o Made RFC5074 Informative (after discussions with chairs.
o Addressed SecDir comments. o Addressed SecDir comments.
o Addressed OpsDir comments. o Addressed OpsDir comments.
-06 to -08: -06 to -08:
 End of changes. 12 change blocks. 
19 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/