Root DNSSEC Design Team D. Knight J. Abley ICANN M. Larson VeriSign January 11, 2009 DNSSEC Deployment for the Root Zone Abstract This document describes a plan for a controlled deployment of DNSSEC in the root zone of the DNS. Copyright Notice Copyright (c) 2010 Internet Corporation For Assigned Names and Numbers. All rights reserved. Copyright (c) 2010 VeriSign Inc. All rights reserved. Knight, et al. [Page 1] DNSSEC Deployment for the Root Zone January 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Concerns . . . . . . . . . . . . . . . . . . . . . 3 2.1. Large Responses . . . . . . . . . . . . . . . . . . . . . 3 2.2. Early-Adopters and Rollback . . . . . . . . . . . . . . . 3 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Staged Deployment . . . . . . . . . . . . . . . . . . . . . . 5 4.1. The DURZ . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Testing the DURZ . . . . . . . . . . . . . . . . . . . 6 4.2. Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Preparation phase . . . . . . . . . . . . . . . . . . 6 4.2.2. Deployment Phase . . . . . . . . . . . . . . . . . . . 6 4.3. Measurement . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Ongoing Traffic Statistics . . . . . . . . . . . . . . 8 4.3.2. Event Driven Full Packet Capture . . . . . . . . . . . 8 4.3.3. Ongoing Priming Query Capture . . . . . . . . . . . . 8 5. Roles and Responsibilities . . . . . . . . . . . . . . . . . . 9 5.1. Parties Organizing Signing . . . . . . . . . . . . . . . . 9 5.2. Root server operators . . . . . . . . . . . . . . . . . . 10 6. Analysis and Success Criteria . . . . . . . . . . . . . . . . 11 7. Communication Plan . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Knight, et al. [Page 2] DNSSEC Deployment for the Root Zone January 2009 1. Introduction This document proposes a staged, incremental deployment of DNSSEC in the root zone with the goal of having a fully-deployed, signed zone in place by 1 July 2010, suitable for use by validators. 2. Deployment Concerns 2.1. Large Responses A substantial number of deployed iterative resolvers currently set the DO bit on queries, regardless of whether DNSSEC validation has been enabled explicitly by operators. For example, approximately 70% of queries arriving at L.ROOT-SERVERS.NET have the DO bit set, a number which is considered disproportionately large given the infancy of DNSSEC deployment. After the root zone is signed, root servers will send much larger responses to these resolvers than they do currently, as priming responses, referrals and name errors. Large DNS responses pose a concern since it is not clear how many network paths, including middle-boxes and firewalls, will accommodate large responses. For example, a widespread lack of support for TCP transport for DNS traffic, or for UDP fragmentation, or even for non-fragmented UDP responses larger than 512 bytes might cause the DNS to appear noticeably unreliable, or even stop it from working altogether. +---------------+---------------+-----------------------+ | Zone | DNSSEC OK Bit | Priming Response Size | +---------------+---------------+-----------------------+ | Unsigned Root | DO=0 | 492 or 500 bytes | | Unsigned Root | DO=1 | 643 bytes | | Signed Root | DO=0 | 492 or 500 bytes | | Signed Root | DO=1 | 599 or 801 bytes | +---------------+---------------+-----------------------+ This document proposes that deployment of DNSSEC in the root zone be done in a manner which allows the change to be made as a series of smaller steps, where the impact of each might be gauged before proceeding with the next. 2.2. Early-Adopters and Rollback A growing number of early-adopters have been deploying validators for communities of end-users, using interim mechanisms such as DLV and manually or automatically-configured discrete trust-anchors from Knight, et al. [Page 3] DNSSEC Deployment for the Root Zone January 2009 repositories such as the IANA ITAR. It seems reasonable to imagine that such early-adopters might well choose to enable validation for the root zone before it is fully deployed, if the root zone is signed conventionally as part of the staged deployment. There is some concern that a need to rollback deployment of DNSSEC to provide relief to clients who are experiencing degraded DNS service (e.g. due to the effect of large responses, as discussed in Section 2.1) might itself degrade service for early-adopters who have come to rely on validation of responses from root servers. This document proposes a deployment which introduces large responses in a staged manner without conventional DNSSEC signing of the root zone. Under this proposal, the root zone will be signed in such a way that validation would not be possible until full deployment has occurred. 3. Goals The goals of this deployment plan are as follows: 1. At 00:00 UTC on 1 July 2010 all root servers are carrying the signed, validatable root zone and the trust anchor has been published such that it is possible for any Internet user to acquire, configure and use it to securely validate the content of the root zone. 2. That every opportunity has been given to every community of interest to observe the effect on the root server system of this deployment. A communications plan which covers both high-level information about the deployment as well as technical information related to design, operations and measurement will be made available to aid in this effort. 3. That every community of interest has been given an opportunity to provide information and raise any concerns during and following the deployment which, and that such information and concerns were assessed comprehensively in order to establish a clear picture of the effect of this deployment on the DNS system as a whole. 4. The transition to the signed root has been managed such that there is no significant community of users to whom the increased size of responses in queries to the root are a surprise at this time. Knight, et al. [Page 4] DNSSEC Deployment for the Root Zone January 2009 4. Staged Deployment A common practice among operators of any kind of service is to stage deployments such that changes to a system are introduced incrementally. For example, rather than upgrade the software of all name servers for a zone in one operation, it is preferable to perform upgrades on one server at a time, assessing the impact of each change and ensuring that there is no degradation in service before proceeding to the next. This approach of incremental change would normally be applied to server infrastructure rather than zone data. A consequence of using this method for the zone data is that during the rollout the root zone will not be coherent across all of the root servers. The same version of the root zone will contain DNSSEC records when served by some of the root servers, but no DNSSEC records when served by others. As this incoherence pertains only to DNSSEC records the class of clients for whom this would be an issue are those attempting to perform DNSSEC validation. A validator encountering an unsigned response from a server which has not yet transitioned to the signed zone would presume a man-in-the-middle signature stripping attack and declare the data bogus. The staged deployment strategy remains useful so long as there is no expectation among users that the signed zone be validatable during the transition. Simply opting not to publish a trust anchor is unlikely to be sufficient deterrent to the overzealous and misguided operator who, not realizing the incomplete state of the deployment might configure a DNSKEY from the zone as a trust anchor only to have validation fail. 4.1. The DURZ The Deliberately Unvalidatable Root Zone (DURZ) is a method to make an intentionally and visibly unvalidatable signed zone. The purpose of the DURZ is to allow a slow rollout of the signed root zone in such a way that attention can be focused on the effect this has on normal DNS resolution without premature consideration of any DNSSEC validation issues. The DURZ is constructed by signing the root zone in the same way as will be done in normal production, but with an additional pre- publication step which replaces the apex DNSKEY records with obvious, visibly bogus versions (see Figure 1). This will render the DURZ impossible to validate. Knight, et al. [Page 5] DNSSEC Deployment for the Root Zone January 2009 . 3600 IN DNSKEY 257 3 8 ( AwEAAa8Zp+++++THIS/IS/IN/AN/INVALID/ KEY/AND/CANNOT/BE/USED/FOR/VALIDATIO N/PLEASE/CONTACT/ROOTSIGN/AT/ICANN/D OT/ORG/FOR/MORE/INFORMATION+++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++8= ) ; Key ID = 42 Figure 1 4.1.1. Testing the DURZ The DURZ is proposed as a mechanism to allow a conservative and controlled deployment of new technology to the root. However, it itself is a new technology, it is possible that it's deployment will have unforeseen consequences for resolvers. It is not known that all resolvers will correctly handle the broken DNSKEY records proposed. This should be tested in simulation with a representative set of resolver implementations prior to it being used in the production root server system. 4.2. Schedule 4.2.1. Preparation phase VeriSign prepare the DURZ and make it available for transfer by the root server operators to test their ability to transfer and serve it from 25 January 2010. The schedule on which the root server operators will transition to the DURZ is described in Section 4.2.2. Each root server operator has committed to having completed preparations in advance of their scheduled transition date. 4.2.2. Deployment Phase Root servers will aim to transition to serving the DURZ on the following schedule. Individual root server operators will follow their own usual procedures specific to their infrastructure to execute the change within their maintenance window. Knight, et al. [Page 6] DNSSEC Deployment for the Root Zone January 2009 o Group 1, Week beginning Mon 25 Jan 2010: L L: 2010-01-27 1800 UTC -- 2010-01-27 2000 UTC o Group 2, Week beginning Mon 08 Feb 2010: A A: 2010-02-10 1700 UTC -- 2010-02-10 1900 UTC o Group 3, Week beginning Mon 01 Mar 2010: M, I M: 2010-03-03 0400 UTC -- 2010-03-03 0600 UTC I: 2010-03-03 1500 UTC -- 2010-03-03 1800 UTC o Group 4, Week beginning Mon 22 Mar 2010: D, K, E D: 2010-03-24 1400 UTC -- 2010-03-24 1500 UTC K: 2010-03-24 1500 UTC -- 2010-03-24 1700 UTC E: 2010-03-24 1800 UTC -- 2010-03-24 2000 UTC o Group 5, Week beginning Mon 12 Apr 2010: B, H, C, G, F H: 2010-04-14 1400 UTC -- 2010-04-14 1500 UTC C: 2010-04-14 1500 UTC -- 2010-04-14 1700 UTC G: 2010-04-14 1700 UTC -- 2010-04-14 1900 UTC B: 2010-04-14 1900 UTC -- 2010-04-14 2100 UTC F: 2010-04-14 2100 UTC -- 2010-04-15 0000 UTC o Group 6, Week beginning Mon 03 May 2010: J J: 2010-05-05 1700 UTC -- 2010-05-05 1900 UTC 4.3. Measurement Measurement is an important aspect of the staged deployment strategy, what is learned as each group of root servers transition to the DURZ will guide how the deployment is executed. It is expected that resolvers which can't hear large responses from root servers running the DURZ will move away to those servers which have not yet made the transition. If this movement can be detected it will be instructive as to how many resolvers are likely to have problems upon completion of the exercise. Knight, et al. [Page 7] DNSSEC Deployment for the Root Zone January 2009 In order to get useful measurement data the root servers should be instrumented and the output of that instrumentation shared at some central location for aggregation and analysis. 4.3.1. Ongoing Traffic Statistics Observing query volume and how it changes on particular root servers as the deployment proceeds might provide insight into macro-scale movements of query traffic between root servers. Being able to do coarse categorisation of query traffic (e.g. using the DSC tool) might allow the effects of deployment events to be observed despite the noise of unwanted traffic that would otherwise obscure it. Root server operators should collect traffic statistics and collaborate to identify any visible consequences of deployment events. 4.3.1.1. Testing Traffic Statistics Individual root server operators should be given the opportunity to deploy or enhance traffic measurement capabilities in advance of the deployment phase. 4.3.2. Event Driven Full Packet Capture Full packet capture entails recording every query arriving at a root server and then later uploading the captured queries to a central location. This is a bandwidth-intensive task and is not considered practical to carry out for the full duration of the deployment phase; rather it should be performed only at times when interesting traffic is expected, e.g. around the time of a root server transitioning to the DURZ. The capture should be done by all root servers, not just those transitioning to the DURZ and should be done for some hours before and after the scheduled transition time. 4.3.2.1. Testing Full Packet Capture Full packet capture will require root operators to perform captures, then upload capture data to a central location for analysis. The root operators should be given an opportunity to test this capture and upload. The analyst should verify that the uploaded data is in a usable format. 4.3.3. Ongoing Priming Query Capture Ongoing filtered packet capture is proposed as a method to gather interesting data which need not be run only periodically and may possibly be run at sites without dedicated measurement infrastructure where otherwise no packet capture would be possible. A libpcap expression which can be used with the tcpdump tool common to most Knight, et al. [Page 8] DNSSEC Deployment for the Root Zone January 2009 UNIX-like systems will be distributed. That expression will capture only interesting queries, priming queries for example. This type of capture should be of such low impact performance-wise that it can if necessary be run on production name servers directly. As with the full capture method there would be periodic upload of capture data to a central location for aggregation and analysis. 4.3.3.1. Testing Ongoing Priming Query Capture Benchmarking which shows the effect that this measurement would have on server performance will be required before it could be proposed to be run on a production server. This packet capture will require root operators to perform captures, then upload capture data to a central location for analysis. The root operators should be given an opportunity to test this capture and upload. The analyst should verify that the uploaded data is in a usable format. 4.3.3.2. Verification of Key Rollover Behaviour ICANN will engage technical experts to perform a quantitative assessment of KSK rollover throughout this staged deployment, in order to gain confidence that the systems used to effect key rollover follow the timers and related direction provided by [RFC5011], in order to facilitate automated trust anchor updates by DNSSEC validators. 5. Roles and Responsibilities 5.1. Parties Organizing Signing Internet Corporation for Assigned Names and Numbers (ICANN), as IANA Functions Operator o Manages the Key Signing Key (KSK) o Publishes the trust anchor for the root zone o Signs the Zone Signing Key (ZSK) with the KSK o Sends update requests to NTIA for authorization and to VeriSign for implementation VeriSign, as Root Zone Maintainer Knight, et al. [Page 9] DNSSEC Deployment for the Root Zone January 2009 o Manages the ZSK o Signs the root zone with the ZSK o Implements NTIA-authorized changes o Generates the DURZ and the bogus keys required by it o Distributes the unsigned root zone, DURZ and signed root zones to the root server operators National Telecommunications and Information Administration (NTIA) o Authorizes changes to the root zone o Checks that ICANN has followed their agreed upon verification/ processing policies and procedures 5.2. Root server operators The root server operators serve the root zone. ICANN and VeriSign, as root server operators themselves, have access to a database of contact information for their peers and will make use of that information as necessary as the deployment proceeds. A, J - VeriSign B - USC Information Sciences Institute (USC-ISI) C - Cogent Communications (Cogent) D - University of Maryland (UMD) E - NASA Ames Research Center (NASA-ARC) F - Internet Systems Consortium, Inc. (ISC) G - Department of Defense Network Information Center (DoD-NIC) H - U.S. Army Research Laboratory (ARL) I - Netnod K - Reseaux IP Europeens Network Coordination Centre (RIPE NCC) L - ICANN Knight, et al. [Page 10] DNSSEC Deployment for the Root Zone January 2009 M - WIDE Project (WIDE) 6. Analysis and Success Criteria This effort will generate a significant amount of data to be analyzed. The intent of the analysis is to discover any systemic or large-scale problems produced by the root zone DNSSEC deployment to allow sufficient time to notify the affected parties and remedy the problems or, as a last resort, postpone or halt the deployment altogether. Multiple factors will make this analysis challenging. First, the sheer volume of data contributes to the complexity. Second, previous research has shown that an overwhelming percentage of queries to the root servers are unnecessary [CAIDA]. As a result, finding useful information about the impact of the DNSSEC deployment among the extraneous packets will make the analysis difficult. The Root DNSSEC Design Team has developed broad parameters for analysis during the deployment; for example, studying the possible movement of traffic from servers serving the signed zone to servers serving the unsigned zone as described in Section 4.3. The details of the required analysis and the criteria to determine if deployment can proceed are still under development. To develop the best possible plan for analysis and to determine generally acceptable criteria to determine the safety of proceeding with deployment, the Root DNSSEC Design Team will solicit the Internet community's input on this topic in a separate document. Ultimately, ICANN and VeriSign will incorporate the community input regarding analysis and success criteria and make a recommendation to the NTIA for authorization to proceed with each step of the deployment. 7. Communication Plan Effective communication is imperative to the success of this effort, the transition being undertaken having a potential impact on every Internet user. As identified above, there is a large group of stakeholders directly involved in the execution of this change. Communication with the root server operators is of paramount importance, but so is that with the community at large. The staged deployment strategy being undertaken is used to allow time for the impact of these incremental steps to be communicated back to the team executing them. In order for the right decisions to be made it is vital that the appropriate channels are in place to encourage that Knight, et al. [Page 11] DNSSEC Deployment for the Root Zone January 2009 communication to happen. Announcements, releases and other pertinent information will be published at . A detailed Communications Plan is under construction by the Root DNSSEC Design Team. The e-mail address rootsign@icann.org is intended to allow any interested party to communicate with the design team. This e-mail address will be included in the bogus keys used to construct the DURZ, and will be publicized as part of the Communications Plan, technical outreach and on the project web page. 8. References [CAIDA] Wessels, D. and M. Fomenkov, "Wow, That's a Lot of Packets", April 2003, . [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. Authors' Addresses Dave Knight ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US Email: dave.knight@icann.org Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US Email: joe.abley@icann.org Knight, et al. [Page 12] DNSSEC Deployment for the Root Zone January 2009 Matt Larson VeriSign Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA Email: matt.larson@verisign.com Knight, et al. [Page 13]