Network Working Group Y. Yoneya Internet-Draft JPRS Intended status: Informational P. Wallstrom Expires: March 9, 2013 .SE September 5, 2012 DNSSEC KSK rollover failure recovery practices draft-yoneya-dnssec-kskro-failure-recovery-01 Abstract This document describes a set of common problems and possible recovery methods for DNSSEC when there is a DS published in the parent zone which does no longer match any DNSKEY in the child zone. As DNSSEC validators are becoming widely deployed, this will have serious effect on the availability of the zone, and the need for a quick recovery is needed. 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 March 9, 2013. Copyright Notice Copyright (c) 2012 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 Yoneya & Wallstrom Expires March 9, 2013 [Page 1] Internet-Draft DNSSEC practices September 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Yoneya & Wallstrom Expires March 9, 2013 [Page 2] Internet-Draft DNSSEC practices September 2012 1. Introduction When a zone is signed and a DS has been published in the parent zone DNS name resolution will fail when DS in the parent zone and the DNSKEY in child zone become inconsistent. The impact of a DS mismatch will be much more severe when it occurs high up in the DNS hierarchy, such as for a TLD where it could make millions of child zones unresolvable. IANA have a defined process for registering DS records for a TLD to the root zone [IANAPROC] and a validation procedure of registered DS [ROOTDNSSEC], but there will still be a non-zero risk of human error. Having a set of best practices for emergency countermeasures in the case of a KSK rollover failure will be helpful for a stable DNSSEC operation. Yoneya & Wallstrom Expires March 9, 2013 [Page 3] Internet-Draft DNSSEC practices September 2012 2. Examples of KSK rollover failures A DNS operator can cause the chain of trust between the parent and child to break in some different ways. These are just some examples: The key storage for the main DNSSEC signer is broken (or even the whole machine). The DNS operator in this case will have to restore the keys and the DNSSEC signer process to a normal state, and this can take some time - and in some cases it can be impossible to restore the system and the keys. The KSK rollover process misbehaves causing the zone to be signed with keys not matched by any DS record published in the parent zone. TODO: more examples? Yoneya & Wallstrom Expires March 9, 2013 [Page 4] Internet-Draft DNSSEC practices September 2012 3. Countermeasures for KSK rollover failures This section lists several countermeasures for KSK rollover failures. 3.1. Case 1 - remove failing DS Countermeasure: Ask the parent zone administrator to delete the DS records from the parent zone or to replace the wrong DS records with the correct set of DS. For a quick recovery there is also a need to ask every major DNSSEC validating resolver operator to flush the cache for the failing zone. Pros: No need to consider TTL of DNS records. Cons: It is an impossible task to communicate with all the resolver operators. 3.2. Case 2 Countermeasure: Specify short time for TTLs of DS and NS records in parent zone to make reflection duration shorter for modification (deletion of wrong DS or replace wrong DS with correct DS) to correspond registration of wrong DS. Pros: Modification to correct NS and/or DS will be reflected to full resolvers in short duration. Cons: Increases queries to parent zone and therefore consumes network bandwidth and disk space of servers when logging. 3.3. Case 3 Yoneya & Wallstrom Expires March 9, 2013 [Page 5] Internet-Draft DNSSEC practices September 2012 Countermeasure: Specify short time for TTL of DS record in parent zone to make reflection duration shorter for modification (deletion of wrong DS or replace wrong DS with correct DS) to correspond registration of wrong DS. Pros: Modification to correct DS will be reflected to full resolvers in short duration. Cons: Increases queries to parent zone and therefore consumes network bandwidth and disk space of servers when logging. 3.4. Case 4 Countermeasure: Specify short time for TTL of newly registered/modified NS and/or DS in parent zone to make reflection duration shorter for modification (deletion of wrong DS or replace wrong DS with correct DS) to correspond registration of wrong DS. After a certain duration passed, TTL of NS and/or DS be made longer time. Pros: Modification to correct NS and/or DS will be reflected in short duration. Cons: Registration system (or zone generation system) of parent zone will be complicated. 3.5. Case 5 Countermeasure: Do nothing because registration of wrong DS is responsibility of registrant. Pros: Yoneya & Wallstrom Expires March 9, 2013 [Page 6] Internet-Draft DNSSEC practices September 2012 No changes to current system/procedure. Cons: If TTLs of NS and DS in parent zone are long time, it will take a time until extinguish of influence since correction of error. Yoneya & Wallstrom Expires March 9, 2013 [Page 7] Internet-Draft DNSSEC practices September 2012 4. Considerations Followings are (not comprehensive) list of points to consider which case is the best practice for quick recovery from DS registration failure. o TTLs of NS and DS in parent zone should be the same or not. o What are the impacts of combination of long NS TTL (~1day) and short DS TTL (~a few hours). o What is the appropriate DS TTL. o How wide range of ISPs should TLDs know point of contacts (PoC) for emergency call. For example, ccTLDs should know PoC of domestic major ISPs. Yoneya & Wallstrom Expires March 9, 2013 [Page 8] Internet-Draft DNSSEC practices September 2012 5. IANA Considerations This document does not specify any IANA actions. Yoneya & Wallstrom Expires March 9, 2013 [Page 9] Internet-Draft DNSSEC practices September 2012 6. Security Considerations TBD. Yoneya & Wallstrom Expires March 9, 2013 [Page 10] Internet-Draft DNSSEC practices September 2012 7. References [IANAPROC] IANA, "Placing TLD delegation signer information in the root zone", http://www.iana.org/procedures/root-dnssec-records.html, 2010. [ROOTDNSSEC] Root DNSSEC, "Enhancements to DNSSEC validation for the DNS Root Zone change requests", http://www.root-dnssec.org/2011/01/27/rrsig-checking/, 2011. Yoneya & Wallstrom Expires March 9, 2013 [Page 11] Internet-Draft DNSSEC practices September 2012 Appendix A. Change Log A.1. Changes since -00 o New co-author joined. o Some editorial collections and cleanup texts. o Add section 2 to show examples of KSK rollover failures. Yoneya & Wallstrom Expires March 9, 2013 [Page 12] Internet-Draft DNSSEC practices September 2012 Authors' Addresses Yoshiro Yoneya JPRS Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: yoshiro.yoneya@jprs.co.jp Patrik Wallstrom .SE Box 7399 Stockholm, Stockholm 103 91 Sweden Phone: +46 733 173956 Email: pawal@iis.se Yoneya & Wallstrom Expires March 9, 2013 [Page 13]