dnsop J. Yao Internet-Draft N. Kong Intended status: Standards Track X. Li Expires: March 31, 2016 CNNIC September 28, 2015 Decreasing Fetch time of Root Data by Improving the Mechanism of Root Data Cacheing draft-yao-dnsop-root-cache-00 Abstract Many DNS recursive resolvers have long round trip times to the DNS root server. It has been an obstacle to increse the performance of DNS query. In order to decrease fetch time of DNS root data, this document proposes a new mechanism by improving the mechanism of root data cacheing. 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 March 31, 2016. Copyright Notice Copyright (c) 2015 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 Yao, et al. Expires March 31, 2016 [Page 1]
Internet-Draft root-cache-solution September 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 4. Mechanism for decreasing fetch time of DNS root data . . . . 4 5. System Requirements . . . . . . . . . . . . . . . . . . . . . 6 6. Requirement of the Root Data Cache . . . . . . . . . . . . . 7 7. Requirement and Operation of the Root Zone Analyzer . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. draft-yao-dnsop-root-cache: Version 00 . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Many DNS recursive resolvers have long round trip times to the DNS root server, which sometimes become the big burden to increase the DNS resolving performance. The document [Root-loopback] allows the new root zone server to be run on a loopback address to decrease access time to root servers, but it also points out " this design being described here is not considered a "best practice." This document provides a new method by improving the mechanism of root data cacheing. The cache provides an efficient way for DNS to efficiently improve its resolving performance. The resolver can eliminate network delay and name server load from most requests by answering them from its cache of prior results. Yao, et al. Expires March 31, 2016 [Page 2]
Internet-Draft root-cache-solution September 2015 TTL is a time limit on how long an RR can be kept in a cache. Root zone data normally is kept stable except the SOA record which the root administrator may intentionaly change. Long TTLs can be used to maximize caching. Recursive resolvers currently send queries for all TLDs that are not in their caches to root servers. If there is a mechanism which can increase the valid time of root data in the cache without using the outdated root data information, it will help to decrease access time to root servers generally or help to decrease the fetch time of root data. When any RR is updated in a zone, there will have a new version of zone and have a different serial No. in SOA record. The root zone normally updates its data not frequently as other zones such as the TLD zone. The data for the root zone is usually long- lived. While TTLs can be used to dynamically adjust caching, and a zero TTL prohibits caching, the realities of root zone features suggest that these times should be on the order of days for the typical resolver. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change. 2. Terminology The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as described in [RFC2119]. The basic DNS terms used in this specification are defined in the documents [RFC1034] and [RFC1035]. 3. Design Considerations The following features will be used to design the cache based mechanism to decrease fetch time of root data: o All resolvers have to connect the root servers for root data. The root data is a common one for all resolvers. o The TLD contents of the root zone is not changed frequently. o DNSSEC[RFC4033][RFC4034][RFC4035] protects the data origin authentication and data integrity. The goal of our design is that the cached root data can be valid as long as the expire value of the root SOA or longger while the data still remains fresh. The mechanism proposed by this dcoument will decrease fetch time of DNS root data efficently. Yao, et al. Expires March 31, 2016 [Page 3]
Internet-Draft root-cache-solution September 2015 4. Mechanism for decreasing fetch time of DNS root data Local System | Foreign | +---------+ +----------+ | +--------+ | | references | |queries | | | |Root Data|-------------->| |---------|->| Root | | Cache | | Resolver | | | Name | | |<--------------| |<--------|--| Servers| | | cache ops | |responses| | | +---------+ +----------+ | +--------+ | | A | | | | V | | +----------+ | +--------+ | Root |-------- |->| IANA | | Zone | | |RootZone| | Analyzer |<------- |--| File | +----------+ | +--------+ Figure 1. The structure of root data caching mechanism The figure above shows the structure of root data caching mechanism. There will have a separated cache specially designed for root data called root data cache in the resolver. There will have a Root Zone Analyzer which will get the SOA record and zone file of root, and analyze the data. The design is shown in the figure above. The detailed function of the three components in the local system is shown below. 1)Root Data Cache: It will cache the root TLD data information from the root name server queried by the resolver. It has three parameters, respectively, version No., fingerprint and refresh timer. Version No: The value is same to SOA serial No. of the current version of root zone. Fingerprint: The value is the digest value by the same digest operation ( MD5 [RFC 1321]) performed by the root zone analyzer to the root zone (excluding the SOA and its RRSIG) Refresh Timer: Yao, et al. Expires March 31, 2016 [Page 4]
Internet-Draft root-cache-solution September 2015 The contents of the root data cache MUST be refreshed using the timer. That is that every RR will be assigned a refresh timer with the default value when it is put into the root data cache. The default timer value is the expire value from the root SOA record in [RFC1035]. The administrators may set their own timer value to RRs in the root data cache. 2)Resolver: When the resolver needs to query the TLD information in the root, it should check its cache (specified in RFC 1035) first. If it fails, it then should check the root data cache. If it can not find the answer queried, it then asks the question to root name servers. If it is a DNSSEC query to the root, the resolver should verify the response from the root with DNSSEC. If it passes the DNSSEC validation, the resolver should put these TLD RRs into the root data cache. If it is not a DNSSEC query, the resolver should send another query with the same question with DNSSEC to the root. If the response from the root passes the DNSSEC validation, the resolver should put the TLD data in the response into the root data cache. If these TLD RRs can not pass the DNSSEC validation, it should discard them without caching. The basic implication is that all sanity checks on any TLD RR should be performed before any of it is cached into the root data cache. When a resolver finds a set of RRs for some TLD name in a response from the root, and wants to cache the RRs into the root data cache, it should check its root data cache for already existing RRs. If there is one, the resolver should replace it with the new one. When several RRs of the same type are available for a TLD, the resolver should either cache them all or none at all. The resolver should not cache a possibly partial set of RRs. 3)Root Zone Analyzer: It will check the root SOA record and analyze the root zone data frequently. Currently, the root SOA is changed every day even if the contents of the root zone are unchanged. So in most cases, the difference between the new zone and old zone is that SOA record and its RRSIG have the new version while the other parts will be kept same. When the root zone analyzer finds that the root SOA is changed, it should download the root zone file. The root zone analyzer will perform the same digest operation (such as MD5), and compare the result to fingerprint of the root zone (excluding the SOA and its RRSIG) stored in the root data cache. If the SOA is changed and the fingerprint is not changed, the version No. will be changed to the new SOA serial No.. If both the SOA and the fingerprint are changed, the version No. must be changed to the new SOA serial No., and the fingerprint must be changed to the new digest value of the root zone (excluding the SOA and its RRSIG), and flush the root data cache. It means that all root data cache information may be outdated. The system should discard all data in the root data cache. Yao, et al. Expires March 31, 2016 [Page 5]
Internet-Draft root-cache-solution September 2015 The detailed steps for using this system is shown below: step 1, When the resolver needs to query the TLD name information in the root, it should check its cache (specified in RFC 1035) first. If it finds the information, go to step 4; otherwise go to step 2. step 2, Check the root data cache for the TLD name information. If it finds the answer queried, go to step 4; otherwise go to step 3. step 3, Ask the question to the root name servers. If it finds the answer queried, go to step 5 and step 4 simultaneously; otherwise go to step 4. step 4, The resolver has the necessary information and followed the steps specified in RFC 1035. End. step 5, If it is a DNSSEC query to the root, the resolver should validate the response from the root with DNSSEC; if it passes the DNSSEC validation, the resolver should put these TLD RRs into the root data cache, and set the refresh timer with the default value for these RRs; if it does not pass the DNSSEC validation, these RRs will not be put into the root data cache; end. If it is not a DNSSEC query, go to step 6. step 6, The resolver should send another query with the same question with DNSSEC to the root. If the response from the root passes the DNSSEC validation, the resolver should put the TLD data in the response into the root data cache, and set the refresh timer with the default value for these RRs. If these TLD RRs can not pass the DNSSEC validation, it should discard them without caching. End. Note: The basic implication is that all sanity checks on any TLD RR should be performed before any of it is cached into the root data cache. 5. System Requirements In order to implement the mechanism described in this document: o The system MUST be able to validate DNSSEC resource records. o The system MUST have an up-to-date copy of the DNS root key. o Only root TLD data from root zone should be cached. 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 Yao, et al. Expires March 31, 2016 [Page 6]
Internet-Draft root-cache-solution September 2015 for the DNS. It is possible to change the unsigned data in the root data cache, but that operation MUST not be allowed. 6. Requirement of the Root Data Cache Root cached data will be discarded by a timeout mechanism with refresh timer value or by the root data anlayzer when the data of the root zone is changed. The requirements to run the root data cache are shown below: o Inside the root data cache, refresh timers for cached root data conceptually "count down", while TTL in the RR will be kept in the constant value. o When the RRs are exported from root data cache, the refresh timer will be removed and the TTL in RR will start to "count down". o Every RR will be assigned a refresh timer with the default value when it is put into the root data cache. o The root data cache should discard old RRs whose timer has expired. The resolver may make the queries to several different root name servers to answer a particular user query. Since all the root servers serve the same root data, it will not impact the data accurance. 7. Requirement and Operation of the Root Zone Analyzer The resolver expects to cache root data which it receives in responses from the root since it is useful in answering future client requests. However, there are several types of data which should not be cached: o any data not from the root o a possibly partial set of the RRs of the same type for a particular TLD name o TLD data that does not pass the DNSSEC validation o Any TLD data from the root data cache itself The system should periodically checks to make sure that its root data cache are up to date. It MUST discard the cached root data if the data is outdated. The steps to run the Root Zone Analyzer are shown below: Yao, et al. Expires March 31, 2016 [Page 7]
Internet-Draft root-cache-solution September 2015 step 1, Get the SOA value from the root name server query, set root data cache's version No. = serial of SOA; refresh timer value = expire value of SOA. step 2, Get the full root zone, and do the same digest operation ( such as MD5 [RFC 1321]) to the root zone data excluding the SOA and its RRSIG. Set the root data cache fingerprint = the digest value. step 3, Check the SOA record from the root name server, and compare the serail of the SOA with the version No. of root data cache. If the value is same, wait for fixed time (the suggested time is the refresh value of SOA of the root zone or every 15 minutes) and go to step 3; If the value is not same, go to step 4. step 4, Notify that the root data cache should stop response to the resolver temporarily and give a message to the resolver that no answer has been found for the question. Get the full root zone, and do the same digest operation ( MD5 [RFC 1321]) to the whole root zone data excluding the SOA and its RRSIG. Compare the digest value with the fingerprint of root data cache. If the value is same, set root data cache's version No. = current serial of SOA; if the RRs of root SOA and its RRSIG are in the root data cache, they should be updated to the new one; notify that the root data cache should start response to the resolver immediately and go to step 3. If the value is not same, the system MUST discard all data in the root data cache, notify that the root data cache should start response to the resolver immediately and go to step 1. 8. IANA Considerations This document requires no action from the IANA. 9. Security Considerations A DNS cache may become poisoned when unauthorized RRs are inserted into it. A non-DNSSEC query may suffer from this problem in the same way as any resolver that does not do DNSSEC validation on responses from a remote root server. The resolver with a DNSSEC query will know how to deal with it. DDOS attackers may aim to the root data cache. They may query random invalid root TLD. In our current design, the root data cache will not cache any negative answers from the root. Yao, et al. Expires March 31, 2016 [Page 8]
Internet-Draft root-cache-solution September 2015 10. Change History RFC Editor: Please remove this section. 10.1. draft-yao-dnsop-root-cache: Version 00 o Decreasing fetch time of Root Data by Improving the Mechanism of Root Data Cacheing 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>. [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, <http://www.rfc-editor.org/info/rfc4035>. Yao, et al. Expires March 31, 2016 [Page 9]
Internet-Draft root-cache-solution September 2015 11.2. Informative References [Root-loopback] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root Servers by Running One on Loopback", May 2015, <https://datatracker.ietf.org/doc/draft-ietf-dnsop-root- loopback/>. Authors' Addresses Jiankang Yao CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3007 Email: yaojk@cnnic.cn Ning Kong CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3147 Email: nkong@cnnic.cn Xiaodong Li CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3020 Email: xl@cnnic.cn Yao, et al. Expires March 31, 2016 [Page 10]