Network Working Group Y. YONEYA Internet-Draft JPRS Intended status: Informational March 2, 2012 Expires: September 3, 2012 DNSSEC KSK rollover failure recovery practices draft-yoneya-dnssec-kskro-failure-recovery-00 Abstract This document intend to consider best practice for quick recovering from DNSSEC DS registration failure. 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 September 3, 2012. 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. YONEYA Expires September 3, 2012 [Page 1] Internet-Draft DNSSEC practices March 2012 1. Introduction In case of DNSSEC DS registration, DNS name resolution will fail when DS in parent zone and DNSKEY in child zone become inconsistent. Especially, the impact of DS registration failure of TLD will be huge because millions of domain names become unresolvable all together. IANA had defined process for registering DS for TLD to root zone [IANAPROC] and validation procedure of registered DS [ROOTDNSSEC], but there will be non zero chance of human error. Having best practice for emergency countermeasure assuming KSK rollover failure will be helpful for stable DNSSEC operation. YONEYA Expires September 3, 2012 [Page 2] Internet-Draft DNSSEC practices March 2012 2. Cases of countermeasure for KSK rollover failure This section lists several cases of countermasure for KSK rollover failure. 2.1. Case 1 Countermeasure: Ask parent zone administrator to delete wrong DS from parent zone or to replace wrong DS with correct DS, and then ask major ISPs to flush cache in full resolvers. Pros: No need to consider TTL of DNS records. Cons: Impossible to ask all major ISPs. 2.2. Case 2 Pros: 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. 2.3. Case 3 Pros: 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. YONEYA Expires September 3, 2012 [Page 3] Internet-Draft DNSSEC practices March 2012 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. 2.4. Case 4 Pros: 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. 2.5. Case 5 Pros: Do nothing because registration of wrong DS is responsibility of registrant. Pros: 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 Expires September 3, 2012 [Page 4] Internet-Draft DNSSEC practices March 2012 3. 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 Expires September 3, 2012 [Page 5] Internet-Draft DNSSEC practices March 2012 4. IANA Considerations This document does not specify any IANA actions. YONEYA Expires September 3, 2012 [Page 6] Internet-Draft DNSSEC practices March 2012 5. Security Considerations TBD. YONEYA Expires September 3, 2012 [Page 7] Internet-Draft DNSSEC practices March 2012 6. 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 Expires September 3, 2012 [Page 8] Internet-Draft DNSSEC practices March 2012 Author's Address 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 YONEYA Expires September 3, 2012 [Page 9]