Internet DRAFT - draft-madi-dnsop-drzom
draft-madi-dnsop-drzom
DNSOP Di Ma
Internet Draft Feng Han
Intended status: Informational ZDNS
Expires: May 30, 2015 Linjian Song
BII
November 26, 2014
Considerations on the evolution of DNS root zone operation
and management
draft-madi-dnsop-drzom-00
Abstract
Given responsibilities and importance it bears, DNS root system
architecture remains largely unchanged. Over the years, the topics
together with some proposals of scaling the root have been discussed
in various communities, trying to offer solutions or insights to a
specific issue of DNS root operation. This document gathers and
describes issues relating to the root zone operation and management
and comb corresponding technical requirements for evolution
directions of root zone operation and management in new groundwork.
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 May 30, 2015.
Copyright Notice
Copyright (c) 2014 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
Di Ma, et al. Expires May 30, 2015 [Page 1]
Internet-Draft Evolution of DNS root November 2014
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.
1. Introduction
DNS service links naming space and addressing system, a connecting
thread through the Internet infrastructure. DNS was designed as a
hierarchical system with a few TLDs and slow update frequency. Rarely
has the domain name system faced so many significant changes in its
root zone operation and management, with DNSSEC-signed zone file,
IPv6 adoption and new gTLD. Besides, DNS is expected to deliver more
responsibilities by supporting DANE (DNS-based Authentication of
Named Entities) that allow Internet applications to establish
cryptographically secured communications by using information made
available in DNS, which by the way, has been launching discussions in
IETF DANE WG. Given responsibilities and importance it bears, DNS
root system architecture remains largely unchanged. Issues of root
security and stability have been stated in many technical reports
[RFC2870] [SAC042] [SAC046]. Over the years, the topics together with
some proposals of scaling the root have been discussed in various
communities, trying to offer solutions or insights to a specific
issue of DNS root operation.
"Scaling the root" was one of remarkable issues when it comes to
evolve the current root system. It could be to extend the number of
root name servers, or it could be to make the root operation
mechanism scale to bigger zone file and higher update frequency, or
it could still be to establish a more open root zone publication
system. DNS root operation is critical service to the Internet and
any changes to it ought to be in a prudent way, assuring security and
stability. Among others, zone file management, the focal thing in
root operation, is a systematic task, involving kinds of multi-
stakeholders in Internet community. We cannot get the pleasing
outcome for root scaling without reviewing the DNS root operation and
management on the whole.
This document, inspired by [icann-ITI] and [RSST], is intended to
gather and describe issues relating to the root zone operation and
management and comb corresponding technical requirements for root
zone evolution directions, before the IETF community gives solutions
to the very issues.
Di Ma, et al. Expires May 30, 2015 [Page 2]
Internet-Draft Evolution of DNS root November 2014
2. Modeling DNS root system operation
2.1. DNS root system components
As described in many technical reports and also a common view, there
are three sub-systems involving DNS root zone operation and
management:
The Resolving System publically interfaces with DNS resolvers, by
responding to root zone query requests via DNS protocol data units.
The Publication System distributes the root zone file to the root
servers (including anycast clones) and arranges for the information
in the root zone file to be available for the construction of
responses to queries.
The Provisioning System processes change requests, maintains the
authoritative database of root zone information, and periodically
creates a root zone file that contains the authoritative root zone
information.
2.2. Roles in DNS root system operation
In accordance with this model, DNS root system roles could be
therefore identified:
Root Zone Coordinator (RZC): RZC works as an administration body of
root zone operation. RZC, as a workflow interface with TLD
registries, receives and processes root zone change requests and
executes administration to TLD registries. With DNSSEC deployment,
RZC additionally delivers the responsibility of root zone Key Signing
Key (KSK) management. Accordingly, RZC is recognized as a root zone
operation representative to the public. The role of RZC is part of
IANA functions, acted by ICANN currently.
Root Zone Host (RZH): The role of RZH is to maintain reliable,
secure, and accurate operation of the DNS name servers that publish
root zone data they fetch from RZC (IANA). As a distribution channel
for root zone data, RZH is responds to root zone information queries
via DNS messages. As well known, there are 13 sets of root name
server IPv4/IPv6 addresses reflecting hundreds of individual machines
representing RZH, denoted by 13 letters from A to M, operated by 12
independent organizations worldwide.
Root Zone Maintainer (RZM): RZM is the backend operator of root zone.
Viewed as a technical role, RZM takes the responsibility of
generating (updating) root zone file together its digital signature,
and distributes DNSSEC-signed zone file to Root Zone Host (RZH). RZM.
Di Ma, et al. Expires May 30, 2015 [Page 3]
Internet-Draft Evolution of DNS root November 2014
At present, VeriSign serves as RZM.
Root Zone Administrator (RZA): RZA is privileged to perform the
review and approval function that authorizes each individual change
to the root zone. The RZA imparts nothing to the root zone but merely
explicitly authorizes these changes by verifying that RZC has
followed established policies and procedures in processing the
requests. At present, the role of RZA is played by National
Telecommunications and Information Agency (NTIA), a governing body of
the United States.
3. Evolution directions
This section is to list the evolution directions with the purpose to
make DNS root system remain an unshakable corner stone of DNS
operation with security, stability as well as high efficiency, while
provide a better and up-to-date service. Responding to root queries
with security and stability is the fundamental among others for root
system. In this document, the evolution of DNS root system is
identified hereby as a set of key issues with respect to resolving
system, publication system and provisioning system.
3.1. DNS protocol data unit and Resolving System
One of the fundamental problems of DNS protocol is the UDP size
limitation, which is caused by the IPv4 MTU setting in the early days
of Internet. Efforts made by EDNS introduce a negotiation mechanism
to support bigger DNS protocol data unit. However, owing to either
capability or filtering policy of intermediate networking devices,
EDNS fails to get the pleasing expectation that it is designed for.
Granted, EDNS is improving over time with updated versions. IPv6 is
yet another thing that DNS protocol data unit can benefit from. IPv6-
capable mandates an MTU of 1280 bytes, which means, even without
EDNS, the size of DNS protocol data unit could be still improved by
the virtue of IPv6 fundamentally. Where and when acceptable, TCP is
still another option for carrying DNS messages [RFC5966].
With a bigger DNS protocol data unit, more information can be
included in DNS message, especially offering a chance to enhance the
Resolving System. By far, there are significant issues regarding the
Resolving System owing to the limitation of the size of DNS protocol
data unit.
When a recursive name resolver is bootstrapped, it uses a hints file
or other statically pre-configured initial glue to find a root
server, and then it asks that root server for the current list of
root servers, with the expected answer the full list of RZH and their
addresses, the process of which is called "priming exchange". For one
Di Ma, et al. Expires May 30, 2015 [Page 4]
Internet-Draft Evolution of DNS root November 2014
thing, with the inclusion of IPv6 addresses for RZHs, the response is
even longer. In the case of 13 RZHs, there is no placing all the IP
addresses of all dual-stake RZHs in a priming response with UDP
limitation of 512 bytes. For another thing, it has been decades since
there were 13 RZHs, which was a calculated one regarding to specific
constraints. The number of RZH is by no means a constant for DNS
system but a variable parameter when and where possible. And still
for another thing, when DNSSEC signatures are added to the root zone,
the response message to the priming query or DNSKEY query will exceed
512 bytes accordingly.
Together with the tendency that DNS is delivering more
responsibilities, bigger protocol data units will therefore
facilitate advancements designed to scale the root system in the days
to come.
3.2. Root zone synchronization and Distribution System
DNS root sub-systems are not organized closely to one another but
root zone keeps changing. Data synchronization is therefore
fundamental to root zone distribution from RZM to RZH via
Distribution System. Considering DNS tends to be more dynamic,
synchronization should be taken into account when a new Distribution
System is introduced.
In alignment with current DNS operation, DNS root name servers ({A-
M}.root-servers.net), serving as RZH, receive queries from clients
using the DNS protocol and provide appropriate responses. As one
important channel to publish root zone information, the root name
servers have been subjected to attacks over the decades, mostly of
the Distributed Denial Of Service (DDOS) variety. Besides,
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. As a point of view from [icann-ITI], in a
world sized distributed system like the Internet, critical services
ought to be extremely well distributed.
Historically and from the perspective of protocol, the channel for
distributing root zone information guarantee the authenticity. This
situation has been changed by DNSSEC that was designed to provide a
security extension to DNS. One of the ways that we can benefit from
DNSSEC is DNSSEC-signed root zone file itself guarantee authenticity
no matter where it is fetched as long as contents of this zone file
could go through the validation based on DNSSEC information with a
globally-trusted single key maintained by IANA. Therefore, the
deployment of DNSSEC and the advantage it brings about could evolve
the root zone Distribution System scaling to a more open fashion.
Accordingly, an open publication system of DNS root zone is
Di Ma, et al. Expires May 30, 2015 [Page 5]
Internet-Draft Evolution of DNS root November 2014
desirable. The role of RZH is expected to be played in a different
way. By the virtue of DNSSEC-signed root zone, theoretically, any
entity with good credit and network could be authorized to host root
zone as long as the hosted zone file is approved and signed by IANA.
Note that the selection process of the RZH candidate is out of the
scope of this document.
Some efforts have been made. For instance, [I-D.dnsop-dist-root]
proposes an enhancement that recursive DNS resolvers, serving as RZH,
get copies of the root zone, validate it using DNSSEC, populate their
caches with the information, and also give negative responses from
the validated zone. While [I-D.dnsop-scalingroot] positions that IANA
produce several additional forms of the DNS root zone by creating yet
another "golden address" pair. It asks the IANA to authorize an un-
owned pair of addresses that anyone can hang root service on.
Although promising, there are problems gripping the designs for open
publication system of DNS root zone. If DNS root zone publication
system operates in an open mode, far more RZHs are expected to take
part in. Given an increasing number of RZH, either recursive
resolvers or "universal anycast" endpoints or anything else, it
should be taken into account how to scale the zone file
synchronization mechanism to the much bigger groups of RZHs, ensuring
consistence and negligible delay. Optimized root zone file
distribution mechanism would be desirable. For example, TLD KSK
rollover should be accomplished within a specific time, requiring the
DS records update should synchronized beforehand timely.
Besides, open publication brings about a more diverse group of RZHs,
including ones that are deployed in a poorly-connected Internet
locations. And an increasing size of root zone file can easily be
served from sites with high-bandwidth connections and ready access to
servers and other computing infrastructure. It cannot easily be
served from sites with poor connectivity or infrastructure. A
synchronization mechanism of this open publication that can scale to
networking diversity is also indispensable.
3.3. Root zone update and Provisioning System
3.3.1. Update frequency
The size of root zone file is attached with significance. "Size" here
is not merely referred to as how many bytes the zone file has, but
also with the number of delegations considered. A conspicuous
observation is root zone has been growing up. As analyzed in [icann-
impact-newgTLD], the number and size of records in the root zone has
successfully grown over time, in part to accommodate new developments
like the introduction of IDN ccTLDs, the first two rounds of new
Di Ma, et al. Expires May 30, 2015 [Page 6]
Internet-Draft Evolution of DNS root November 2014
gTLDs, the introduction of IPv6 glue records, and the deployment of
DNSSEC in the Root Zone. There is also a natural tendency for the
number of name servers per delegation to increase as TLD name server
infrastructure matures over time.
As indicated in [RSST], due to introduction of DNSSEC and TLD update,
the transferring frequency of root zone will, as estimated and
desirable, remarkably increased, bring about the undesirable latency,
which will place a significant impact on root operation. The very
observation and analysis is yet another significance that should be
included into the context of root zone management evolution.
DNS root zone is getting bigger in an unprecedented rate and to an
unpredictable size. Ever since the new gTLD program was launched by
ICANN, more than 400 new gTLDs have been delegated so far. As a
natural tendency and estimated, more and more TLD operators will get
involved in root system, thus the rate of change or update would
increase proportionately. These changes includes:
1. Delegation and re-delegation
These are additions of new top-level domains or the transfer of
operation of a top-level domain from an existing operator to a
new operator. There might also be the removal of a top-level
domain.
2. Changes in contact information
There are usually three official points of contact for a top-
level domain, the formal head of the operator, the administrative
contact and the technical contact. Each of these can change from
time to time. The Root Zone Registration Data ("WHOIS") system is
therefore affected.
3. Changes in the set of name servers
Each top-level domain is served by two or more name servers. Top-
level domain operators occasionally add to, change, or remove
name servers from their set.
4. Changes in the addresses of name servers
Name servers are occasionally renumbered. Also, when a new name
server is added to the set serving a TLD, its address must also
be added.
5. TLD KSK rolling
TLD operators request to update their DS records in root zone.
For each change, current root server system has several parties
involved which including RZA, RZS, RZM and RZHs. And the whole
process consists of several manual steps, which dramatically
Di Ma, et al. Expires May 30, 2015 [Page 7]
Internet-Draft Evolution of DNS root November 2014
decrease the efficiency and predictability of the update process.
To make the whole process automated and use other zone update
policy (for example, dynamic update), measures should be taken to
fulfill the impending improvement to the Provisioning System.
3.3.2. Shared zone control
Over the years, concerns have been raised towards current root
operation is based in the Untied States and subject to the
jurisdiction of the United States. Due to the multi-stakeholder mode
advocated and coordinated by ICANN, shared control on root zone is
desirable by many and technical specification is needed therefore.
One straightforward thought is that root zone data should have
multiple signatures. Some theories have been advanced together with
multiple signing protocols.
Technically, efforts have been made on coordinating DNSSEC signing
information and multiple signing protocols. But how to make these
technologies fit into the context of shared control on DNS root is
still an open question, which should follow current root operation
practices with new risks evaluated. As indicated in [icann-ITI], the
right model is one in which all of the parties sharing control have a
set of capabilities:
1. A system for initiating a shared zone consisting of the zone
itself, rules, and individual journals for each of the
participants to post their requests and actions.
2. Each type of request is visible to all of the other participants
who can approve, disapprove, or timeout.
3. Rules define what happens to a request
* One type of a rule is a vote, which defines the conditions
for a request to succeed. This might include a delay for all
parties to have time to consider the request. For ccTLDs the
WSIS rules would dictate 1 of N, so each Country Code Top
Level Domain (ccTLD) could unilaterally change its own data.
Other domains might use a simple majority
* Specified delays could be important so that others might be
able to point out operational issues and let the requesters
reconsider
* Different conditions might apply for different operations,
such as creating a new vs. editing, etc.
4. Security Considerations
Di Ma, et al. Expires May 30, 2015 [Page 8]
Internet-Draft Evolution of DNS root November 2014
TBD
5. IANA Considerations
TBD
6. Acknowledgements
The authors would like to thank Bill Manning and David Conrad for
reviewing this document.
7. Informative References
[RFC2870] R. Bush, D. Karrenberg, M. Kosters, R. Plzak.,
"Root Name Server Operational Requirements", RFC 2870,
June 2000.
[SAC042] SSAC Comment on the Root Scaling Study Team Report and the
TNO Report,
https://www.icann.org/en/system/files/files/sac-042-en.pdf
[SAC046] Report of the Security and Stability Advisory Committee on
Root Scaling.,
https://www.icann.org/en/system/files/files/sac-046-en.pdf
[RFC5966] R. Bellis., "DNS Transport over TCP - Implementation
Requirements", RFC 5966, August 2010.
[icann-ITI]
Identifier Technology Innovation Panel,
https://www.icann.org/resources/pages/identifier-
technology-2013-10-11-en
[I-D.dnsop-scalingroot]
Xiaodong Lee, Paul Vixie and Zhiwei Yan., "How to scale
the DNS root system", draft-lee-dnsop-scalingroot-00(work-
in-progress), July 2014.
[I-D.dnsop-dist-root]
W. Kumari, P. Hoffman., "Securely Distributing the DNS
Root", draft-wkumari-dnsop-dist-root-01(work-in-progress),
July 2014.
[icann-impact-newgTLD]
Joe Abley and Kim Davies., "Impact on Root Server
Operations and Provisioning Due to New gTLDS", June 2012.
Di Ma, et al. Expires May 30, 2015 [Page 9]
Internet-Draft Evolution of DNS root November 2014
[RSST] Jaap Akkerhuis, Lyman Chapin, Patrik Faltstrom, Glenn
Kowack, Lars-Johan Liman and Bill Manning., "Report on the
Impact on the DNS Root System of Increasing the Size and
Volatility of the Root Zone", September 2009
Authors' Addresses
Di Ma
ZDNS Ltd.
4, South 4th Street, Zhongguancun
Haidian, Beijing 100190
China
Email: madi@zdns.cn
Feng Han
ZDNS Ltd.
4, South 4th Street, Zhongguancun
Haidian, Beijing 100190
China
Email: hanfeng@zdns.cn
Linjian Song
Beijing Internet Institute
2508 Room, 25th Floor, Tower A, Time Fortune
Beijing 100028
China
Email: songlinjian@gmail.com
Di Ma, et al. Expires May 30, 2015 [Page 10]
