Internet DRAFT - draft-liu-dnsop-dns-cache
draft-liu-dnsop-dns-cache
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,
<http://www.rfc-editor.org/info/rfc2119>.
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,
<http://www.rfc-editor.org/info/rfc2629>.
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]
