draft-ietf-dnsop-delegation-trust-maintainance-13.txt   draft-ietf-dnsop-delegation-trust-maintainance-14.txt 
dnsop W. Kumari dnsop W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational O. Gudmundsson Intended status: Informational O. Gudmundsson
Expires: November 04, 2014 Shinkuro Inc. Expires: December 12, 2014 Shinkuro Inc.
G. Barwood G. Barwood
May 03, 2014 June 10, 2014
Automating DNSSEC Delegation Trust Maintenance Automating DNSSEC Delegation Trust Maintenance
draft-ietf-dnsop-delegation-trust-maintainance-13 draft-ietf-dnsop-delegation-trust-maintainance-14
Abstract Abstract
This document describes a method to allow DNS operators to more This document describes a method to allow DNS operators to more
easily update DNSSEC Key Signing Keys using the DNS as communication easily update DNSSEC Key Signing Keys using the DNS as communication
channel. The technique described is aimed at delegations in which it channel. The technique described is aimed at delegations in which it
is currently hard to move information from the child to parent. is currently hard to move information from the child to parent.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 04, 2014. This Internet-Draft will expire on December 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DNS Delegations . . . . . . . . . . . . . . . . . . . . . 4 2.1. DNS Delegations . . . . . . . . . . . . . . . . . . . . . 4
2.2. Relationship Between Parent and Child DNS Operator . . . 5 2.2. Relationship Between Parent and Child DNS Operator . . . 5
2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6 2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6
2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 6 2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 6
3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions . 7 3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions . 7
3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 7 3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8
3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8 3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
4. Automating DS Maintenance With CDS / CDNSKEY records . . . . 8 4. Automating DS Maintenance With CDS / CDNSKEY records . . . . 8
4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8 4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8
5. CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . . 9 5. CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . . 9
6. Parent Side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9 6. Parent Side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9
6.1. Detecting a Changed CDS / CDNSKEY . . . . . . . . . . . . 9 6.1. Detecting a Changed CDS / CDNSKEY . . . . . . . . . . . . 9
6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10 6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10
6.1.2. Polling Triggers . . . . . . . . . . . . . . . . . . 10 6.1.2. Polling Triggers . . . . . . . . . . . . . . . . . . 10
6.2. Using the New CDS / CDNSKEY Records . . . . . . . . . . . 11 6.2. Using the New CDS / CDNSKEY Records . . . . . . . . . . . 11
6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11 6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15 Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
Appendix B. CDS key rollover example . . . . . . . . . . . . . . 16 Appendix B. CDS key rollover example . . . . . . . . . . . . . . 16
Appendix C. Changes / Author Notes. . . . . . . . . . . . . . . 17 Appendix C. Changes / Author Notes. . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The first time a DNS operator signs a zone, they need to communicate The first time a DNS operator signs a zone, they need to communicate
the keying material to their parent through some out-of-band method the keying material to their parent through some out-of-band method
to complete the chain of trust. Depending on the desires of the to complete the chain of trust. Depending on the desires of the
skipping to change at page 3, line 21 skipping to change at page 3, line 21
DNSSEC provides data integrity to information published in DNS; thus DNSSEC provides data integrity to information published in DNS; thus
DNS publication can be used to automate maintenance of delegation DNS publication can be used to automate maintenance of delegation
information. This document describes a method to automate information. This document describes a method to automate
publication of subsequent DS records, after the initial one has been publication of subsequent DS records, after the initial one has been
published. published.
Readers are expected to be familiar with DNSSEC, including [RFC4033], Readers are expected to be familiar with DNSSEC, including [RFC4033],
[RFC4034], [RFC4035], [RFC5011] and [RFC6781]. [RFC4034], [RFC4035], [RFC5011] and [RFC6781].
This document is a compilation of two earlier drafts: draft-barwood-
dnsop-ds-publish[I-D.ds-publish] and draft-wkumari-dnsop-ezkeyroll.
This document outlines a technique in which the parent periodically This document outlines a technique in which the parent periodically
(or upon request) polls its signed children and automatically (or upon request) polls its signed children and automatically
publishes new DS records. To a large extent, the procedures this publishes new DS records. To a large extent, the procedures this
document follows are as described in [RFC6781] section 4.1.2. document follows are as described in [RFC6781] section 4.1.2.
This technique is designed to be friendly both to fully automated This technique is designed to be friendly both to fully automated
tools and humans. Fully automated tools can perform all the actions tools and humans. Fully automated tools can perform all the actions
needed without human intervention, and thus can monitor when it is needed without human intervention, and thus can monitor when it is
safe to move to the next step. safe to move to the next step.
skipping to change at page 4, line 32 skipping to change at page 4, line 29
o Parental Agent: "The entity that the child has relationship with, o Parental Agent: "The entity that the child has relationship with,
to change its delegation information" to change its delegation information"
o Provisioning system: "A system that the operator of the master DNS o Provisioning system: "A system that the operator of the master DNS
server operates to maintain the information published in the DNS. server operates to maintain the information published in the DNS.
This includes the systems that sign the DNS data" This includes the systems that sign the DNS data"
1.2. Requirements Notation 1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Background 2. Background
2.1. DNS Delegations 2.1. DNS Delegations
DNS operation consists of delegations of authority. For each DNS operation consists of delegations of authority. For each
delegation there are (most of the time) two parties: the parent and delegation there are (most of the time) two parties: the parent and
the child. the child.
The parent publishes information about the delegations to the child; The parent publishes information about the delegations to the child;
skipping to change at page 7, line 35 skipping to change at page 7, line 31
3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions 3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions
This document specifies two new DNS resource records, CDS and This document specifies two new DNS resource records, CDS and
CDNSKEY. These records are used to convey, from one zone to its CDNSKEY. These records are used to convey, from one zone to its
parent, the desired contents of the zone's DS resource record set parent, the desired contents of the zone's DS resource record set
residing in the parent zone. residing in the parent zone.
The CDS / CDNSKEY resource records are published in the child zone The CDS / CDNSKEY resource records are published in the child zone
and gives the child control of what is published for it in the and gives the child control of what is published for it in the
parental zone. The CDS / CDNSKEY RRset expresses what the child parental zone. The child can publish these manually, or they can be
would like the DS RRset to look like after the change; it is a automatically maintained by DNS provisioning tools. The CDS /
"replace" operation, and it is up to the consumer of the records to CDNSKEY RRset expresses what the child would like the DS RRset to
translate that into the appropriate add/delete operations in the look like after the change; it is a "replace" operation, and it is up
provisioning systems (and in the case of CDNSKEY, to generate the DS to the software that consumes the records to translate that into the
from the DNSKEY). If no CDS / CDNSKEY RRset is present in child, appropriate add/delete operations in the provisioning systems (and in
this means that no change is needed. the case of CDNSKEY, to generate the DS from the DNSKEY). If no CDS
/ CDNSKEY RRset is present in child, this means that no change is
needed.
[[RFC Editor: Please remove this paragraph before publication] [[RFC Editor: Please remove this paragraph before publication]
Version -04 of the ID that became this working group document (http:/ Version -04 of the ID that became this working group document
/tools.ietf.org/id/draft-kumari-ogud-dnsop-cds-04.txt) defined a new (http://tools.ietf.org/id/draft-kumari-ogud-dnsop-cds-04.txt) defined
record (CTA) that could hold either a DS or a DNSKEY record (with a a new record (CTA) that could hold either a DS or a DNSKEY record
selector to differentiate between them). In a shocking development, (with a selector to differentiate between them). In a shocking
there was almost full consensus that this was horrid :-) ] development, there was almost full consensus that this was horrid :-)
]
3.1. CDS Resource Record Format 3.1. CDS Resource Record Format
The wire and presentation format of the CDS ("Child DS") resource The wire and presentation format of the CDS ("Child DS") resource
record is identical to the DS record [RFC4034]. IANA has allocated record is identical to the DS record [RFC4034]. IANA has allocated
RR code 59 for the CDS resource record via expert review RR code 59 for the CDS resource record via expert review
[I-D.ds-publish]. The CDS RR uses the same registries as DS for its [I-D.ds-publish]. The CDS RR uses the same registries as DS for its
fields. fields.
No special processing is performed by authoritative servers or by No special processing is performed by authoritative servers or by
revolvers, when serving or resolving. For all practical purposes CDS resolvers, when serving or resolving. For all practical purposes CDS
is a regular RR type. is a regular RR type.
3.2. CDNSKEY Resource Record Format 3.2. CDNSKEY Resource Record Format
The wire and presentation format of the CDNSKEY ("Child DNSKEY") The wire and presentation format of the CDNSKEY ("Child DNSKEY")
resource record is identical to the DNSKEY record. IANA has resource record is identical to the DNSKEY record. IANA has
allocated RR code TBA1 for the CDNSKEY resource record via expert allocated RR code TBA1 for the CDNSKEY resource record via expert
review. The CDNSKEY RR uses the same registries as DNSKEY for its review. The CDNSKEY RR uses the same registries as DNSKEY for its
fields. fields.
No special processing is performed by authoritative servers or by No special processing is performed by authoritative servers or by
revolvers, when serving or resolving. For all practical purposes resolvers, when serving or resolving. For all practical purposes
CDNSKEY is a regular RR type. CDNSKEY is a regular RR type.
4. Automating DS Maintenance With CDS / CDNSKEY records 4. Automating DS Maintenance With CDS / CDNSKEY records
CDS / CDNSKEY resource records are intended to be "consumed" by CDS / CDNSKEY resource records are intended to be "consumed" by
delegation trust maintainers. The use of CDS / CDNSKEY is optional. delegation trust maintainers. The use of CDS / CDNSKEY is OPTIONAL.
The child SHOULD publish both CDS and CDNSKEY resource records. If If the child publishes either the CDS or the CDNSKEY resource record,
the child knows which the parent consumes, it MAY choose to only it SHOULD publish both. If the child knows which the parent
publish that record type (for example, some children wish the parent consumes, it MAY choose to only publish that record type (for
to publish a DS, but they wish to keep the DNSKEY "hidden" until example, some children wish the parent to publish a DS, but they wish
needed). If the child publishes both, the two RRsets MUST match in to keep the DNSKEY "hidden" until needed). If the child publishes
content. both, the two RRsets MUST match in content.
4.1. CDS / CDNSKEY Processing Rules 4.1. CDS / CDNSKEY Processing Rules
If there are no CDS / CDNSKEY RRset in the child, this signals that If there are no CDS / CDNSKEY RRset in the child, this signals that
no change should be made to the current DS set. This means that, no change should be made to the current DS set. This means that,
once the child and parent are in sync, the Child DNS Operator MAY once the child and parent are in sync, the Child DNS Operator MAY
remove all CDS and CDNSKEY resource records from the zone. The Child remove all CDS and CDNSKEY resource records from the zone. The Child
DNS Operator may choose to do this to decrease the size of the zone, DNS Operator may choose to do this to decrease the size of the zone,
or to decrease the workload for the parent (if the parent receives no or to decrease the workload for the parent (if the parent receives no
CDS / CDNSKEY records it can go back to sleep). If it does receive a CDS / CDNSKEY records it can go back to sleep). If it does receive a
skipping to change at page 9, line 18 skipping to change at page 9, line 21
o Signer: MUST be signed with a key that is represented in both the o Signer: MUST be signed with a key that is represented in both the
current DNSKEY and DS RRsets (unless the parent uses the CDS / current DNSKEY and DS RRsets (unless the parent uses the CDS /
CDNSKEY RRset for initial enrollment, in that case the parent CDNSKEY RRset for initial enrollment, in that case the parent
validates the CDS / CDNSKEY through some other means (see validates the CDS / CDNSKEY through some other means (see
Section 6.1 and the Security Considerations.) Section 6.1 and the Security Considerations.)
o Continuity: MUST NOT break the current delegation if applied to DS o Continuity: MUST NOT break the current delegation if applied to DS
RRset. RRset.
If any these conditions fail the CDS / CDNSKEY resource record MUST If any these conditions fail the CDS / CDNSKEY resource record MUST
be ignored. be ignored, and this error SHOULD be logged.
5. CDS / CDNSKEY Publication 5. CDS / CDNSKEY Publication
Child DNS Operator publishes CDS and / or CDNSKEY resource records. The Child DNS Operator publishes CDS and / or CDNSKEY resource
In order to be valid, the CDS / CDNSKEY RRset MUST be compliant with records. In order to be valid, the CDS / CDNSKEY RRset MUST be
the rules in Section 4.1. When the Parent DS is "in sync" with the compliant with the rules in Section 4.1. When the Parent DS is "in
CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the sync" with the CDS / CDNSKEY resource records, the Child DNS Operator
CDS / CDNSKEY record(s); the child can determine if this is the case MAY delete the CDS / CDNSKEY record(s); the child can determine if
by querying for DS records in the parent. this is the case by querying for DS records in the parent
6. Parent Side CDS / CDNSKEY Consumption 6. Parent Side CDS / CDNSKEY Consumption
The CDS / CDNSKEY RRset SHOULD be used by the Parental Agent to The CDS / CDNSKEY RRset SHOULD be used by the Parental Agent to
update the DS RRset in the parent zone. The Parental Agent for this update the DS RRset in the parent zone. The Parental Agent for this
uses a tool that understands the CDS / CDNSKEY signing rules from uses a tool that understands the CDS / CDNSKEY signing rules from
Section 4.1 so it might not be able to use a standard validator. Section 4.1 so it might not be able to use a standard validator.
The parent MUST choose to use either CDNSKEY or CDS resource records The parent MUST choose to use either CDNSKEY or CDS resource records
as their default updating mechanism. The parent MAY only accept as their default updating mechanism. The parent MAY only accept
skipping to change at page 11, line 25 skipping to change at page 11, line 25
CDNSKEY RRset do not overwrite more recent versions. This MAY be CDNSKEY RRset do not overwrite more recent versions. This MAY be
accomplished by checking that the signature inception in the RRSIG accomplished by checking that the signature inception in the RRSIG
for CDS / CDNSKEY RRset is later and / or the serial number on the for CDS / CDNSKEY RRset is later and / or the serial number on the
child's SOA is greater. This may require the Parental Agent to child's SOA is greater. This may require the Parental Agent to
maintain some state information. maintain some state information.
The Parental Agent MAY take extra security measures. For example, to The Parental Agent MAY take extra security measures. For example, to
mitigate the possibility that a Child's key signing key has been mitigate the possibility that a Child's key signing key has been
compromised, the Parental Agent may, for example, inform (by email or compromised, the Parental Agent may, for example, inform (by email or
other methods) the Child DNS Operator of the change. However the other methods) the Child DNS Operator of the change. However the
precise out-of-band measures that a parent zone SHOULD take are precise out-of-band measures that a parent zone takes are outside the
outside the scope of this document. scope of this document.
Once the Parental Agent has obtained a valid CDS / CDNSKEY RRset it Once the Parental Agent has obtained a valid CDS / CDNSKEY RRset it
MUST check the publication rules from section 4.1. In particular the MUST check the publication rules from section 4.1. In particular the
Parental Agent MUST check the Continuity rule and do its best not to Parental Agent MUST check the Continuity rule and do its best not to
invalidate the Child zone. Once checked and if the information in invalidate the Child zone. Once checked and if the information in
the CDS / CDNSKEY and DS differ it may apply the changes to the the CDS / CDNSKEY and DS differ it may apply the changes to the
parent zone. If the parent consumes CDNSKEY, the parent should parent zone. If the parent consumes CDNSKEY, the parent should
calculate the DS before doing this comparison. calculate the DS before doing this comparison.
6.2.1. Parent Calculates DS 6.2.1. Parent Calculates DS
skipping to change at page 11, line 52 skipping to change at page 11, line 52
When a Parent operates in "calculate DS" mode it can operate in one When a Parent operates in "calculate DS" mode it can operate in one
of two sub-modes: of two sub-modes:
full: it only publishes DS records it calculates from DNSKEY full: it only publishes DS records it calculates from DNSKEY
records, records,
augment: it will make sure there are DS records for the digest augment: it will make sure there are DS records for the digest
algorithm(s) it requires(s). algorithm(s) it requires(s).
In the case where the parent fetches the CDNSKEY RRset and calculates In the case where the parent fetches the CDNSKEY RRset and calculates
the DS it MAY be the case that the DS published in the parent zone is the DS the resulting DS can differ from the CDS published by the
not identical with the data in the CDS resource record made available child. It is expected that the differences are only due different
by the child. set of digest algorithms used.
7. IANA Considerations 7. IANA Considerations
IANA has assigned RR Type code 59 for the CDS resource record. This IANA has assigned RR Type code 59 for the CDS resource record. This
was done for an earlier version of this document[I-D.ds-publish] This was done for an earlier version of this document[I-D.ds-publish] This
document is to become the reference for CDS RRtype. document is to become the reference for CDS RRtype.
IANA is requested to assign another RR Type for the CDNSKEY, and to IANA is requested to assign an RR Type for the CDNSKEY, see below
replace TBA1 with this value (currently 60 is still free, it would be
nice if that were assigned...) Type: CDNSKEY
Value: TBD1 (60 suggested)
Meaning: DNSKEY(s) the child wants reflected in DS
Reference: This document
8. Privacy Considerations 8. Privacy Considerations
All of the information handled / transmitted by this protocol is All of the information handled / transmitted by this protocol is
public information published in the DNS. public information published in the DNS.
9. Security Considerations 9. Security Considerations
This work is for the normal case; when things go wrong there is only This work is for the normal case; when things go wrong there is only
so much that automation can fix. so much that automation can fix.
skipping to change at page 12, line 50 skipping to change at page 13, line 9
and remove any compromised DS keys. and remove any compromised DS keys.
A compromise of the account with the parent (e.g. registrar) will not A compromise of the account with the parent (e.g. registrar) will not
be mitigated by this technique, as the "new registrant" can delete / be mitigated by this technique, as the "new registrant" can delete /
modify the DS records at will. modify the DS records at will.
While it may be tempting, this SHOULD NOT be used for initial While it may be tempting, this SHOULD NOT be used for initial
enrollment of keys since there is no way to ensure that the initial enrollment of keys since there is no way to ensure that the initial
key is the correct one. If is used, strict rules for inclusion of key is the correct one. If is used, strict rules for inclusion of
keys such as hold down times, challenge data inclusion or similar, keys such as hold down times, challenge data inclusion or similar,
ought to be used, along with some kind of challenge mechanism. A MUST be used, along with some kind of challenge mechanism. A child
child cannot use this mechanism to go from signed to unsigned cannot use this mechanism to go from signed to unsigned (publishing
(publishing an empty CDS / CDNSKEY RRset means no-change should be an empty CDS / CDNSKEY RRset means no-change should be made in the
made in the parent). parent).
The CDS RR type should allow for enhanced security by simplifying The CDS RR type should allow for enhanced security by simplifying
process. Since key change is automated, updating a DS RRset by other process. Since key change is automated, updating a DS RRset by other
means may be regarded as unusual and subject to extra security means may be regarded as unusual and subject to extra security
checks. checks.
As this introduces a new mechanism to update information in the As this introduces a new mechanism to update information in the
parent it MUST be clear who is fetching the records and creating the parent it MUST be clear who is fetching the records and creating the
appropriate records in the parent zone. Specifically some operations appropriate records in the parent zone. Specifically some operations
may use other mechanisms than what is described here. For example, a may use other mechanisms than what is described here. For example, a
skipping to change at page 13, line 37 skipping to change at page 13, line 44
different answers on different checks or CDS RR validation fails. In different answers on different checks or CDS RR validation fails. In
the worst case, the Parental Agent performs an action reversing a the worst case, the Parental Agent performs an action reversing a
prior action but after the child signing system decides to take the prior action but after the child signing system decides to take the
next step in the key change process, resulting in a broken next step in the key change process, resulting in a broken
delegation. delegation.
DNS is a loosely coherent distributed database with local caching; DNS is a loosely coherent distributed database with local caching;
therefore, it is important to allow old information to expire from therefore, it is important to allow old information to expire from
caches before deleting DS or DNSKEY records. Similarly, it is caches before deleting DS or DNSKEY records. Similarly, it is
important to allow new records to propagate through the DNS before important to allow new records to propagate through the DNS before
use, see [RFC6781] and [I-D.key-time] use, see [RFC6781].
It is common practice for users to outsource their DNS hosting to a It is common practice for users to outsource their DNS hosting to a
third-party DNS provider. In order for that provider to be able to third-party DNS provider. In order for that provider to be able to
maintain the DNSSEC information some users give the provider their maintain the DNSSEC information some users give the provider their
registrar login credentials (which obviously has negative security registrar login credentials (which obviously has negative security
implications). Deploying the solution described in this document implications). Deploying the solution described in this document
allows the 3rd party DNS provider to maintain the DNSSEC information allows the 3rd party DNS provider to maintain the DNSSEC information
without giving them the registrar credentials, thereby improving without giving them the registrar credentials, thereby improving
security. security.
skipping to change at page 14, line 16 skipping to change at page 14, line 22
We would like to thank a large number of folk, including: Mark We would like to thank a large number of folk, including: Mark
Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian
Dickson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir Dickson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir
Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu, Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu,
Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul
Wouters, John Dickinson, Timothe Litt and Edward Lewis. Wouters, John Dickinson, Timothe Litt and Edward Lewis.
Special thanks to Wes Hardaker for contributing significant text and Special thanks to Wes Hardaker for contributing significant text and
creating the complementary (CSYNC) solution, and to Patrik Faltstrom, creating the complementary (CSYNC) solution, and to Patrik Faltstrom,
Paul Hoffman, Matthijs Mekking, Mukund Sivaraman and Jeremy C. Reed Paul Hoffman, Matthijs Mekking, Mukund Sivaraman and Jeremy C. Reed
for text and in-depth review. for text and in-depth review. Brian Carpender provided a good Gen-
Art review.
There were a number of other folk with whom we discussed this, There were a number of other folk with whom we discussed this,
apologies for not remembering everyone. apologies for not remembering everyone.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 15, line 19 skipping to change at page 15, line 28
[I-D.csync] [I-D.csync]
Hardaker, W., "Child To Parent Synchronization in DNS", Hardaker, W., "Child To Parent Synchronization in DNS",
draft-hardaker-dnsop-csync-02 (work in progress), July draft-hardaker-dnsop-csync-02 (work in progress), July
2013. 2013.
[I-D.ds-publish] [I-D.ds-publish]
Barwood, G., "DNS Transport", draft-barwood-dnsop-ds- Barwood, G., "DNS Transport", draft-barwood-dnsop-ds-
publish-02 (work in progress), June 2011. publish-02 (work in progress), June 2011.
[I-D.key-time]
Mekking, W., "DNSSEC Key Timing Considerations", draft-
ietf-dnsop-dnssec-key-timing-03 (work in progress), July
2012.
[I-D.parent-zones] [I-D.parent-zones]
Andrews, M., "Updating Parent Zones", draft-andrews-dnsop- Andrews, M., "Updating Parent Zones", draft-andrews-dnsop-
update-parent-zones-04 (work in progress), November 2013. update-parent-zones-04 (work in progress), November 2013.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009. STD 69, RFC 5730, August 2009.
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
Security Extensions Mapping for the Extensible Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 5910, May 2010. Provisioning Protocol (EPP)", RFC 5910, May 2010.
skipping to change at page 16, line 21 skipping to change at page 16, line 26
EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number
of ccTLDs there are other mechanisms in use as well as EPP, but in of ccTLDs there are other mechanisms in use as well as EPP, but in
general there seems to be a movement towards EPP usage when DNSSEC is general there seems to be a movement towards EPP usage when DNSSEC is
enabled in the TLD. enabled in the TLD.
Appendix B. CDS key rollover example Appendix B. CDS key rollover example
This section shows an example on how CDS is used when performing a This section shows an example on how CDS is used when performing a
KSK rollover, this example will demonstrate the the double DS KSK rollover, this example will demonstrate the the double DS
rollover method from section 4.1.2 in [RFC6781]. Other rollovers rollover method from section 4.1.2 in [RFC6781]. Other rollovers
using CDNSKEY and double KSK are left as an exersize to the reader. using CDNSKEY and double KSK are left as an exercise to the reader.
The table below does not reflect the ZSK keys as they are not The table below does not reflect the ZSK keys they just do not matter
material during KSK rollovers. The wait states below are highlight during KSK rollovers. The wait states below highlight what RRset
what RRset needs to expire from caches before progressign to the next needs to expire from caches before progressing to the next step.
step.
+-------+---------------+----------+---------+------------+---------+ +------+---------------+---------+---------+--------------+---------+
| Step | State | Parent | Child | DNSKEY and | Child | | Step | State | Parent | Child | DNSKEY and | Child |
| | | DS | KSK | CDS signer | CDS | | | | DS | KSK | CDS signer | CDS |
+-------+---------------+----------+---------+------------+---------+ +------+---------------+---------+---------+--------------+---------+
| 0 | Beginning | A | A | A | | | | Beginning | A | A | A | |
| 1 | Add CDS | A | A | A | AB | | 1 | Add CDS | A | A | A | AB |
| 2 | Wait for DS | A | A | A | AB | | Wait | for DS change | A | A | A | AB |
| | change | | | | | | 2 | Updated DS | AB | A | A | AB |
| 3 | Updated DS | AB | A | A | AB | | Wait | > DS TTL | AB | A | A | AB |
| 4 | wait > DS TTL | AB | A | A | AB | | 3 | Actual | AB | B | B | AB |
| 5 | Actual | AB | B | B | AB | | | Rollover | | | | |
| | Rollover | | | | | | Wait | > DNSKEY TTL | AB | B | B | AB |
| 6 | wait > DNSKEY | AB | B | B | AB | | 4 | Child Cleanup | AB | B | B | B |
| | TTL | | | | | | 5 | Parent cleans | B | B | B | B |
| 7 | Cleanup | AB | B | B | B | | 6 | Optional CDS | B | B | B | |
| | starts | | | | | | | delete | | | | |
| 8 | Parent | B | B | B | B | +------+---------------+---------+---------+--------------+---------+
| | updates | | | | |
| 9 | Optional CDS | B | B | B | |
| | delete | | | | |
+-------+---------------+----------+---------+------------+---------+
Table 1: States Table 1: States
End text
Appendix C. Changes / Author Notes. Appendix C. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
WG-13 to WG-14 IETF Last call and IESG processing
o Applied text fixes from Phil Pennock
o Addressed comments from Brian Carpender GEN-ART review.
o Barry Leiba wanted better IANA considerations and suggested some
text changes in 6.1 and 6.2.1
o Reformatted the Appendix B table to be clearer.
WG-12 to WG-13 WG-12 to WG-13
o Added appendix B showing Key rollover using CDS. o Added appendix B showing Key rollover using CDS.
WG-11 to WG-12 WG-11 to WG-12
o Many nits and helpful grammar fixes from Jeremy C. Reed. o Many nits and helpful grammar fixes from Jeremy C. Reed.
WG-10 to WG-11 WG-10 to WG-11
o More useful text from Matthijs. o More useful text from Matthijs.
o Explained why the child might want to remove the CDS / CDNSKEY o Explained why the child might want to remove the CDS / CDNSKEY
Records. Records.
WG-09 to WG-10 WG-09 to WG-10
 End of changes. 29 change blocks. 
88 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/