Change of Operator Procedures for Automatically Published DNSSEC Zones
draft-pounsett-transferring-automated-dnssec-zones-02

Abstract

Section 4.3.5.1 of [RFC6781] "DNSSEC Operational Practices, version 2" describes a procedure for transitioning a DNSSEC signed zone from one (cooperative) operator to another. The procedure works well in many situations, but makes the assumption that it is feasible for the two operators to simultaneously publish slightly different versions of the zone being transferred. In some cases, such as with TLD registries, operational considerations require both operators to publish identical versions of the zone for the duration of the transition. This document describes a modified transition procedure which can be used in these cases.

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 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

The process described in "DNSSEC Operational Practices, version 2" ([RFC6781]), section 4.3.5.1 for cooperating DNS operators to move a DNSSEC signed zone cannot be followed in all cases. When operators are moving a zone that is automatically published and/or changes rapidly, such as with a TLD or any other zone published from a registration database, it may not be feasible for the operators to publish different versions of the same zone.

In these cases, it would be necessary for one or both operators to have the capability to add, remove, or alter arbitrary records inline along the zone transfer path (such as modifying the NSSet, and stripping RRSIGs). It cannot be assumed that this capability exists, since few (if any) common DNS implementations include these functions, and many custom implementations exist whose feature sets cannot be predicted.

As a result, it must be assumed that operators moving an automatically generated or frequently updated zone must be able to publish an identical zone while transitioning it from one operator to another.

2. Changing Between Cooperating DNS Operators

2.1. Assumptions

In this scenario, it is assumed that the operators will not exchange any private key material, but are otherwise fully cooperative. It is also assumed that the zone publishing process will be transferred between operators independently of the DNS operations. The simplest case is to transition the publishing process after the DNS operations move has been completed, and is the order that is assumed in this document, although the reverse order is possible. During the transition, the losing operator will provide the zone contents to the gaining operator by some automatic means (typically zone transfer). The transition of the publishing process is out of scope of this document.

2.2. Procedure Overview

The DNS operations transition uses a modified pre-publish KSK and ZSK rollover, whereby the losing operator pre-publishes the public KSK and ZSK of the gaining operator. Part way through the transition, the losing operator stops signing the zone and begins providing an unsecure zone to the gaining operator, who begins signing. Once that is done, the gaining operator continues to post-publish the public keys of the losing operator until the TTLs of the original RRSIGs expire.

2.3. Procedure Notation

In the timeline below, the losing operator is operator A, and the gaining operator is operator B. Records representing data generated by each operator are appended with the operator letter. DNSKEY records are appended with the keytype; DNSKEY_Z is a ZSK, and DNSKEY_K is a KSK. RRSIGs are appended with the DNSKEY type they were generated from, as well as the operator who generated them; RRSIGs include in parentheses the RRSET type that they sign. For example, RRSIG_Z_A(SOA) is the RRSIG generated with DNSKEY_Z_A and signs the SOA record.

2.4. The Procedure

The KSK and ZSK rollover from the losing to gaining operator keys involves six stages as described in Figure 1 and Figure 2.

----------------------------------------------------------------
| initial            | pre-publish        | re-delegation      |
----------------------------------------------------------------
| Parent:            | Parent:            | Parent:            |
|  NS_A              |  NS_A              |                    |
|                    |                    |  NS_B              |
|  DS_A              |  DS_A              |  DS_A              |
|                    |                    |  DS_B              |
----------------------------------------------------------------
| Child:             | Child:             | Child:             |
| Published by A     | Published by A     | Published by A     |
| Signed by A        | Signed by A        | Signed by A        |
|  SOA_A0            |  SOA_A1            |  SOA_A1            |
|  RRSIG_Z_A(SOA)    |  RRSIG_Z_A(SOA)    |  RRSIG_Z_A(SOA)    |
|                    |                    |                    |
|  NS_A              |                    |                    |
|                    |  NS_B              |  NS_B              |
|  RRSIG_Z_A(NS)     |  RRSIG_Z_A(NS)     |  RRSIG_Z_A(NS)     |
|                    |                    |                    |
|  DNSKEY_Z_A        |  DNSKEY_Z_A        |  DNSKEY_Z_A        |
|                    |  DNSKEY_Z_B        |  DNSKEY_Z_B        |
|  DNSKEY_K_A        |  DNSKEY_K_A        |  DNSKEY_K_A        |
|                    |  DNSKEY_K_B        |  DNSKEY_K_B        |
|  RRSIG_K_A(DNSKEY) |  RRSIG_K_A(DNSKEY) |  RRSIG_K_A(DNSKEY) |
----------------------------------------------------------------

Figure 1: Rollover for Cooperating Operators, Steps 1-3

Signing Migration: Once the new (pre-published) DNSKEY records and DS_B are in the caches of validating clients the operators can swap signing duties; RRSIG_K_B and RRSIG_Z_B become the active signing keys. When the ganinig operator begins signing the zone, either they MUST strip the RRSIGs of the losing operator, or the losing operator MUST begin producing an unsigned zone. The operators MUST wait at least the largest TTL of any RRSIG in the zone before moving on to the Old DS Removal step.
Old DS Removal: The parent now removes the old DS_A from its zone. The operators MUST wait at least the TTL of the DS set before moving on to the Post Migration step.
Post Migration: After the old DS set has expired from caches the gaining operator may remove the losing operator DNSKEYs from the zone. At this time it is assumed that the gaining operator severs whatever process was transferring zone data from the losing operator, and the gaining operator begins publishing the zone.

----------------------------------------------------------------
| signing migration  | old DS removal     | post migration     |
----------------------------------------------------------------
|  Parent:           | Parent:            | Parent:            |
|                    |                    |                    |
|   NS_B             |  NS_B              |  NS_B              |
|   DS_A             |                    |                    |
|   DS_B             |  DS_B              |  DS_B              |
----------------------------------------------------------------
| Child:             | Child:             | Child:             |
| Published by A     | Published by A     | Published by B     |
| Signed by B        | Signed by B        | Signed by B        |
|  SOA_A2            |  SOA_A2            |  SOA_B0            |
|  RRSIG_Z_B(SOA)    |  RRSIG_Z_B(SOA)    |  RRSIG_Z_B(SOA)    |
|                    |                    |                    |
|                    |                    |                    |
|  NS_B              |  NS_B              |  NS_B              |
|  RRSIG_Z_B(NS)     |  RRSIG_Z_B(NS)     |  RRSIG_Z_B(NS)     |
|                    |                    |                    |
|  DNSKEY_Z_A        |  DNSKEY_Z_A        |                    |
|  DNSKEY_Z_B        |  DNSKEY_Z_B        |  DNSKEY_Z_B        |
|  DNSKEY_K_A        |  DNSKEY_K_A        |                    |
|  DNSKEY_K_B        |  DNSKEY_K_B        |  DNSKEY_K_B        |
|  RRSIG_K_B(DNSKEY) |  RRSIG_K_B(DNSKEY) |  RRSIG_K_B(DNSKEY) |
----------------------------------------------------------------

Figure 2: Rollover for Cooperating Operators, Steps 4-6

3. Security Considerations

This document raises no new security considerations. Please see Section 6 of [RFC6781].

4. IANA Considerations

This document has no actions for IANA.

5. Normative References

[RFC6781]

Kolkman, O., Mekking, W. and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012.

Appendix A. Document Source

[RFC Editor: Please remove this section before publication.]

This document is maintained at Github at <https://github.com/mpounsett/operator-transfer>. Issue reports and pull requests are gratefully accepted here.

The XML and TXT versions of this document are generated from Markdown using mmark by Miek Gieben. mmark is available at <https://github.com/miekg/mmark>.