Root DNSSEC Design Team J. Abley D. Knight ICANN M. Larson VeriSign May 5, 2010 DNSSEC Deployment for the Root Zone (Draft) Abstract This document describes a plan for a controlled deployment of DNSSEC in the root zone of the DNS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Deployment Concerns . . . . . . . . . . . . . . . . . . . . . 2 2.1. Large Responses . . . . . . . . . . . . . . . . . . . . . 2 2.2. Early-Adopters and Rollback . . . . . . . . . . . . . . . 2 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Staged Deployment . . . . . . . . . . . . . . . . . . . . . . 4 4.1. The DURZ . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Testing the DURZ . . . . . . . . . . . . . . . . . . . 5 4.2. Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Preparation phase . . . . . . . . . . . . . . . . . . 5 4.2.2. Deployment Phase . . . . . . . . . . . . . . . . . . . 5 4.3. Measurement . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Ongoing Traffic Statistics . . . . . . . . . . . . . . 7 4.3.2. Event Driven Full Packet Capture . . . . . . . . . . . 7 4.3.3. Ongoing Priming Query Capture . . . . . . . . . . . . 7 5. Roles and Responsibilities . . . . . . . . . . . . . . . . . . 8 5.1. Parties Organising Signing . . . . . . . . . . . . . . . . 8 5.2. Root server operators . . . . . . . . . . . . . . . . . . 9 6. Analysis and Success Criteria . . . . . . . . . . . . . . . . 10 7. Emergency Rollback . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Rollback from DURZ . . . . . . . . . . . . . . . . . . . . 11 7.2. Rollback from Production Signed Zone . . . . . . . . . . . 12 8. Communication Plan . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Abley, et al. [Page 1] DNSSEC Deployment for the Root Zone (Draft) May 2010 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 2010-07-15, suitable for use by validators. 2. Deployment Concerns 2.1. Large Responses It is believed that 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 (source: ). After the root zone is signed, root servers will send 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 incorporating 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 Abley, et al. [Page 2] DNSSEC Deployment for the Root Zone (Draft) May 2010 manually or automatically-configured discrete trust-anchors from 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. By 2010-07-15 23:59 UTC 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. Abley, et al. [Page 3] DNSSEC Deployment for the Root Zone (Draft) May 2010 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 realising 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. Abley, et al. [Page 4] DNSSEC Deployment for the Root Zone (Draft) May 2010 . 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, since the DURZ itself is a new technology it is possible that its deployment will have unforeseen consequences for resolvers. To characterise the reaction of resolvers to the DURZ and to identify any potential harmful effects a series of tests were executed against a variety of resolver implementations. The results of these tests can be found in [draft-icann-dnssec-resolver-testing]. 4.2. Schedule 4.2.1. Preparation phase VeriSign will 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. Abley, et al. [Page 5] DNSSEC Deployment for the Root Zone (Draft) May 2010 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 0600 UTC -- 2010-03-03 0800 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. Abley, et al. [Page 6] DNSSEC Deployment for the Root Zone (Draft) May 2010 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 Abley, et al. [Page 7] DNSSEC Deployment for the Root Zone (Draft) May 2010 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 Organising 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 root zone DNSKEY RRSets, using the KSK o Sends update requests to NTIA for authorisation and a copy to VeriSign for implementation VeriSign, as Root Zone Maintainer Abley, et al. [Page 8] DNSSEC Deployment for the Root Zone (Draft) May 2010 o Manages the ZSK o Signs the root zone with the ZSK o Sends DNSKEY RRSets for signature to ICANN o Implements NTIA-authorised 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 Authorises changes to the root zone o Checks that ICANN has followed their agreed upon verification/ processing policies and procedures o Authorises signed DNSKEY RRSets signed by ICANN for inclusion in the root zone by VeriSign 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: H - U.S. Army Research Laboratory (ARL) Abley, et al. [Page 9] DNSSEC Deployment for the Root Zone (Draft) May 2010 I: Autonomica K: Reseaux IP Europeens Network Coordination Centre (RIPE NCC) L: Internet Corporation for Assigned Names and Numbers (ICANN) M: WIDE Project (WIDE) 6. Analysis and Success Criteria This effort will generate a significant amount of data to be analysed. 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. Analysis by third parties will also be possible since source data will be made generally accessible. The Root DNSSEC Design Team will adapt analysis in reaction to early observations made during the deployment, and following feedback from the technical community as early results are made public. See also Section 8. Ultimately, ICANN and VeriSign will incorporate community input regarding analysis and success criteria and make a recommendation to the NTIA for authorization to proceed with each step of the deployment. Rollback in the event that a decision is made to roll back will follow procedures outlined in Section 7. 7. Emergency Rollback Abley, et al. [Page 10] DNSSEC Deployment for the Root Zone (Draft) May 2010 7.1. Rollback from DURZ Rollback from a phase in the deployment where one or more root servers is serving the DURZ and the remainder are serving the unsigned root zone is as follows. 1. A maintenance window for the rollback event will be agreed between NTIA, ICANN and VeriSign. 2. Notice of the impending maintenance, with a technical description of the change, will be sent to the same Internet engineering communities to which technical status updates are directed (see Section 8). 3. Notice of the impending maintenance, including technical details of precisely what steps are to be taken, will be sent to root server operators, exercising emergency contact channels. ICANN and VeriSign will ensure that all root server operators have received notice of the maintenance and are prepared to facilitate its execution. 4. During the maintenance window, VeriSign will begin to serve an unsigned root zone, stripped of all DNSSEC information, from all master servers that were previously serving the DURZ to root servers. VeriSign will arrange for the root zone SOA serial to increase, in order to trigger the distribution of the unsigned zone. 5. Following the availability of the unsigned root zone, ICANN and VeriSign will coordinate with root server operators to ensure that the distribution of the unsigned zone proceeds smoothly across all root servers. 6. Once all root servers are serving the unsigned root zone, ICANN and VeriSign will advise NTIA that the maintenance is complete. 7. ICANN and VeriSign will send confirmation that the maintenance has been completed to the recipients of the earlier maintenance notice. 8. ICANN and VeriSign will prepare a detailed technical report of the circumstances leading to the rollback, and the execution of the rollback itself, and will publish the results to the technical community. Abley, et al. [Page 11] DNSSEC Deployment for the Root Zone (Draft) May 2010 7.2. Rollback from Production Signed Zone Rollback from a phase in the deployment where the root servers are serving the production signed zone is as follows. 1. Notice of the circumstances and the remedial action intended, with technical detail, will be sent to the same Internet engineering communities to which technical status updates are directed (see Section 8). 2. ICANN will execute an emergency Key Processing ceremony, attended by only ICANN staff, and will reprocess the most recently- processed KSR, this time setting the REVOKE bit on the active KSK. 3. NTIA will authorise the SKR for use. 4. VeriSign will deploy the SKR. 5. Public communication with the Internet engineering communities will continue, with the goal of ensuring that news of the situation and the actions being taken are communicated to as wide a public audience as possible. 6. Following the appropriate publication delay, as specified by [RFC5011], VeriSign will execute a transition to an unsigned root zone as described in Section 7.1. 8. Communication Plan Effective communication is critical for the success of this effort, the transition being undertaken having a potential impact on every Internet user. 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 allows 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 communication to happen. Announcements, releases and other pertinent information will be published at . Periodic technical status updates will be sent to appropriate Internet engineering mailing lists in order to keep technical and operational communities informed of developments. Abley, et al. [Page 12] DNSSEC Deployment for the Root Zone (Draft) May 2010 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 publicised as part of outreach activities and on the project web page. 9. 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. [draft-icann-dnssec-resolver-testing] Wessels and D. Knight, "Resolver Testing with a DURZ", May 2010. Authors' Addresses Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US Email: joe.abley@icann.org Dave Knight ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US Email: dave.knight@icann.org Abley, et al. [Page 13] DNSSEC Deployment for the Root Zone (Draft) May 2010 Matt Larson VeriSign Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA Email: matt.larson@verisign.com Abley, et al. [Page 14]