draft-ietf-dnsop-delegation-trust-maintainance-08.txt   draft-ietf-dnsop-delegation-trust-maintainance-09.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 17, 2014 Shinkuro Inc. Expires: October 18, 2014 Shinkuro Inc.
G. Barwood G. Barwood
April 15, 2014 April 16, 2014
Automating DNSSEC Delegation Trust Maintenance Automating DNSSEC Delegation Trust Maintenance
draft-ietf-dnsop-delegation-trust-maintainance-08 draft-ietf-dnsop-delegation-trust-maintainance-09
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 1, line 38 skipping to change at page 1, line 38
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 October 17, 2014. This Internet-Draft will expire on October 18, 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 40 skipping to change at page 2, line 40
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 . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15 Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
When a DNS operator first signs their zone, they need to communicate The first time a DNS operator signs a zone, they need to communicate
their DS record(s) (or DNSKEY(s)) to their parent through some out- the keying material to their parent through some out-of-band method
of-band method to complete the chain of trust. to complete the chain of trust. Depending on the desires of the
parent, the child might send their DNSKEY record, a DS record, or
both.
Each time the child changes the key that is represented in the Each time the child changes the key that is represented in the
parent, the updated and/or deleted key information has to be parent, the updated and/or deleted key information has to be
communicated to the parent and published in the parent's zone. How communicated to the parent and published in the parent's zone. How
this information is sent to the parent depends on the relationship this information is sent to the parent depends on the relationship
the child has with the parent. In many cases this is a manual the child has with the parent. In many cases this is a manual
process, and not an easy one. For each key change, there may be up process, and not an easy one. For each key change, there may be up
to two interactions with the parent. Any manual process is to two interactions with the parent. Any manual process is
susceptible to mistakes and/or errors. In addition, due to the susceptible to mistakes and/or errors. In addition, due to the
annoyance factor of the process, operators may avoid changing keys or annoyance factor of the process, operators may avoid changing keys or
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-08 to WG-09
o New text from Paul Hoffman for the first paragraph of the intro.
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.
o Comments from Paul Hoffman and Tim W o Comments from Paul Hoffman and Tim W
WG-06 to WG-07 WG-06 to WG-07
o Incorporated nits / editorial comments from Tim Wicinski. o Incorporated nits / editorial comments from Tim Wicinski.
 End of changes. 7 change blocks. 
8 lines changed or deleted 16 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/