idnits 2.17.1 draft-arnt-yao-dnsop-root-data-caching-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 12, 2019) is 1897 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1321' is defined on line 204, but no explicit reference was found in the text == Unused Reference: 'Root-loopback' is defined on line 230, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 -- Obsolete informational reference (is this intentional?): RFC 7706 (ref. 'Root-loopback') (Obsoleted by RFC 8806) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop A. Gulbrandsen 3 Internet-Draft 4 Intended status: Standards Track J. Yao 5 Expires: August 16, 2019 CNNIC 6 February 12, 2019 8 Decreasing Fetch time of Root Data by Additional Caching Rules 9 draft-arnt-yao-dnsop-root-data-caching-00 11 Abstract 13 Some DNS recursive resolvers have long round trip times to the 14 nearest DSN root server, which has been an obstacle to DNS query 15 performance. In order to decrease root record fetch time without 16 introducing a new source of errors, this document proposes a root- 17 specific modification to the caching rules. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 16, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 56 4. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. Impact on the resolver . . . . . . . . . . . . . . . . . 3 58 4.2. Impact on the root servers . . . . . . . . . . . . . . . 4 59 4.3. Impact on the network . . . . . . . . . . . . . . . . . . 4 60 5. System Requirements . . . . . . . . . . . . . . . . . . . . . 4 61 6. Difference between this mechanism and RFC7706 based mechanism 4 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 8. Change History . . . . . . . . . . . . . . . . . . . . . . . 4 64 8.1. draft-arnt-yao-dnsop-root-data-caching: Version 00 . . . 5 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 9.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Some DNS recursive resolvers suffer from long round trip times to the 73 nearest DSN root server, which has been an obstacle to DNS query 74 performance. 76 A particular characteristic of the root zone is that when cached, its 77 data is usable for very different queries: An MTA that wishes to send 78 mail to Google needs the NS records for .com, and so does a web 79 browser that wishes to open the Bing home page. Other public zones 80 (such as .co.uk and .gen.nz, and perhaps tumblr.com) are shared among 81 some queries, the root zone is used for all. 83 This suggests that caching rules that are appropriate to the rest of 84 the DNS tree may not be ideal for the root zone. 86 We propose to refresh root zone data probabilistically when it 87 expires, instead of when needed. 89 2. Terminology 91 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 93 described in [RFC2119]. 95 The basic DNS terms used in this specification are defined in the 96 documents [RFC1034] and [RFC1035]. 98 3. Design Considerations 100 o The RRs in the root zone do not change frequently. 102 o The root zone is not large, compared to the RAM of even smallish 103 resolvers. 105 o DNSSEC[RFC4033][RFC4034][RFC4035] protects the data origin 106 authentication and data integrity. 108 4. Changes 110 When an RR in a resolver's cache expires and is in the root zone, 111 then the resolver immediately refreshes it. There are no protocol 112 changes or extensions. 114 Assuming that the lookup frequency for a root-zone RR drops by half 115 for every additional week, (ie. half of all RRs that looked up 116 repeatedly are looked up every week, a quarter every second week, an 117 eighth every third week, etc), this eliminates root-zone delay as a 118 timing factor for more than 99.999% of queries through this resolver. 120 In practice, this should mean that unintentional clearing of the 121 resolver's cache (e.g. as a side effect of restarting the resolver) 122 is the next biggest contributor to slow queries. 124 OPEN ISSUE: Or perhaps better, only with 95% likelihood? If the 125 resolver refreshes it with 100% certainty, then the resolver 126 necessarily grows to storing all of the root-zone RRs it has needed 127 forever. If the resolver refreshes it 95% of the time and root-zone 128 RRs have a TTL of around a week, then an unused root-zone RR has 129 around 50% chance of being discarded after three months. The 130 resolver will perform around 12 DNS queries that turn out, in 131 hindsight, not to be necessary. The text below assumes 95% 132 likelihood. 134 4.1. Impact on the resolver 136 The resolver is able to answer DNS queries quickly for all root RRs 137 that have been used in the past several months, instead of the past 138 week. The cost in additional processing and RAM is negligible; there 139 are no additional tasks that can go wrong. 141 4.2. Impact on the root servers 143 The root servers one additional query per TTL (usually week) per 144 resolver and RR, for the RRs that have been needed by that resolver 145 in the past, but will not be needed in the coming week. The queries 146 arrive evenly. They do not peak around a particular time, but are 147 distributed as the normal traffic. 149 4.3. Impact on the network 151 There is no additional network traffic related to ongoing use of the 152 network (or DNS). There are also no savings. However, some packets 153 are sent earlier than they would be withot this document. 155 Around 25 additional packets are transmitted (two per week over a 156 period of some months) when a the users of a particular resolver stop 157 using a particular root-zone RR. 159 5. System Requirements 161 In order to implement the mechanism described in this document: 163 o The system MUST be able to validate DNSSEC resource records. 165 o The system MUST have an up-to-date copy of the DNS root key. 167 6. Difference between this mechanism and RFC7706 based mechanism 169 The following features are considered to be different compared to 170 RFC7706 based mechanism: 172 o This document retrieves single RRs (or probably sets, as required 173 by DNSSSEC validation). RFC7706 retrieves the entire zone. 175 o This document requires no actions by human administrators. 177 o This document provides only a probabilistic performance 178 improvement; RFC 7706 provides a guarantee. 180 7. Security Considerations 182 None. 184 8. Change History 186 RFC Editor: Please remove this section. 188 8.1. draft-arnt-yao-dnsop-root-data-caching: Version 00 190 o Decreasing fetch time of root data by additional caching rules 192 9. References 194 9.1. Normative References 196 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 197 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 198 . 200 [RFC1035] Mockapetris, P., "Domain names - implementation and 201 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 202 November 1987, . 204 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 205 DOI 10.17487/RFC1321, April 1992, 206 . 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, 210 DOI 10.17487/RFC2119, March 1997, 211 . 213 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 214 Rose, "DNS Security Introduction and Requirements", 215 RFC 4033, DOI 10.17487/RFC4033, March 2005, 216 . 218 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 219 Rose, "Resource Records for the DNS Security Extensions", 220 RFC 4034, DOI 10.17487/RFC4034, March 2005, 221 . 223 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 224 Rose, "Protocol Modifications for the DNS Security 225 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 226 . 228 9.2. Informative References 230 [Root-loopback] 231 Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 232 Servers by Running One on Loopback", November 2015, 233 . 235 Authors' Addresses 237 Arnt Gulbrandsen 239 Email: arnt@gulbrandsen.priv.no 241 Jiankang Yao 242 CNNIC 243 4 South 4th Street,Zhongguancun,Haidian District 244 Beijing, Beijing 100190 245 China 247 Phone: +86 10 5881 3007 248 Email: yaojk@cnnic.cn