Root DNSSEC Design Team J. Abley D. Knight ICANN M. Larson VeriSign June 7, 2010 DNSSEC Test Plan for the Root Zone (Draft) Abstract This document describes the test plan for the deployment of DNSSEC in the root zone of the DNS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Roles and Responsibilities . . . . . . . . . . . . . . . . . . 3 3. Test Subjects . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Success and Failure Criteria . . . . . . . . . . . . . . . . . 3 5. Pre-Deployment Testing . . . . . . . . . . . . . . . . . . . . 4 5.1. Root Server Incoherence . . . . . . . . . . . . . . . . . 4 5.2. Deliberately-Unvalidatable Root Zone (DURZ) . . . . . . . 4 5.2.1. Generation of DURZ . . . . . . . . . . . . . . . . . . 4 5.2.2. Distribution of DURZ . . . . . . . . . . . . . . . . . 4 5.2.3. Serving the DURZ . . . . . . . . . . . . . . . . . . . 4 5.2.4. Rollback to unsigned from the DURZ . . . . . . . . . . 5 5.2.5. Resolver Behaviour . . . . . . . . . . . . . . . . . . 5 5.3. Measurement Systems . . . . . . . . . . . . . . . . . . . 5 5.3.1. Long-Term Priming Query Collection . . . . . . . . . . 5 5.3.2. Tactical Full Request Capture . . . . . . . . . . . . 6 6. Key Management Testing . . . . . . . . . . . . . . . . . . . . 6 6.1. KSR Exchange . . . . . . . . . . . . . . . . . . . . . . . 6 6.1.1. Transmission of KSR . . . . . . . . . . . . . . . . . 6 6.1.2. Transmission of SKR . . . . . . . . . . . . . . . . . 6 6.1.3. Authorisation of SKR by US DoC NTIA . . . . . . . . . 7 6.2. ZSK Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. KSK Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 6.4. KSK Disaster Recovery . . . . . . . . . . . . . . . . . . 7 6.4.1. Failure of one HSM . . . . . . . . . . . . . . . . . . 7 6.4.2. Failure of both HSMs at one location . . . . . . . . . 8 6.4.3. Loss of all HSMs at both locations . . . . . . . . . . 8 6.5. Key Ceremonies . . . . . . . . . . . . . . . . . . . . . . 8 6.5.1. Key Management Ceremonies Prologue . . . . . . . . . . 8 6.5.2. HSM Initialisation . . . . . . . . . . . . . . . . . . 9 6.5.3. HSM Decommission . . . . . . . . . . . . . . . . . . . 9 Abley, et al. [Page 1] DNSSEC Test Plan for the Root Zone (Draft) June 2010 6.5.4. Key Generation . . . . . . . . . . . . . . . . . . . . 9 6.5.5. Key Signing / KSR Processing . . . . . . . . . . . . . 9 6.5.6. Private Key Deletion . . . . . . . . . . . . . . . . . 10 6.5.7. Key Management Ceremonies Epilogue . . . . . . . . . . 10 6.5.8. Safe Security Controller Enrolment . . . . . . . . . . 10 6.5.9. Safe Security Controller Replacement . . . . . . . . . 10 6.5.10. Crypto Officer Enrollment . . . . . . . . . . . . . . 10 6.5.11. Equipment Acceptance . . . . . . . . . . . . . . . . . 11 6.6. Trust Anchor Publication . . . . . . . . . . . . . . . . . 11 7. Provisioning Testing . . . . . . . . . . . . . . . . . . . . . 11 7.1. Receipt and Validation of DS RDATA by ICANN . . . . . . . 11 7.2. TLD DS Change Request Workflow . . . . . . . . . . . . . . 12 7.3. Generation of Signed Root Zone . . . . . . . . . . . . . . 12 7.4. Distribution of Signed Root Zone . . . . . . . . . . . . . 12 7.5. Rollback to Unsigned from Production Signed Zone . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Abley, et al. [Page 2] DNSSEC Test Plan for the Root Zone (Draft) June 2010 1. Introduction This document describes the test plan for the deployment of DNSSEC in the root zone of the DNS. Details of the deployment itself can be found in [DEPLOY]. 2. Roles and Responsibilities The respective roles of ICANN, US DoC NTIA and VeriSign in the deployment of DNSSEC in the root zone are described in [NTIAREQ]. Decisions about success or failure will be made collectively by ICANN, US DoC NTIA and VeriSign, as described in [DEPLOY]. 3. Test Subjects Many tests described in this document involve the use of DNS software in experiments intended to model the live root server system. While it is not practical to enumerate an exhaustive list of DNS software in use on the Internet, efforts will be made to test a wide variety of software that is believed to be in common use. Authority-only servers that will be tested will include the particular software in use by Root Server operators at the time of the deployment. Resolvers that will be tested will include Nominum CNS, ISC BIND4, ISC BIND8, ISC BIND9, NLNet Labs Unbound and Microsoft Windows DNS. Where resolvers are capable of requesting and validating secure answers they will be tested with validation disabled and also with validation enabled. 4. Success and Failure Criteria In the context of this document, failure denotes a finding which should cause the deployment to stop, pending further investigation of the test results. The deployment plan might subsequently be modified, or further testing may be performed to clarify the situation. Success denotes an expected result, consistent with the goals of the deployment plan. Abley, et al. [Page 3] DNSSEC Test Plan for the Root Zone (Draft) June 2010 5. Pre-Deployment Testing 5.1. Root Server Incoherence Test the behaviour of resolvers when presented with a set of root servers, some but not all of which provide secure answers in response to queries with DO=1, and some but not all of which are configured to give no responses at all. Success: resolvers exhibit no instability when presented with root zone incoherence; resolvers make use of multiple root servers and retry using a different server in the event that a queried root server provides no response. Responses are consistent from all root servers which provide them, ignoring DNSSEC information. Failure: any one of the success criteria is not met. 5.2. Deliberately-Unvalidatable Root Zone (DURZ) 5.2.1. Generation of DURZ Test the systems responsible for the generation of the DURZ. Success: the DURZ is produced with the same frequency and at the same times as the unsigned root zone; the contents of the DURZ, with RRSIG, DS, DNSKEY and NSEC records removed, are identical to the contents of the unsigned root zone; no trust anchor capable of validating signatures in the zone can be derived from any DNSKEY RRSet in the zone; the zone is internally consistent and the NSEC chain is complete. Failure: any one of the success criteria is not met. 5.2.2. Distribution of DURZ Test the systems responsible for the distribution of the DURZ. Success: all root server operators are able to perform zone transfers of the DURZ and have no operational concerns with their ability to do so over an extended period. Failure: any one of the success criteria is not met. 5.2.3. Serving the DURZ Individual root server operators should confirm that they are able to load and serve the DURZ in place of the unsigned root zone prior to their transition to serve a DURZ. Abley, et al. [Page 4] DNSSEC Test Plan for the Root Zone (Draft) June 2010 Success: individual root server operators are able to distribute a DURZ internally in place of an unsigned root zone and make it available on nameservers. Failure: any one of the success criteria is not met. 5.2.4. Rollback to unsigned from the DURZ Test the system responsible for the distribution of the root zone to the root servers. Confirm that the system is capable of distributing an unsigned root zone, stripped of all DNSSEC information, to root servers. Success: The root zone distribution system is capable of serving an unsigned root zone to the root servers. The root zone SOA serial can be increased in order to trigger the timely distribution of a new version of the root zone. Failure: any one of the success criteria is not met. 5.2.5. Resolver Behaviour Test resolver behaviour when supplied with responses from a DURZ rather than an unsigned root zone. Success: resolvers exhibit no instability when presented with responses with a DURZ; resolvers demonstrate an ability to follow referrals and otherwise process responses from a DURZ in precisely the same way as responses from an unsigned root zone are processed. Failure: any one of the success criteria is not met. 5.3. Measurement Systems 5.3.1. Long-Term Priming Query Collection Test software tools which perform a long-term, continuous capture of priming queries received at a root server and upload the results to a central collection facility for analysis. Success: queries are captured and uploaded as intended; performance impact on individual systems due to the packet capture does not present undue load to the systems, as determined by their operators. Failure: any one of the success criteria is not met. Abley, et al. [Page 5] DNSSEC Test Plan for the Root Zone (Draft) June 2010 5.3.2. Tactical Full Request Capture Test software tools which perform a short-term, tactical capture of all queries received at a root server and upload the results to a central collection facility for analysis. Success: queries are captured and uploaded as intended; performance impact on individual systems due to the packet capture does not present undue load to the systems, as determined by their operators; upload of the captured request data is feasible for a 50-hour continuous capture and does not present undue load to networks, as determined by their operators. Failure: any one of the success criteria is not met. 6. Key Management Testing 6.1. KSR Exchange 6.1.1. Transmission of KSR Test the systems and procedure responsible for the transmission and corresponding receipt of a KSR. Success: Systems at VeriSign transmit a well-formed KSR to ICANN; systems at ICANN are able to receive the KSR, returning success status to the transmitting system and making the KSR available to ICANN in a form suitable for use in a key ceremony; systems at ICANN reject an invalid KSR, returning failure status to the transmitting system. Failure: any one of the success criteria is not met. 6.1.2. Transmission of SKR Test the systems and procedure responsible for the transmission and corresponding receipt of an SKR. Success: Systems at VeriSign accept a valid SKR, returning success status to the transmitting system and making the SKR available to VeriSign in a form suitable for use in zone-signing systems; systems at VeriSign reject an invalid SKR, returning failure status to the transmitting system. Failure: any one of the success criteria is not met. Abley, et al. [Page 6] DNSSEC Test Plan for the Root Zone (Draft) June 2010 6.1.3. Authorisation of SKR by US DoC NTIA Test the systems and procedure involved in the authorisation of an SKR by US DoC NTIA. Success: US DoC NTIA operators are able to connect to and authenticate with the VeriSign system; US DoC NTIA operators are able to view and authorise an SKR. Failure: any one of the success criteria are not met. 6.2. ZSK Rollover Test the systems and procedures responsible for the execution of a ZSK rollover. Success: The KSR process produces an SKR specifying a ZSK rollover, scheduled according to the policy specified in [KEYMGMT]; root zone signing systems faithfully implement the policy specified in the SKR. Failure: any one of the success criteria are not met. 6.3. KSK Rollover Test the systems and procedures involved in the execution of a KSK rollover. Success: The KSR process produces an SKR specifying a KSK rollover, scheduled according to the policy described in [KEYMGMT]; root zone signing systems faithfully implement the policy specified in the SKR. Failure: any one of the success criteria are not met. 6.4. KSK Disaster Recovery Test the procedures responsible for recovery from the loss of one or more HSMs containing KSK material. There are two separate locations, each containing two such HSMs. 6.4.1. Failure of one HSM Test the procedure for recovery from the scenario where one HSM has failed, but the security of the key materials has not been compromised. One failed HSM can be recovered by the COs for that location performing a Storage Master Key (SMK) extraction from the functioning HSM and importing that into a replacement HSM. Success: The COs for the location are able to clone the functioning Abley, et al. [Page 7] DNSSEC Test Plan for the Root Zone (Draft) June 2010 HSM onto a replacement HSM; the newly-created cloned HSMs are verified to contain the appropriate key materials. Failure: any one of the success criteria are not met. 6.4.2. Failure of both HSMs at one location Test the procedure for recovery from the scenario where both HSMs at one location have failed, but the security of the key materials have not been compromised. Failure of both HSMs at one location can be recovered from by the COs for the other location performing an SMK extraction from a functioning HSM and the COs at the failed location importing that onto replacement HSMs. Success: the COs at the site with functioning HSMs create a clone of a functioning HSM which is restored onto replacement HSMs by the COs at the location with failed HSMs; the newly-created cloned HSMs are verified to contain the appropriate key materials. Failure: any one of the success criteria are not met. 6.4.3. Loss of all HSMs at both locations Test the procedures responsible for recovery from the loss of all HSMs at both locations. Failure of all HSMs can be recovered from by using 5 out of the 7 recovery key shares to restore the StoraSMK onto replacement HSMs and using the application key backups stored at each location to restore the KSK. Success: At least 5 out of the 7 recovery key shares are brought to a location and used to restore the SMK onto a replacement HSM; the application key backup is used to restore a backup of the KSK onto the replacement HSM; the replacement HSM is confirmed to contain the appropriate key materials. Failure: any one of the success criteria are not met. 6.5. Key Ceremonies Test the procedures to be followed by the Root Zone Key Signing Key Operator in the execution of ceremonies as described in [CEREMONY] 6.5.1. Key Management Ceremonies Prologue Test that CO credentials and HSMs can be removed from their respective safes and placed into Tier 4 (Key Ceremony Room). Success: CO credentials and HSMs can be removed from their respective Abley, et al. [Page 8] DNSSEC Test Plan for the Root Zone (Draft) June 2010 safes and placed into Tier 4 (Key Ceremony Room). Failure: any one of the success criteria were not met. 6.5.2. HSM Initialisation Test that an HSM can be initialised for use. Success: HSM hardware integrity is verified by checking the serial number of the tamper evident bag in which the device was stored and the serial number of the device itself; the HSM issues CO credentials and these are distributed to their respective COs; followed by connecting the HSM to a laptop and running initialization software; if the HSM being initialized is not the first of a set, the SMK can be assembled and restored from the SMK cards made at the initialization of the first HSM. Failure: any one of the success criteria were not met. 6.5.3. HSM Decommission Test that an HSM can be securely decommissioned. Success: the HSM can be zero-ized and tampered. Failure: any one of the success criteria were not met. 6.5.4. Key Generation Test that a key generated at an HSM is faithfully copied to the other three HSMs. Success: New keys are present on all 4 HSMs and the hash of the key generated by each HSM it was copied to matches that produced by the HSM upon which it was created. Failure: any one of the success criteria were not met. 6.5.5. Key Signing / KSR Processing Test the procedure and tools for processing a Key Signing Request. Success: The KSR validates; the integrity of the KSR is verified by manual verification of a hash of its content with the ZSK operator; the produced SKR is accepted for use by the ZSK operator. Failure: any one of the success criteria were not met. Abley, et al. [Page 9] DNSSEC Test Plan for the Root Zone (Draft) June 2010 6.5.6. Private Key Deletion Test that a private key can be deleted from all HSMs. Success: The deleted private key no longer appears in an inventory of keys on any of the four HSMs. Failure: any one of the success criteria were not met. 6.5.7. Key Management Ceremonies Epilogue Test that CO credentials and HSMs can be returned to their respective safes from Tier 4 (Key Ceremony Room). Success: CO credentials and HSMs are returned to their respective safes from Tier 4 (Key Ceremony Room). Failure: any one of the success criteria were not met. 6.5.8. Safe Security Controller Enrolment Test that a Safe Security Controller can be enrolled. Success: A new combination can be set and this can be used to unlock the safe. Failure: any one of the success criteria were not met. 6.5.9. Safe Security Controller Replacement Test that a Safe Security Controller can be replaced. Success: An old combination can be removed and a new one set; the old combination can no longer be used to unlock the safe; the new combincation can be used to unlock the safe. Failure: any one of the success criteria were not met. 6.5.10. Crypto Officer Enrollment Test that the safety deposit box keys issued to a CO can be used to open a safety deposit box in combination with the CA common key. Success: Each CO key, used in combination with the CA common key, can be used to open a safety deposit box; other combinations of similar keys not intended for use with the specific safety deposit box being tested cannot be used to open the box. Abley, et al. [Page 10] DNSSEC Test Plan for the Root Zone (Draft) June 2010 Failure: any one of the success criteria were not met. 6.5.11. Equipment Acceptance Test new HSMs according to the ICANN DNSSEC AEP Keyper v2.0 Acceptance Script. Success: Chain of custody is verified and the tests described in the script are completed successfully. Failure: Any one of the success criteria is not met. 6.6. Trust Anchor Publication Test the system responsible for the production of the trust anchor. Success: The trust anchor is produced in two formats: an XML document containing a hash of the KSK DNSKEY in DS RR format and a Certificate Signing Request in PKCS#10 format; both representations of the trust anchor can be used for validation of a zone signed using the corresponding KSK; trust anchor documents are signed using OpenPGP keys which themselves carry signatures from the personal OpenPGP keys of ICANN operations staff; it is possible to verify a chain of trust from one of those personal OpenPGP keys to the OpenPGP key used to sign the trust anchor; trust anchor documents are also signed using S/MIME in such a way that the signature can be verified using a trust anchor derived from ICANN's CA. Finally, the CSR is signed by ICANN's CA (and other parties interested in attesting to its authenticity) to create an X.509 certificate. Failure: any one of the success criteria is not met. 7. Provisioning Testing 7.1. Receipt and Validation of DS RDATA by ICANN Test the tools and procedures used by the ICANN to verify DS RRsets submitted by TLD operators for inclusion in the root zone. Success: The tools confirm the validity of DS RRs which match a hash made of DNSKEYs retrieved from the active TLD zone and correctly identify those which do not match as invalid. Failure: any one of the success criteria is not met. Abley, et al. [Page 11] DNSSEC Test Plan for the Root Zone (Draft) June 2010 7.2. TLD DS Change Request Workflow Test the tools and procedures involved in the transmission of a root zone change request. Success: changes in DS RRSets can be sent from ICANN to NTIA for authorisation in the usual format and following the usual procedures used for processing other root zone changes; NTIA is able to authorise the changes; VeriSign is able to implement the changes. Failure: Any one of the success criteria is not met. 7.3. Generation of Signed Root Zone Test the systems involved in producing a signed root zone. Success: DNSSEC signatures over signed RRsets in the root zone are appropriately signed; the process of signing does not introduce any unnecessary modifications to the zone content; the signed root zone, when stripped of all DNSSEC RRsets is identical to an unsigned root zone generated by VeriSign. Failure: any one of the success criteria is not met. 7.4. Distribution of Signed Root Zone Test the distribution mechanism for the signed root zone. Success: All root servers operators report that they are able to transfer the signed root zone from the designated master servers using TSIG-authenticated AXFR. Failure: any one of the success criteria is not met. 7.5. Rollback to Unsigned from Production Signed Zone Test the systems and procedures for rollback from the production signed root zone to the unsigned root zone as described in [DEPLOY]. Success: a valid KSR can be processed such that the resulting SKR contains a single active KSK with the REVOKE bit set; the resulting SKR is well-formed and valid; zone-signing systems at VeriSign can incorporate the data contained within the SKR in the root zone to effect an unsigning consistent with [RFC5011]. Failure: any one of the success criteria is not met. Abley, et al. [Page 12] DNSSEC Test Plan for the Root Zone (Draft) June 2010 8. References [CEREMONY] Schlyter, J., Ljunggren, F., and R. Lamb, "Root Zone DNSSEC KSK Ceremonies Guide", May 2010. [DEPLOY] Abley, J., Knight, D., and M. Larson, "DNSSEC Deployment for the Root Zone (Draft)", May 2010. [KEYMGMT] Schlyter, J., Lamb, R., and R. Balasubramanian, "DNSSEC Key Management Implementation for the Root Zone (DRAFT)", May 2010. [NTIAREQ] NTIA, "Testing and Implementation Requirements for the Initial Deployment of DNSSEC in the Authoritative Root Zone", June 2009. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. 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 Test Plan for the Root Zone (Draft) June 2010 Matt Larson VeriSign Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA Email: matt.larson@verisign.com Abley, et al. [Page 14]