Domain Name System Operations D. Liu Internet-Draft Z. Liu Intended status: Best Current Practice Alibaba Group Holding Ltd. Expires: September 21, 2016 Z. Yan L. Pan G. Geng CNNIC March 20, 2016 Operation Recommendations for DNS Cache Service draft-liu-dnsop-dns-cache-00 Abstract In this document, we give some recommendations to operate the DNS cache service based on our previous work and practice. 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 September 21, 2016. Copyright Notice Copyright (c) 2016 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 Liu, et al. Expires September 21, 2016 [Page 1] Internet-Draft DNS Cache Management March 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Recursive cache . . . . . . . . . . . . . . . . . . . . . . . 2 4. Selection of cached data . . . . . . . . . . . . . . . . . . 3 5. Update of cached data . . . . . . . . . . . . . . . . . . . . 3 6. Response of the cached data . . . . . . . . . . . . . . . . . 3 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 10.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction DNS cache directly serves the DNS queries from stub resolvers as the data source in the specified network area. For the present, however, the operators manage and run the cache service in a diversified manner as surveyed in the draft[I-D.wang-dnsop-cachesurvey]. In this document, we give some recommendations to operate the DNS cache service based on our previous work and practice. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Recursive cache To meet the respective demands of business operation and IT operation, the cache service plays an important role for the recursive service. Basically, the cache should consist of two parts: online cache and offline (or backup) cache. Specifically, the online cache serves the stub resolvers directly, and the backup cache is mainly used in the emergency case as a backup data source. Regarding the cached data and management policy, they are operation-dependent but we try to give the recommendations as follows. Liu, et al. Expires September 21, 2016 [Page 2] Internet-Draft DNS Cache Management March 2016 4. Selection of cached data In order to optimize the recursive performance with cache service, the domain names requested most frequently should be cached, for example, root zone file, part of hot TLD zone files and domain names cover Top-N DNS query. For the positive cache, the A, AAAA, CNAME, MX , NS, DS and RRSIG RRs must be cached. Besides, the NXDOMAIN and SERVFAIL RR also should be cached as negative cache. The cached data and type may be differentiated based on location and preference of stub resolvers. Public DNS which serves large area and supports endns-client-subnet should cache data with client location information. 5. Update of cached data In order to maintain the data freshness, the cache should be updated continually based on the behavior of stub resolvers or the statistics of domain names. For the former case, the data is updated when the stub resolver requests the specified domain name. While for the latter case, the recursive server pre-fetches the hot domain names before expiration and updates them actively. Because the cached date is managed by the TTL, the TTL can be updated based on the normal TTL setting or prolonged by the cache server. Cut down the cache update interval on NS RRs of hot domain names can shorten the RTO (Recovery Time Object) of DNS service when authority DNS server network fluctuation. 6. Response of the cached data In normal case, response of the cached data should not be modified. Some recursive servers return specified IP when raw response is NXDOMAIN and no cached data. For example, recursive servers can return recent historical cached RR when query is temporary SERVFAIL or NODATA. Recursive servers can modify the TTL of RR cached data. When recursive server cut down the TTL of domain NS record less than one day, long existence risk for name server hijack can be depressed. When recursive server raises up the TTL of RR more than one hour, the junked query cost on very short TTL (about 1s~30s) can be optimized, but some of RTT sensitive services like video and game which need quick service IP dispatch through CDN by short TTL (about 600s) may be negatively influenced. Liu, et al. Expires September 21, 2016 [Page 3] Internet-Draft DNS Cache Management March 2016 Recursive servers may modify RR rotation by RTT detection. When recursive server sets the order of NS RR according to shorter RTT firstly policy, it will get the benefit of the short response time. But when recursive server applies the same policy to A RR, it will result in the failure of load balance, which is based on RR rotation. Temporary domain names such as domains for virus update have a short lifetime, for which the DNS response will vary from A to NXDOMAIN when TTL expire. Because of that, there will be huge temporary domain information on cache database that should be optimized. Some authority servers support edns-client-subnet [I-D.ietf-dnsop-edns-client-subnet]or some other GSLB (Global Server Load Balance) solution, authority servers may return different A RR response to different client IP. If cache contains client IP information, the size of cache database will be enlarged, recursive server should extend policy on selecting RR response by client IP geo-location and ISP information. 7. Security Considerations Recursive servers are easily attacked by DDoS, especially attacked from botnet. It is recommended to analyze DNS traffic to extract some access control rules, which can be applied to recursive servers to block the attack traffic. Global DNSSEC deployment progress is less than 5%, there is still high DNS hijack risk on the Internet. If recursive server receives hijacked RR from hacked authoritative server or evil middle node in the communication link, without any security check policy, the cached data may be polluted. Large public DNS service should support hijack analysis on hot domains before response RR data is added into cache database. For security consideration, recursive server makes iterate DNSSEC enabled query to get NS RR, should prefers TCP to UDP when making DNS query to second level domain authoritative servers. Furthermore, cached data can be classified into different security level. For example, history IP frequency, history hijacked IP set, history high-risk domain set and history high risk register set. All of them should be used to filter cached data before sending response to clients. Liu, et al. Expires September 21, 2016 [Page 4] Internet-Draft DNS Cache Management March 2016 8. IANA Considerations This draft does not request any IANA action. 9. Acknowledgements The authors would like to thanks the valuable comments made by XXX and other members of DNSOP WG. This document was produced using the xml2rfc tool [RFC2629]. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.ietf-dnsop-edns-client-subnet] Contavalli, C., Gaast, W., tale, t., and W. Kumari, "Client Subnet in DNS Queries", draft-ietf-dnsop-edns- client-subnet-06 (work in progress), December 2015. [I-D.wang-dnsop-cachesurvey] Wang, W. and Z. Yan, "A Survey of the DNS cache service in China", draft-wang-dnsop-cachesurvey-00 (work in progress), February 2015. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . Authors' Addresses Dapeng Liu Alibaba Group Holding Ltd. Email: max.ldp@alibaba-inc.com Zhihui Liu Alibaba Group Holding Ltd. Email: chenghuang.lzh@alibaba-inc.com Liu, et al. Expires September 21, 2016 [Page 5] Internet-Draft DNS Cache Management March 2016 Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing, 100190 P.R. China Email: yan@cnnic.cn Lanlan Pan CNNIC No.4 South 4th Street, Zhongguancun Hai-Dian District, Beijing, 100190 P.R. China Email: panlanlan@cnnic.cn Guanggang Geng CNNIC No.4 South 4th Street, Zhongguancun Hai-Dian District, Beijing, 100190 P.R. China Email: gengguanggang@cnnic.cn Liu, et al. Expires September 21, 2016 [Page 6]