draft-ietf-dnsop-delegation-trust-maintainance-09.txt   draft-ietf-dnsop-delegation-trust-maintainance-10.txt 
dnsop W. Kumari dnsop W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational O. Gudmundsson Intended status: Informational O. Gudmundsson
Expires: October 18, 2014 Shinkuro Inc. Expires: October 18, 2014 Shinkuro Inc.
G. Barwood G. Barwood
April 16, 2014 April 16, 2014
Automating DNSSEC Delegation Trust Maintenance Automating DNSSEC Delegation Trust Maintenance
draft-ietf-dnsop-delegation-trust-maintainance-09 draft-ietf-dnsop-delegation-trust-maintainance-10
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. This document does not address the initial configuration of channel. This document does not address the initial configuration of
trust anchors for a domain. The technique described is aimed at trust anchors for a domain. The technique described is aimed at
delegations in which it is currently hard to move information from delegations in which it is currently hard to move information from
the child to parent. the child to parent.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
child has told the parent it will use to sign its DNSKEY RRset. In child has told the parent it will use to sign its DNSKEY RRset. In
DNSSEC trust relationship between zones is provided by the following DNSSEC trust relationship between zones is provided by the following
chain: chain:
parent DNSKEY --> DS --> child DNSKEY. parent DNSKEY --> DS --> child DNSKEY.
A prior proposal [I-D.auto-cpsync] suggested that the child send an A prior proposal [I-D.auto-cpsync] suggested that the child send an
"update" to the parent via a mechanism similar to Dynamic Update. "update" to the parent via a mechanism similar to Dynamic Update.
The main issue became: How does the child find the actual parental The main issue became: How does the child find the actual parental
agent/server to send the update to? While that could have been agent/server to send the update to? While that could have been
solved via technical means, it failed to each consensus. There is solved via technical means, it failed to reach consensus. There is
also a similar proposal in [I-D.parent-zones]. also a similar proposal in [I-D.parent-zones].
As the DS record can only be present at the parent ( [RFC4034]), some As the DS record can only be present at the parent ( [RFC4034]), some
other method is needed to automate which DNSKEYs are picked to be other method is needed to automate which DNSKEYs are picked to be
represented in the parent zone's DS records. One possibility is to represented in the parent zone's DS records. One possibility is to
use flags in the DNSKEY record. If the SEP bit is set, this use flags in the DNSKEY record. If the SEP bit is set, this
indicates that the DNSKEY is intended for use as a secure entry indicates that the DNSKEY is intended for use as a secure entry
point. This DNSKEY signs the DNSKEY RRset, and the Parental Agent point. This DNSKEY signs the DNSKEY RRset, and the Parental Agent
can calculate DS records based on that. But this fails to meet some can calculate DS records based on that. But this fails to meet some
operating needs, including the child having no influence what DS operating needs, including the child having no influence what DS
skipping to change at page 6, line 20 skipping to change at page 6, line 20
o Multi-step Combinations: The information flows through an o Multi-step Combinations: The information flows through an
intermediary. It is possible, but unlikely, that all the steps intermediary. It is possible, but unlikely, that all the steps
are automated via API's and there are no humans are involved. are automated via API's and there are no humans are involved.
A domain name holder (Child) may operate its own DNS servers or A domain name holder (Child) may operate its own DNS servers or
outsource the operation. While we use the word parent as a singular, outsource the operation. While we use the word parent as a singular,
parent can consist of single entity or a composite of many discrete parent can consist of single entity or a composite of many discrete
parts that have rules and roles. We refer to the entity that the parts that have rules and roles. We refer to the entity that the
child corresponds with as the Parent. child corresponds with as the Parent.
In some cases an organization may delegate parts of its name-space to An organization (such as an enterprise) may delegate parts of its
be operated by a group that is not the same as that which operates name-space to be operated by a group that is not the same as that
the organization's DNS servers. In this case the flow of information which operates the organization's DNS servers. In some of these
is frequently handled in either an ad hoc manner or via some cases the flow of information is handled in either an ad hoc manner
corporate mechanism; this can range from email to fully-automated or via some corporate mechanism; this can range from email to fully-
operation. automated operation.
2.2.1. Solution Space 2.2.1. Solution Space
This document is aimed at the cases in which there is a separation This document is aimed at the cases in which there is a separation
between the child and parent. between the child and parent.
A further complication is when the Child DNS Operator is not the A further complication is when the Child DNS Operator is not the
Child. There are two common cases of this: Child. There are two common cases of this:
a) The Parental Agent (e.g. registrar) handles the DNS operation. a) The Parental Agent (e.g. registrar) handles the DNS operation.
skipping to change at page 9, line 9 skipping to change at page 9, line 9
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. remove all CDS and CDNSKEY resource records from the zone.
Following acceptance rules are placed on the CDS / CDNSKEY resource Following acceptance rules are placed on the CDS / CDNSKEY resource
records as follows: records as follows:
o Location: "the CDS / CDNSKEY resource records MUST be at the child o Location: "the CDS / CDNSKEY resource records MUST be at the child
zone apex". zone apex".
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 RRset's." current DNSKEY and DS RRset's" (unless the parent validates the
CDS / CDNSKEY though some other means (see Section 6.1 and the
Security Considerations.))
o Continuity: "MUST NOT break the current delegation if applied to o Continuity: "MUST NOT break the current delegation if applied to
DS RRset" DS 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.
5. CDS / CDNSKEY Publication 5. CDS / CDNSKEY Publication
Child DNS Operator publishes a CDS and / or CDNSKEY resource records. Child DNS Operator publishes CDS and / or CDNSKEY resource records.
In order to be valid, the CDS / CDNSKEY RRset MUST be compliant with In order to be valid, the CDS / CDNSKEY RRset MUST be compliant with
the rules in Section 4.1. When the Parent DS is "in-sync" with the the rules in Section 4.1. When the Parent DS is "in-sync" with the
CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the
CDS / CDNSKEY record(s); the child can determine if this is the case CDS / CDNSKEY record(s); the child can determine if this is the case
by quering for DS records in the parent. Note that if the child has by querying for DS records in the parent.
published a CDNSKEY RR, the Parent will have to calculate the DS
(using the requested digest algorithm) to do the comparison.
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 may 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
either CDNSKEY or CDS, but it MAY also accept both, so it can use the either CDNSKEY or CDS, but it MAY also accept both, so it can use the
other in the absence of the default updating mechanism, but it MUST other in the absence of the default updating mechanism, but it MUST
NOT expect there to be both. NOT expect there to be both.
6.1. Detecting a Changed CDS / CDNSKEY 6.1. Detecting a Changed CDS / CDNSKEY
How the Parental Agent gets the CDS / CDNSKEY RRset may differ, below How the Parental Agent gets the CDS / CDNSKEY RRset may differ, below
skipping to change at page 14, line 10 skipping to change at page 14, line 10
By automating the maintenance of the DNSSEC key information (and By automating the maintenance of the DNSSEC key information (and
removing humans from the process), we expect to decrease the number removing humans from the process), we expect to decrease the number
of DNSSEC related outages, which should increase DNSSEC deployment. of DNSSEC related outages, which should increase DNSSEC deployment.
10. Acknowledgements 10. Acknowledgements
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
Dickinson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir Dickinson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir
Hussain, Tatuya Jinmei, Olaf Kolkman, Cricket Liu, Stephan Lagerholm, Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu,
Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul Stephan Lagerholm, Matt Larson, Marco Sanz, Antoin Verschuren,
Wouters, John Dickinson, Timothe Litt and Edward Lewis. Suzanne Woolf, Paul 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 and Mukund Sivaraman for text and in- Paul Hoffman, Matthijs Mekking and Mukund Sivaraman for text and in-
depth review. depth 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
skipping to change at page 16, line 19 skipping to change at page 16, line 19
In many RRR cases the Registrar and Registry communicate via In many RRR cases the Registrar and Registry communicate via
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. Changes / Author Notes. Appendix B. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
WG-09 to WG-10
o Incorporated off list comments from Stephan Lagerholm. Largest
change is fixing discrepancy between parent MAY perform OOB
validation and the Signer rule in 4.1. Clarified by updating
signer rule to allow
WG-08 to WG-09 WG-08 to WG-09
o New text from Paul Hoffman for the first paragraph of the intro. o New text from Paul Hoffman for the first paragraph of the intro.
o ... with a modification from Jaap. o ... with a modification from Jaap.
WG-07 to WG-08 WG-07 to WG-08
o Incorporated text from Antoin Verschuren at the end of Section 6. o Incorporated text from Antoin Verschuren at the end of Section 6.
 End of changes. 9 change blocks. 
17 lines changed or deleted 25 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/