Automating DNSSEC delegation trust maintenance
draft-ietf-dnsop-delegation-trust-maintainance-02
| The information below is for an old version of the document |
| Document |
Type |
|
Active Internet-Draft (dnsop WG)
|
|
Last updated |
|
2014-02-05
|
|
Replaces |
|
draft-kumari-ogud-dnsop-cds
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
pdf
htmlized
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
None
|
| IESG |
IESG state |
|
I-D Exists
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
dnsop W. Kumari
Internet-Draft Google
Intended status: Informational O. Gudmundsson
Expires: August 9, 2014 Shinkuro Inc.
G. Barwood
February 5, 2014
Automating DNSSEC delegation trust maintenance
draft-ietf-dnsop-delegation-trust-maintainance-02
Abstract
This document describes a method to allow DNS operators to more
easily update DNSSEC Key Signing Keys using DNS as communication
channel. This document does not address the initial configuration of
trust anchors for a domain. The technique described is aimed at
delegations in which it is currently hard to move information from
the child to parent.
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 August 9, 2014.
Copyright Notice
Copyright (c) 2014 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
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Kumari, et al. Expires August 9, 2014 [Page 1]
Internet-Draft Automating Delegation Trust Maint February 2014
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DNS delegations . . . . . . . . . . . . . . . . . . . . . 4
2.2. Relationship between Parent and Child DNS operator . . . 5
2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6
2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 7
3. CDS / CDNSKEY (Child DS/ Child DNSKEY) record definitions . . 7
3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8
3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
4. Automating DS maintainance with CDS/CDNSKEY records . . . . . 8
4.1. CDS / CDNSKEY processing rules . . . . . . . . . . . . . 9
5. Child's CDS / CDNSKEY Publication . . . . . . . . . . . . . . 9
6. Parent side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9
6.1. Detecting a changed CDS / CDNSKEY . . . . . . . . . . . . 10
6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10
6.1.2. Other mechanisms . . . . . . . . . . . . . . . . . . 10
6.2. Using the new CDS / CDNSKEY records . . . . . . . . . . . 11
6.2.1. Parent calculates DS . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
When a DNS operator first signs their zone, they need to communicate
their DS record(s) (or DNSKEY(s)) to their parent through some out-
of-band method to complete the chain of trust.
Each time the child changes/rolls the key that is represented in the
Show full document text