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 01, 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.

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.

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.

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.

3. Considerations

Followings are (not comprehensive) list of points to consider which case is the best practice for quick recovery from DS registration failure.

• TTLs of NS and DS in parent zone should be the same or not.
• What are the impacts of combination of long NS TTL (~1day) and short DS TTL (~a few hours).
• What is the appropriate DS TTL.
• 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.

4. IANA Considerations

This document does not specify any IANA actions.

5. Security Considerations

TBD.

6. References

Author's Address

Table of Contents

• 1. Introduction
• 2. Cases of countermeasure for KSK rollover failure
• 2.1. Case 1
• 2.2. Case 2
• 2.3. Case 3
• 2.4. Case 4
• 2.5. Case 5
• 3. Considerations
• 4. IANA Considerations
• 5. Security Considerations
• 6. References
• Author's Address