JPRS

Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku Tokyo 101-0065 Japan +81 3 5215 8451 yoshiro.yoneya@jprs.co.jp

.SE

Box 7399 Stockholm Stockholm 103 91 Sweden +46 733 173956 pawal@iis.se

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.

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 and a validation procedure of registered DS , 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.

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?

This section lists several countermeasures for KSK rollover failures.

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. No need to consider TTL of DNS records. It is an impossible task to communicate with all the resolver operators.

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. Modification to correct NS and/or DS will be reflected to full resolvers in short duration. Increases queries to parent zone and therefore consumes network bandwidth and disk space of servers when logging.

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. Modification to correct DS will be reflected to full resolvers in short duration. Increases queries to parent zone and therefore consumes network bandwidth and disk space of servers when logging.

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. Modification to correct NS and/or DS will be reflected in short duration. Registration system (or zone generation system) of parent zone will be complicated.

Do nothing because registration of wrong DS is responsibility of registrant. No changes to current system/procedure. 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.

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.

This document does not specify any IANA actions.

TBD.

New co-author joined. Some editorial collections and cleanup texts. Add section 2 to show examples of KSK rollover failures.