[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03

Network Working Group                                        M. Pounsett
Internet-Draft                                     Rightside Group, Ltd.
Updates: 6781 (if approved)                           September 13, 2017
Intended status: Informational
Expires: March 17, 2018


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

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.

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 https://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 17, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (https://trustee.ietf.org/license-info) in effect on the date of



Pounsett                 Expires March 17, 2018                 [Page 1]


Internet-Draft   Change of Operator for Automated Zones   September 2017


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Changing Between Cooperating DNS Operators  . . . . . . . . .   3
     3.1.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Procedure Overview  . . . . . . . . . . . . . . . . . . .   3
     3.3.  Procedure Notation  . . . . . . . . . . . . . . . . . . .   3
     3.4.  The Procedure . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Document Source  . . . . . . . . . . . . . . . . . .   7
   Appendix B.  Changelist . . . . . . . . . . . . . . . . . . . . .   7
     B.1.  Version pounsett-03 . . . . . . . . . . . . . . . . . . .   7
     B.2.  Version pounsett-02 . . . . . . . . . . . . . . . . . . .   7
     B.3.  Version pounsett-01 . . . . . . . . . . . . . . . . . . .   7
     B.4.  Version pounsett-00 . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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




Pounsett                 Expires March 17, 2018                 [Page 2]


Internet-Draft   Change of Operator for Automated Zones   September 2017


   publish an identical zone while transitioning it from one operator to
   another.

2.  Applicability

   This document is intended for operators intending to transfer
   operational responsibility for DNSSEC-signed zones, while publishing
   consistent zone data on both sets of name servers throughout the
   transition.

   Other procedures exist for operators who are unable to consistently
   replicate data between both sets of name servers (e.g. through zone
   transfer) or who do not require this level of zone consistency during
   the transfer.

3.  Changing Between Cooperating DNS Operators

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

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

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



Pounsett                 Expires March 17, 2018                 [Page 3]


Internet-Draft   Change of Operator for Automated Zones   September 2017


   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.

3.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
      The initial version of the zone.  This zone is published and
      signed by the losing operator.  During this stage the gaining
      operator should begin serving the zone on its name servers.

   Pre-Publish
      Operator A begins pre-publishing DNSKEY_K_B and DNSKEY_Z_B.  At
      the same time, the NS set at the apex of the zone is changed to
      NS_B to begin moving traffic to the gaining name servers.  The
      operators MUST wait at least the time it takes for the data to
      propagate to all authoritative servers plus the TTL of the DNSKEY
      set before the Signing Migration step can be begun.

   Re-Delegation
      The parent changes the prent NS set to be NS_B, to match the NS
      set at the apex of the child zone.  The parent also begins
      publishing the DS record for the gaining operator.  The operators
      MUST wait at least the time it takes for the data to propagate to
      all the parent servers plus the TTL of the DS set before the
      Signing Migration step can be begun.




















Pounsett                 Expires March 17, 2018                 [Page 4]


Internet-Draft   Change of Operator for Automated Zones   September 2017


     ----------------------------------------------------------------
     | 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; DNSKEY_K_B and DNSKEY_Z_B become the active signing keys.
      When the gaining 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 stops whatever




Pounsett                 Expires March 17, 2018                 [Page 5]


Internet-Draft   Change of Operator for Automated Zones   September 2017


      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

4.  Security Considerations

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

5.  IANA Considerations

   This document has no actions for IANA.

6.  Normative References

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <https://www.rfc-editor.org/info/rfc6781>.





Pounsett                 Expires March 17, 2018                 [Page 6]


Internet-Draft   Change of Operator for Automated Zones   September 2017


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

Appendix B.  Changelist

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

B.1.  Version pounsett-03

   o  grammar and spelling nits

   o  fix RRSIG/DNSKEY typo in "Signing Migration" step

B.2.  Version pounsett-02

   o  grammar and spelling nits

   o  separate procedural section into subsections

   o  improve notation explanation

   o  rename procedure steps for clarity

   o  add prose description of operator key roll

B.3.  Version pounsett-01

   o  grammar and spelling nits

   o  added Security Considerations section

   o  added IANA Considerations section

   o  added Document Source and Changelist

   o  call out publishing migration as out of scope






Pounsett                 Expires March 17, 2018                 [Page 7]


Internet-Draft   Change of Operator for Automated Zones   September 2017


B.4.  Version pounsett-00

   Initial Submission

Author's Address

   Matthew Pounsett
   Rightside Group, Ltd.
   Toronto, ON
   Canada

   Email: matt@conundrum.com







































Pounsett                 Expires March 17, 2018                 [Page 8]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/