idnits 2.17.1 draft-yao-dnsop-root-cache-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 : ---------------------------------------------------------------------------- No issues found here. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The requirement above is to be sure that authoritative data in the root data cache MUST be identical to the same data in the root zone for the DNS. It is possible to change the unsigned data in the root data cache, but that operation MUST not be allowed. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 28, 2015) is 3133 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) == Missing Reference: 'RFC 1321' is mentioned on line 356, but not defined == Unused Reference: 'RFC1321' is defined on line 404, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop J. Yao 3 Internet-Draft N. Kong 4 Intended status: Standards Track X. Li 5 Expires: March 31, 2016 CNNIC 6 September 28, 2015 8 Decreasing Fetch time of Root Data by Improving the Mechanism of Root 9 Data Cacheing 10 draft-yao-dnsop-root-cache-00 12 Abstract 14 Many DNS recursive resolvers have long round trip times to the DNS 15 root server. It has been an obstacle to increse the performance of 16 DNS query. In order to decrease fetch time of DNS root data, this 17 document proposes a new mechanism by improving the mechanism of root 18 data cacheing. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 31, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 69 4. Mechanism for decreasing fetch time of DNS root data . . . . 4 70 5. System Requirements . . . . . . . . . . . . . . . . . . . . . 6 71 6. Requirement of the Root Data Cache . . . . . . . . . . . . . 7 72 7. Requirement and Operation of the Root Zone Analyzer . . . . . 7 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. draft-yao-dnsop-root-cache: Version 00 . . . . . . . . . 9 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 11.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 Many DNS recursive resolvers have long round trip times to the DNS 85 root server, which sometimes become the big burden to increase the 86 DNS resolving performance. The document [Root-loopback] allows the 87 new root zone server to be run on a loopback address to decrease 88 access time to root servers, but it also points out " this design 89 being described here is not considered a "best practice." This 90 document provides a new method by improving the mechanism of root 91 data cacheing. 93 The cache provides an efficient way for DNS to efficiently improve 94 its resolving performance. The resolver can eliminate network delay 95 and name server load from most requests by answering them from its 96 cache of prior results. 98 TTL is a time limit on how long an RR can be kept in a cache. Root 99 zone data normally is kept stable except the SOA record which the 100 root administrator may intentionaly change. Long TTLs can be used to 101 maximize caching. Recursive resolvers currently send queries for all 102 TLDs that are not in their caches to root servers. If there is a 103 mechanism which can increase the valid time of root data in the cache 104 without using the outdated root data information, it will help to 105 decrease access time to root servers generally or help to decrease 106 the fetch time of root data. When any RR is updated in a zone, there 107 will have a new version of zone and have a different serial No. in 108 SOA record. 110 The root zone normally updates its data not frequently as other zones 111 such as the TLD zone. The data for the root zone is usually long- 112 lived. While TTLs can be used to dynamically adjust caching, and a 113 zero TTL prohibits caching, the realities of root zone features 114 suggest that these times should be on the order of days for the 115 typical resolver. If a change can be anticipated, the TTL can be 116 reduced prior to the change to minimize inconsistency during the 117 change, and then increased back to its former value following the 118 change. 120 2. Terminology 122 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 124 described in [RFC2119]. 126 The basic DNS terms used in this specification are defined in the 127 documents [RFC1034] and [RFC1035]. 129 3. Design Considerations 131 The following features will be used to design the cache based 132 mechanism to decrease fetch time of root data: 134 o All resolvers have to connect the root servers for root data. The 135 root data is a common one for all resolvers. 137 o The TLD contents of the root zone is not changed frequently. 139 o DNSSEC[RFC4033][RFC4034][RFC4035] protects the data origin 140 authentication and data integrity. 142 The goal of our design is that the cached root data can be valid as 143 long as the expire value of the root SOA or longger while the data 144 still remains fresh. The mechanism proposed by this dcoument will 145 decrease fetch time of DNS root data efficently. 147 4. Mechanism for decreasing fetch time of DNS root data 149 Local System | Foreign 150 | 151 +---------+ +----------+ | +--------+ 152 | | references | |queries | | | 153 |Root Data|-------------->| |---------|->| Root | 154 | Cache | | Resolver | | | Name | 155 | |<--------------| |<--------|--| Servers| 156 | | cache ops | |responses| | | 157 +---------+ +----------+ | +--------+ 158 | 159 | A | 160 | | | 161 V | | 162 +----------+ | +--------+ 163 | Root |-------- |->| IANA | 164 | Zone | | |RootZone| 165 | Analyzer |<------- |--| File | 166 +----------+ | +--------+ 168 Figure 1. The structure of root data caching mechanism 170 The figure above shows the structure of root data caching mechanism. 171 There will have a separated cache specially designed for root data 172 called root data cache in the resolver. There will have a Root Zone 173 Analyzer which will get the SOA record and zone file of root, and 174 analyze the data. The design is shown in the figure above. The 175 detailed function of the three components in the local system is 176 shown below. 178 1)Root Data Cache: 179 It will cache the root TLD data information from the root name server 180 queried by the resolver. It has three parameters, respectively, 181 version No., fingerprint and refresh timer. 183 Version No: 184 The value is same to SOA serial No. of the current version of root 185 zone. 187 Fingerprint: 188 The value is the digest value by the same digest operation ( MD5 [RFC 189 1321]) performed by the root zone analyzer to the root zone 190 (excluding the SOA and its RRSIG) 192 Refresh Timer: 194 The contents of the root data cache MUST be refreshed using the 195 timer. That is that every RR will be assigned a refresh timer with 196 the default value when it is put into the root data cache. The 197 default timer value is the expire value from the root SOA record in 198 [RFC1035]. The administrators may set their own timer value to RRs 199 in the root data cache. 201 2)Resolver: 202 When the resolver needs to query the TLD information in the root, it 203 should check its cache (specified in RFC 1035) first. If it fails, 204 it then should check the root data cache. If it can not find the 205 answer queried, it then asks the question to root name servers. If 206 it is a DNSSEC query to the root, the resolver should verify the 207 response from the root with DNSSEC. If it passes the DNSSEC 208 validation, the resolver should put these TLD RRs into the root data 209 cache. If it is not a DNSSEC query, the resolver should send another 210 query with the same question with DNSSEC to the root. If the 211 response from the root passes the DNSSEC validation, the resolver 212 should put the TLD data in the response into the root data cache. If 213 these TLD RRs can not pass the DNSSEC validation, it should discard 214 them without caching. The basic implication is that all sanity 215 checks on any TLD RR should be performed before any of it is cached 216 into the root data cache. When a resolver finds a set of RRs for 217 some TLD name in a response from the root, and wants to cache the RRs 218 into the root data cache, it should check its root data cache for 219 already existing RRs. If there is one, the resolver should replace 220 it with the new one. When several RRs of the same type are available 221 for a TLD, the resolver should either cache them all or none at all. 222 The resolver should not cache a possibly partial set of RRs. 224 3)Root Zone Analyzer: 225 It will check the root SOA record and analyze the root zone data 226 frequently. Currently, the root SOA is changed every day even if the 227 contents of the root zone are unchanged. So in most cases, the 228 difference between the new zone and old zone is that SOA record and 229 its RRSIG have the new version while the other parts will be kept 230 same. When the root zone analyzer finds that the root SOA is 231 changed, it should download the root zone file. The root zone 232 analyzer will perform the same digest operation (such as MD5), and 233 compare the result to fingerprint of the root zone (excluding the SOA 234 and its RRSIG) stored in the root data cache. If the SOA is changed 235 and the fingerprint is not changed, the version No. will be changed 236 to the new SOA serial No.. If both the SOA and the fingerprint are 237 changed, the version No. must be changed to the new SOA serial No., 238 and the fingerprint must be changed to the new digest value of the 239 root zone (excluding the SOA and its RRSIG), and flush the root data 240 cache. It means that all root data cache information may be 241 outdated. The system should discard all data in the root data cache. 243 The detailed steps for using this system is shown below: 245 step 1, When the resolver needs to query the TLD name information in 246 the root, it should check its cache (specified in RFC 1035) first. 247 If it finds the information, go to step 4; otherwise go to step 2. 249 step 2, Check the root data cache for the TLD name information. If 250 it finds the answer queried, go to step 4; otherwise go to step 3. 252 step 3, Ask the question to the root name servers. If it finds the 253 answer queried, go to step 5 and step 4 simultaneously; otherwise go 254 to step 4. 256 step 4, The resolver has the necessary information and followed the 257 steps specified in RFC 1035. End. 259 step 5, If it is a DNSSEC query to the root, the resolver should 260 validate the response from the root with DNSSEC; if it passes the 261 DNSSEC validation, the resolver should put these TLD RRs into the 262 root data cache, and set the refresh timer with the default value for 263 these RRs; if it does not pass the DNSSEC validation, these RRs will 264 not be put into the root data cache; end. If it is not a DNSSEC 265 query, go to step 6. 267 step 6, The resolver should send another query with the same question 268 with DNSSEC to the root. If the response from the root passes the 269 DNSSEC validation, the resolver should put the TLD data in the 270 response into the root data cache, and set the refresh timer with the 271 default value for these RRs. If these TLD RRs can not pass the 272 DNSSEC validation, it should discard them without caching. End. 274 Note: The basic implication is that all sanity checks on any TLD RR 275 should be performed before any of it is cached into the root data 276 cache. 278 5. System Requirements 280 In order to implement the mechanism described in this document: 282 o The system MUST be able to validate DNSSEC resource records. 284 o The system MUST have an up-to-date copy of the DNS root key. 286 o Only root TLD data from root zone should be cached. 288 The requirement above is to be sure that authoritative data in the 289 root data cache MUST be identical to the same data in the root zone 290 for the DNS. It is possible to change the unsigned data in the root 291 data cache, but that operation MUST not be allowed. 293 6. Requirement of the Root Data Cache 295 Root cached data will be discarded by a timeout mechanism with 296 refresh timer value or by the root data anlayzer when the data of the 297 root zone is changed. The requirements to run the root data cache 298 are shown below: 300 o Inside the root data cache, refresh timers for cached root data 301 conceptually "count down", while TTL in the RR will be kept in the 302 constant value. 304 o When the RRs are exported from root data cache, the refresh timer 305 will be removed and the TTL in RR will start to "count down". 307 o Every RR will be assigned a refresh timer with the default value 308 when it is put into the root data cache. 310 o The root data cache should discard old RRs whose timer has 311 expired. 313 The resolver may make the queries to several different root name 314 servers to answer a particular user query. Since all the root 315 servers serve the same root data, it will not impact the data 316 accurance. 318 7. Requirement and Operation of the Root Zone Analyzer 320 The resolver expects to cache root data which it receives in 321 responses from the root since it is useful in answering future client 322 requests. However, there are several types of data which should not 323 be cached: 325 o any data not from the root 327 o a possibly partial set of the RRs of the same type for a 328 particular TLD name 330 o TLD data that does not pass the DNSSEC validation 332 o Any TLD data from the root data cache itself 334 The system should periodically checks to make sure that its root data 335 cache are up to date. It MUST discard the cached root data if the 336 data is outdated. The steps to run the Root Zone Analyzer are shown 337 below: 339 step 1, Get the SOA value from the root name server query, set root 340 data cache's version No. = serial of SOA; refresh timer value = 341 expire value of SOA. 343 step 2, Get the full root zone, and do the same digest operation ( 344 such as MD5 [RFC 1321]) to the root zone data excluding the SOA and 345 its RRSIG. Set the root data cache fingerprint = the digest value. 347 step 3, Check the SOA record from the root name server, and compare 348 the serail of the SOA with the version No. of root data cache. If 349 the value is same, wait for fixed time (the suggested time is the 350 refresh value of SOA of the root zone or every 15 minutes) and go to 351 step 3; If the value is not same, go to step 4. 353 step 4, Notify that the root data cache should stop response to the 354 resolver temporarily and give a message to the resolver that no 355 answer has been found for the question. Get the full root zone, and 356 do the same digest operation ( MD5 [RFC 1321]) to the whole root zone 357 data excluding the SOA and its RRSIG. Compare the digest value with 358 the fingerprint of root data cache. If the value is same, set root 359 data cache's version No. = current serial of SOA; if the RRs of root 360 SOA and its RRSIG are in the root data cache, they should be updated 361 to the new one; notify that the root data cache should start response 362 to the resolver immediately and go to step 3. If the value is not 363 same, the system MUST discard all data in the root data cache, notify 364 that the root data cache should start response to the resolver 365 immediately and go to step 1. 367 8. IANA Considerations 369 This document requires no action from the IANA. 371 9. Security Considerations 373 A DNS cache may become poisoned when unauthorized RRs are inserted 374 into it. A non-DNSSEC query may suffer from this problem in the same 375 way as any resolver that does not do DNSSEC validation on responses 376 from a remote root server. The resolver with a DNSSEC query will 377 know how to deal with it. 379 DDOS attackers may aim to the root data cache. They may query random 380 invalid root TLD. In our current design, the root data cache will 381 not cache any negative answers from the root. 383 10. Change History 385 RFC Editor: Please remove this section. 387 10.1. draft-yao-dnsop-root-cache: Version 00 389 o Decreasing fetch time of Root Data by Improving the Mechanism of 390 Root Data Cacheing 392 11. References 394 11.1. Normative References 396 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 397 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 398 . 400 [RFC1035] Mockapetris, P., "Domain names - implementation and 401 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 402 November 1987, . 404 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 405 DOI 10.17487/RFC1321, April 1992, 406 . 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 414 Rose, "DNS Security Introduction and Requirements", 415 RFC 4033, DOI 10.17487/RFC4033, March 2005, 416 . 418 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 419 Rose, "Resource Records for the DNS Security Extensions", 420 RFC 4034, DOI 10.17487/RFC4034, March 2005, 421 . 423 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 424 Rose, "Protocol Modifications for the DNS Security 425 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 426 . 428 11.2. Informative References 430 [Root-loopback] 431 Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 432 Servers by Running One on Loopback", May 2015, 433 . 436 Authors' Addresses 438 Jiankang Yao 439 CNNIC 440 4 South 4th Street,Zhongguancun,Haidian District 441 Beijing, Beijing 100190 442 China 444 Phone: +86 10 5881 3007 445 Email: yaojk@cnnic.cn 447 Ning Kong 448 CNNIC 449 4 South 4th Street,Zhongguancun,Haidian District 450 Beijing, Beijing 100190 451 China 453 Phone: +86 10 5881 3147 454 Email: nkong@cnnic.cn 456 Xiaodong Li 457 CNNIC 458 4 South 4th Street,Zhongguancun,Haidian District 459 Beijing, Beijing 100190 460 China 462 Phone: +86 10 5881 3020 463 Email: xl@cnnic.cn