DNSOP Working Group Xiaodong Lee
Internet Draft CNNIC
Expires: January 2015 Vixie Paul
Farsight Security, Inc.
Zhiwei Yan(Ed.)
CNNIC
July 3, 2014
How to scale the DNS root system?
draft-lee-dnsop-scalingroot-00.txt
Abstract
In Domain Name System (DNS), 13 root servers are deployed in order
to provide the entrance of domain name resolution and they are
denoted by 13 letters. From 2000 or so, the anycast technology has
been adopted to extend the number of root servers with the explosive
development of Internet. To date, 11 of the 13 letters are hosted at
multiple sites, and the root zone is served at about 380 sites
around the globe. However, increasing mirror sites is not a perfect
solution to scale the DNS root servers because the geographical
distribution of the current 13 root servers is uneven and only
increasing mirror sites cannot solve the efficiency and scalability
issues caused by that. Then we propose a new DNS root system in this
draft based on the widely deployed Domain Name System Security
Extensions (DNSSEC). The proposed architecture is scalable and
secure enough to meet the current and future needs to scale the DNS
root system in an easy-deployment way.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
X.D. Lee et al. Expires January,2015 [Page 1]
Internet-Draft How to scale the DNS root system? July 3, 2014
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January, 2015.
Copyright Notice
Copyright (c) 2010 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 the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 2
2. Motivations ................................................. 3
3. Proposed architecture........................................ 5
4. Management considerations.................................... 8
5. Security considerations...................................... 9
6. References .................................................. 9
Author's Address .............................................. 10
Acknowledgment ................................................ 11
1. Introduction
In Domain Name System (DNS), 13 root servers are deployed and they
are denoted by 13 letters from A to M. From 2000 or so, the anycast
technology has been adopted to extend the number of root servers
with the explosive development of Internet. To date, 11 of the 13
letters are hosted at multiple sites, and the root zone is served at
about 380 sites around the globe [1,2].
X.D. Lee et al. Expires January,2015 [Page 2]
Internet-Draft How to scale the DNS root system? July 3, 2014
With the continuous development of Internet, more and more DNS root
servers have to be deployment in order to meet the efficiency and
stability requirements of the DNS root system. On one hand, the DNS
resolution efficiency should be high enough to support more and more
Internet users and their sophisticated applications. On the other
hand, the DNS root system has to be stable enough to face the cyber
attacks which are becoming more and more serious [3]. Then, how
about deploying more anycast mirror sites? Without doubt, this
scheme can improve the efficiency and stability of DNS root system
as usual, but its problems are:
a) This scheme is not open enough to satisfy the special
requirements of a country or district or organization (CDO). If a
CDO wants to deploy a root server to serve its local users, the
current procedure is complex and it is almost impossible for the CDO
to control the deployed site no matter the type of the site is local
or global. Specially, the current root name servers have respective
Root Name Server Operators (RNSOs), to whom IP address blocks have
been allocated. The CDO wants a root server mirror site must
coordinate anycast routing configuration and server placement with
the corresponding RNSO.
b) This scheme is not stable enough. When one root server is
attacked and fails down, its anycast mirrors cannot do the zone file
synchronization and the DNS root service may be affected.
2. Motivations
During recent years, many CDOs declare their anticipation to host a
DNS root server. And how to adjust the placement of the current 13
DNS root servers also drew a lot of attention from both academic and
technical worlds [2]. However, it's very difficult to change the
current belonging situation of DNS root servers. If possible, it's a
good idea to deploy more root servers (not just the mirror sites) to
solve or relieve the above problems.
In the IPv4 based Internet, only 13 root servers are allowed due to
the 512-byte limitation. However, adding the IPv6 address
information for more than two root name servers will increase the
size of the DNS priming response to exceed this maximum. Ultimately,
when all 13 root name servers assign IPv6 addresses, the priming
response will be increased to 811 bytes [3]. Specially, if a message
cannot fit in the 512 bytes, the server must set a special flag
indicating that the message was truncated. When receiving such a
message, a DNS resolver will normally retry the transaction using
TCP instead of UDP [4]. However, the costs of using TCP rather than
UDP, in terms of system and network resources, are much higher and
X.D. Lee et al. Expires January,2015 [Page 3]
Internet-Draft How to scale the DNS root system? July 3, 2014
can have significant impact on systems such as name servers that may
receive several thousands of queries per second during normal
operations. At the same time, with the promotion from ICANN, work is
in progress to put forward a recommendation that will enable the
publication of IPv6 addresses for, at least, DNS root servers in as
short a time as possible. Besides, with the exhaustion of IPv4
address, the IPv6 is promoted from all parties in the community.
Currently, 10 IPv6 addresses have been configured on the root
servers and the total size of the DNS priming response message has
been increased to above 512 bytes (We even do not consider the
DNSSEC herein, which increases the DNS response message more
tremendously).
Above background means that the 512-byte limitation does not
actually exist anymore in the DNS [5]. Then how many DNS root server
can be increased further? We take the IPv6 supported Internet as an
example, then the DNS priming response message structure is shown in
the following if we set the maximum number of root servers is N [6].
--Required Header: 12 bytes
--Query: 5 bytes
--Answer: 31+15*(N-1) [the first answer is 31 bytes, the sequent
answers are reduced by 16 bytes due to compression]
--Additional Records: 16*N [each A record is 16 bytes]
--Additional Records: 28*N [each AAAA record is 28 bytes]
The IPv6 supported node is not required to reduce the size of
subsequent packets to less than 1280 bytes, but must include a
"Fragment Header" in those packets so that the IPv6-to-IPv4
translating router can obtain a suitable "Identification" value to
use in resulted IPv4 fragments. Note that this means the payload may
have to be reduced to 1232 bytes (1280 minus 40 for the IPv6 header
and 8 for the Fragment header) [7].
Then we get the following formula,
12+5+31+15*(N-1)+16*N+28*N<1232
Accordingly, N=20, which means that the root servers can only be
increased by 7 more in the IPv6 transport environment (without EDNS0
[8] and TCP supporting).
X.D. Lee et al. Expires January,2015 [Page 4]
Internet-Draft How to scale the DNS root system? July 3, 2014
In advance, DNSSEC should be considered because it is necessary to
guarantee the security of the DNS information and it has been widely
deployed (and will be more widely deployed in the future). If only
one kind of signature algorithm is used to generate the RRSIG
resource record, the size of DNS response message will be increased
to about 7 to 10 times comparing with the original one without
signing [9]. It means that it is unpromising to increase the root
servers further in the current architecture.
In the security aspect, criticisms of the current and historical
root name server system is lack of resistance to DDoS attack, noting
that even with the current wide scale anycasting by every RNSO,
there are still only a few hundred name servers in the world to
answer authoritatively for the DNS root zone. We are also concerned
that reachability of the root name server system is required even
for purely local communication, since otherwise local clients have
no way to discover local services. In a world sized distributed
system like the Internet, critical services such as DNS root system
ought to be extremely well distributed.
In a word, we have to design a new architecture to scale the DNS
root name server system and in this way the root server deployment
balance can be reconsidered (the future deployment can refer the
actual requirements such as the number of Internet users, amount of
Internet traffic and so on). Besides, this architecture should scale
the DNS root servers without the technology limitations as
illustrated above.
3. Proposed architecture
The proposed architecture is strongly based on the widely deployed
DNSSEC and shown in Figure 1. With DNSSEC, it is now possible for
recursive name server operators to configure DNSSEC validation, such
that any gTLD information heard from a root server (or mirror site)
must be IANA-approved as indicated by DNSSEC signatures made with
IANA's root Zone Signing Key (ZSK).
For the universal anycast root server nodes deployment, we here
provide two actual solutions:
1)
The DNS root service manager (may still be the IANA) would
generate and digitally sign (with DNSSEC) an additional version of
the root zone that has a different set of NS records at its apex.
These NS records will denote name servers whose addresses are not
assigned to any current RNSO but are instead held in trust by IANA
for use by any or all interested CDOs (Global Root X in Figure 1).
IANA would request infrastructure micro-allocations from an RIR
X.D. Lee et al. Expires January,2015 [Page 5]
Internet-Draft How to scale the DNS root system? July 3, 2014
(such as ARIN or APNIC), as several IPv4 24-bit prefixes and
several IPv6 48-bit prefixes, for use in universal anycasting of
the root zone. For example, the following configuration can be
used corresponding to the universal root server (Global Root X):
. IN NS anycast-X1.iana-servers.net.
. IN NS anycast-X2.iana-servers.net.
$ORIGIN iana-servers.net.
anycast-x1 IN AAAA 2001:?:1::1
anycast-x1 IN A ?.?.1.1
anycast-x2 IN AAAA 2001:?:2::2
anycast-x2 IN A ?.?.2.2
2) Based on the contract or approval of one or multiple RNSO, the
related root server can also be globally anycasted or locally
deployed and totally managed and controlled by a CDO (Root A1 in
Figure 1). This case is backward-compatible and does not need to
change the current DNS root system.
+-----------------------+
| Distribution Master |
+-----------------------+
/ / \ \
/ / \ \
+------+ +-------+...+------+ +------+
|Root A|...|Global | |Root M|...|Global|
+------+ |Root A1| +------+ |Root X|
/ +-------+ +------+
/ \ \
/ \ \
+-------+ +-------+ +------+
|Local | |Local | |Local |
|Root A | |Root A1| |Root X|
+-------+ +-------+ +------+
Figure 1. DNS root server architecture
We herein assume that the DNSSEC is widely deployed. In this way,
the root zone file will not be tampered or misused. If the DNS root
X.D. Lee et al. Expires January,2015 [Page 6]
Internet-Draft How to scale the DNS root system? July 3, 2014
server is a local site (Local Root A) and only serve for the
restricted area, it may be unnecessary for holding the global
anycast address. Still in this case, the local site (Local Root A)
can also expand its site to multiple mirrors within the local area
(for example, within one ISP's coverage) as the global node (Global
Root A1) does.
Accordingly, the DNS request message may be served by any root sever
during its transmission and the possible scenarios are shown in
Figure 2.
+---------------+
+----+ ( )
|ISP3|--( Backbone )
+----+ ( )
| +---------------+
| | |
[Root 3] | |
| |
| |
| |
+----+ +----+
[Root 1]--|ISP1|----------|ISP2|--[Root 2]
+----+ +----+
Figure 2. DNS resolution scenarios
We assume that one ISP only holds one DNS root server. In the first
case, the DNS request message originated from the edge user is
served by the root server deployed in the local network within the
same ISP (Root 1) and then the response can be served as soon as
possible. In the second case, the DNS request is transmitted to the
nearby ISP due to the routing protocol and responded by the root
server in the nearby ISP (Root 2). In the third case, the request
may travel all the way to the Internet backbone without having been
answered closely, in which case it may be answered by an RNSO who
has decided to advertise a route to the well known address of the
CDO root server (Root 3).
For the data synchronization, the current scheme can be used. After
the root zone file is produced, the Distribution Master (DM) (such
as the current hidden server) sends a DNS notify message to all root
servers and then every root server responds with an acknowledgement
to the DM. The DNS notify triggers the Start of Authority (SOA)
request. The DM replies with a message which includes the serial
number. If this serial number is higher than the number that is
X.D. Lee et al. Expires January,2015 [Page 7]
Internet-Draft How to scale the DNS root system? July 3, 2014
currently operated by the root server, the root server starts the
Zone Transfer (XFR) to retrieve the new root zone file. If this
serial number in the SOA response is not higher than the root
server's currently used version, the root server will take no
further action. If this scheme is adopted, each CDO root server has
to register with the DM in order to receive the notify message and
which is the requirement of the first deployment solution
illustrated above. While, for the second deployment solution, the DM
function may be the root server managed by the current RNSO.
Of course, a more open scheme is needed in the future for the root
zone file synchronization. Because the root zone file data is solid
and cannot be tampered, the CDO can actively fetch the root zone
file data according to its special requirement and configuration. We
mention this synchronization type because the CDO root servers may
be increased significantly in the future and the traditional scheme
explained above is not flexible and efficient enough.
In a word, DNSSEC makes it possible to deploy the DNS root servers
in a more distributed and flat manner, because any server can
synchronize the root zone file without modification.
4. Management considerations
Considering the deployment of the architecture proposed in this
draft, the following management questions should be answered:
1) How to manage the universal anycast DNS root servers?
We introduce the idea to globally distribute the root servers and
locally deploy multiple local nodes. In the routing aspect, the
anycast addresses will be broadcasted more widely for the global
nodes to be accessed anywhere. However, the addresses of the local
nodes have to be controlled in the local area (with the no-export
attribute in BGP routing protocol) to serve the requests from the
particular local area.
2) What are the principles to deploy the universal DNS root servers?
The principles or rules to select the service provider (CDO) and
deploy the root servers can refer to [10,11]. Besides, more actual
aspects can be considered in this new architecture due to its
minimized limitation to deploy a root server.
Other management and deployment issues will be added further.
X.D. Lee et al. Expires January,2015 [Page 8]
Internet-Draft How to scale the DNS root system? July 3, 2014
5. Security considerations
Although this architecture maintains the basic operations of the
current DNS root system and follows the standard DNS protocols, it
changes the current DNS root system because we want this mature
system to be flexibly scaled with the Internet. Then the following
issues related to security and stability may be caused:
1) Routing table: according to this architecture, more than 13 root
servers may broadcast their IP addresses globally. This will
increase the entries of the BGP routing table (even maybe only one
pair of additional anycast addresses (IPv4 and IPv6)).
2) Attack defense: due to the deployment of anycast servers is more
widely and the anycast nodes are increased a lot. How to secure
these nodes will be harder and more important. In order to manage
the increased global/local nodes, more sophisticated tools (such as
CHOAS resource record, Traceroute command, special monitoring and
analyzing platform) should be adopted and developed. In this way,
the anycast nodes can be identified and monitored effectively and
efficiently.
Of course, we believe that the future DNS root service provider
(many ccTLD and gTLD have deployed anycast service and manage it
well) for the global or local anycast nodes will have the experience
and ability to monitor and manage the servers and the possible
attack (such as DDoS) can be effectively detected and defended [12].
Other security issues will be discussed and detailed further.
6. References
[1] http://www.root-servers.org/.
[2] T. Lee, B. Huffaker, M. Fomenkov, and k. claffy. On the
problem of optimization of DNS root servers' placement. In
Proc. of Passive and Active Network Measurement Workshop (PAM).
April 2003.
[3] P. Vixie and A. Kato. DNS Response Size Issues. draft-ietf-
dnsop-respsize-15.txt. February 2014.
[4] R. Bellis. DNS Transport over TCP - Implementation
Requirements. IETF RFC 5966. August 2010.
[5] CAIDA. Analysis of the DNS root and gTLD nameserver system:
status and progress report. May 2008.
X.D. Lee et al. Expires January,2015 [Page 9]
Internet-Draft How to scale the DNS root system? July 3, 2014
[6] ICANN. Accommodating IP Version 6 Address Resource Records for
the Root of the Domain Name System. January 2007.
[7] S. Deering, and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. IETF RFC 2460. December 1998.
[8] P. Vixie. Extension Mechanisms for DNS (EDNS0). IETF RFC 2671.
August 1999.
[9] http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj
_7-2/dnssec.html.
[10] S. Sato, T. Matsuura, and Y. Morishita. BGP Anycast Node
Requirements for Authoritative Name Servers draft-sato-dnsop-
anycast-node-requirements-02.txt. September 2007.
[11] R. Bush, D. Karrenberg, M. Kosters, and R. Plzak. Root Name
Server Operational Requirements. IETF RFC 2870. June 2000.
[12] USC/ISI Technical Report. Identifying and Characterizing
Anycast in the Domain Name System. May 2011.
Author's Address
Xiaodong Lee
China Internet Network Information Center
No.4 South 4th Street, Zhongguancun
Beijing, P. R. China
Email: xl@cnnic.cn
Paul Vixie
Farsight Security, Inc.
155 Bovet Road, #476
San Mateo, CA 94402, USA
Email: vixie@farsightsecurity.com
Zhiwei Yan
China Internet Network Information Center
No.4 South 4th Street, Zhongguancun
Beijing, P. R. China
Email: yanzhiwei@cnnic.cn
X.D. Lee et al. Expires January,2015 [Page 10]
Internet-Draft How to scale the DNS root system? July 3, 2014
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
X.D. Lee et al. Expires January,2015 [Page 11]