Change of Operator Procedures for Automatically Published DNSSEC Zones
draft-pounsett-transferring-automated-dnssec-zones-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Matthew Pounsett | ||
| Last updated | 2016-08-02 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pounsett-transferring-automated-dnssec-zones-01
Network Working Group M. Pounsett
Internet-Draft Rightside Group, Ltd.
Updates: 6781 (if approved) August 2, 2016
Intended status: Informational
Expires: February 3, 2017
Change of Operator Procedures for Automatically Published DNSSEC Zones
draft-pounsett-transferring-automated-dnssec-zones-01
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 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 February 3, 2017.
Copyright Notice
Copyright (c) 2016 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
Pounsett Expires February 3, 2017 [Page 1]
Internet-Draft Change of Operator for Automated Zones August 2016
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. Changing Between Cooperating DNS Operators . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Document Source . . . . . . . . . . . . . . . . . . 6
Appendix B. Changelist . . . . . . . . . . . . . . . . . . . . . 6
B.1. Version pounsett-01 . . . . . . . . . . . . . . . . . . . 6
B.2. Version pounsett-00 . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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
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
Pounsett Expires February 3, 2017 [Page 2]
Internet-Draft Change of Operator for Automated Zones August 2016
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.
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. Partway 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.
In the timeline below, the losing operator is operator A, and the
gaining operator is operator B. Records representig data generated
by each operator are appended with the operator letter. DNSKEY_Z is
a ZSK, and DNSKEY_K is a KSK. RRSIG_K is the RRSIG generated with
DNSKEY_K.
Pounsett Expires February 3, 2017 [Page 3]
Internet-Draft Change of Operator for Automated Zones August 2016
----------------------------------------------------------------
| initial | pre-publish | re-delegation I |
----------------------------------------------------------------
| 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) |
----------------------------------------------------------------
Rollover for Cooperating Operators, Steps 1-3
Pounsett Expires February 3, 2017 [Page 4]
Internet-Draft Change of Operator for Automated Zones August 2016
----------------------------------------------------------------
| signing-migration | re-delegation II | 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) |
----------------------------------------------------------------
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,
<http://www.rfc-editor.org/info/rfc6781>.
Pounsett Expires February 3, 2017 [Page 5]
Internet-Draft Change of Operator for Automated Zones August 2016
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-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
B.2. Version pounsett-00
Initial Submission
Author's Address
Matthew Pounsett
Rightside Group, Ltd.
Email: matt@conundrum.com
Pounsett Expires February 3, 2017 [Page 6]