Internet DRAFT - draft-yao-dnsop-root-cache
draft-yao-dnsop-root-cache
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]
