DNEXT Working Group S. Rose
Internet Draft NIST
Expires: January 2001 July 2000
Category: Informational
DNS Security Document Roadmap
------------------------------
<draft-srose-dnsext-dnssec-roadmap-00.txt>
Status of this Document
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Distribution of this document is unlimited. Comments
regarding this document should be sent to the author.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Abstract
DNS Security (DNSSEC)technology is comprised of
extensions to the Domain Name System (DNS) protocol that
provide data integrity and authentication to security
aware resolvers and applications through the use of
cryptographic digital signatures. Several documents
exist to describe these extensions and the implementation
specific details regarding specific digital signing
schemes. The interrelationship between these different
documents is discussed here. A brief overview of what to
Rose [Page 1]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
find in which document and author guidelines for what to
include in new DNS Security documents, or revisions to
existing documents, is described.
Table of Contents
1. Introduction ............................................... 3
2. Interrelationship of DNS Security Documents ................ 3
3. Relationship of DNS Security Documents to other DNS Docu-
ments .......................................................... 6
4. Recommended Content for new DNS Security Documents ......... 6
4.1 Security Related Resource Records ......................... 6
4.2 Digital Signature Algorithm Implementation ................ 7
4.3 Refinement of Security Procedures ......................... 7
4.4 The Use of DNS Security Extensions with Other Protocols
................................................................ 8
5. Security Considerations .................................... 8
6. Acknowledgements ........................................... 8
7. References ................................................. 9
8. Author's Address ........................................... 10
Expiration and File Name ....................................... 10
Rose [Page 2]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
1. Introduction
This document is intended to provide guidelines for the development
of supplemental documents describing security extensions to the
Domain Name System (DNS).
The main goal of the DNS Security (DNSSEC) protocol extensions is to
add data authentication and integrity services to the DNS protocol.
These protocol extensions should be differentiated from DNS opera-
tional security issues, which are beyond the scope of this effort.
DNS Security documents fall into one or possibly more of the follow-
ing sub-categories: new DNS security resource records, implementation
details of specific digital signing algorithms for use in DNS Secu-
rity and Secure DNS transactions. Since the goal of DNS Security
extensions is to become part of the DNS protocol standard, additional
documents that seek to refine a portion of the security extensions
will be introduced as the specifications progress along the IETF
standards track.
There is a set of basic guidelines for each sub-category of documents
that explains what should be included, what should be considered a
protocol extension, and what should be considered an operational
issue. Currently, there are at least two documents that fall under
operational security considerations that deal specifically with the
DNS security extensions: The first is RFC 2541 which deals with the
operational side of implementing the security extensions. The other
is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These documents
should be considered part of the operational side of DNS, but will be
addressed as a supplemental part of the DNS Security roadmap. That
is not to say that these two documents are not important to securing
a DNS zone, but it does not directly address the proposed DNS secu-
rity extensions. Authors of documents that seek to address the
operational concerns of DNS security should be aware of the structure
of DNS Security documentation if they wish to include their documents
in the DNSEXT Working Group in addition to the DNS Operations WG.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. It is
also assumed the reader has some knowledge of the Domain Name System
[RFC1035] and the Domain Name System Security Extensions [RFC2535].
2. Interrelationship of DNS Security Documents
The DNSSEC set of documents can be partitioned into five main groups
as depicted in Figure 1. All of these documents in turn are under
the larger umbrella group of DNS base protocol documents. It is
Rose [Page 3]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
possible that some documents fall into more than one of these
categories, such as RFC 2535, and should follow the guidelines for
the all of the document groups it falls into. However, it is wise to
limit the number of "uberdocuments" that try to be everything to
everyone. The documents listed in each category are current as to
the time of writing.
+--------------------------------+
| |
| Base DNS Protocol Docs. |
| [RFC1035, RFC2181, etc.] |
| |
+--------------------------------+
|
|
|
+------------+ +-----------+ +-------------+
| New | | DNSSEC | | New |
| Security | <------->| protocol |<-------->| Security |
| RRs | | | | Uses |
| [RFC2538, | | [RFC2535, | | |
| SIG0] | | CLARIFY, | +-------------+
+------------+ | AUTH, |
| SIZE ] |
+-----------+
|
|
+----------------------+***********************
| | *
| | *
+------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
| DS | | | | Implementation |
| Algorithm | | Transactions | * Notes *
| Impl. | | | | |
| [RFC2536, | | [RFC2845, | * [CAIRN] *
| RFC2537 | | TKEY] | | |
| RFC2539 ] | | | +-*-*-*-*-*-*-*-*-+
+------------+ +---------------+
Figure 1 DNSSEC Document Roadmap
The "DNSSEC protocol" document set refers to the document that makes
up the groundwork for adding security to the DNS protocol [RFC2535]
and updates to this document. RFC 2535 laid out the goals and expec-
tations of DNS Security and the new security related Resource Records
KEY, SIG, and NXT. Expanding from this document, related document
groups include the implementation documents of various digital
Rose [Page 4]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
signature algorithms with DNSSEC, and documents further refining the
transaction of messages. It is expected that RFC 2535 will be
obseleted by one or more documents that refine the set of security
extensions and DNS security transactions. Documents that seek to
modify or clarify the base protocol documents should state so clearly
in the introduction of the document (as well as proscribe to the IETF
guidelines of RFC/Internet Draft author guidelines). Also, the por-
tions of the specification to be modified SHOULD be synopsized in the
new document for the benefit of the reader. The "DNSSEC protocol"
set includes the documents [RFC2535], [CLARIFY], [AUTH], [SIZE] and
their derivative documents.
The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Record to the set of base DNS Record
types. These new records can be related to securing the DNS protocol
[RFC2535] [SIG0] or using DNS security for other purposes such as
storing certificates [RFC2538].
The "DS Algorithm Impl" document set refers to the group of documents
that describe how a specific digital signature algorithm is imple-
mented to fit the DNSSEC Resource Record format. Each one of these
documents deals with one specific digital signature algorithm. Exam-
ples of this set include [RFC2536] [RFC2537] and [RFC2539].
The "Transactions" document set refers to the group of documents that
deal with the message transaction sequence of security related DNS
operations. The contents and sequence for operations such as dynamic
update [RFC2137] [UPDATE] and transaction signatures [RFC2845] are
described in this document category. Additional message transaction
schemes to support DNSSEC operation would also fall under this group,
including secret key establishment [TKEY], and verification.
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. Documents that fall in this category include the
use of DNS in the distribution of certificates and individual user
public keys (PGP, email, etc.).
Lastly, there is a set of documents that should be classified as
"Implementation Notes". Because the DNS security extensions are
still in the developmental stage, there is an audience for documents
that detail the transition and implementation of the security exten-
sions. These have more to do with the practical side of DNS opera-
tions, but can also point to places in the protocol specifications
that need improvement. Documents in this set may be offspring of
both the DNSEXT and/or DNSOP working groups. Currently, there is
only one Internet Draft that falls under this category: The report
on the CAIRN DNSSEC testbed [CAIRN]. This document was submitted
Rose [Page 5]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
through the DNSOP working group, however the main concern of this
document in the implementation and limitations of the DNS security
extensions, hence its interest to the DNS security community.
Authors of documents that deal with the implementation and opera-
tional side of the DNSSEC specifications would be advised/encouraged
to submit their documents to the DNSEXT working group as well.
3. Relationship of DNS Security Documents to other DNS Documents
The DNS security related extensions should be considered a subset of
the DNS protocol. The DNS Security working group of the IETF
(DNSSEC) has been absorbed into the larger DNS Extensions working
group (DNSEXT). Therefore, all DNS security related documents should
be seen as a subset of the main DNS architecture documents. It is a
good idea for authors of future DNS security documents to be familiar
with the contents of these base protocol documents.
4. Recommended Content for new DNS Security Documents
Documents that seek to make additions or revisions to the DNS proto-
col to add security should follow common guidelines as to minimum
required content and structure. It is the purpose of this document
roadmap to establish criteria for content that any new DNS security
protocol specifications document SHOULD contain. This criteria
SHOULD be interpreted as a minimum set of information required/needed
in a document, any additional information regarding the specific
extension should also be included in the document. These criteria
are not officially part of the IETF guidelines regarding RFC/Internet
Drafts, but should be considered as guidance to promote uniformity to
working group documents.
Since the addition of security to the DNS protocol is now considered
A general extension to the DNS protocol, any guideline for the con-
tents of a DNS Security document could be taken as a suggestion for
the contents of any DNS extension document.
4.1 Security Related Resource Records
Documents describing a new type of DNS Security Resource Record (RR)
should contain information describing the structure and use of the
new RR type. It is a good idea to only discuss one new type in a
document, unless the set of new resource records are closely related
or a protocol extensions requires the use of more than one new record
type. Specifically: each document detailing a new Security related
RR type should include the following information:
Rose [Page 6]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
* The format of the new RR type, both "on the wire" (bit format) and
ASCII representation (for text zone files), if appropriate.
* When and in what section of a DNS query/response this new RR type
is to be included.
* At which level of the DNS hierarchy this new RR type is to be
considered authoritative (i.e. in a zone, in a zone's superzone) and
who is authoritative to sign the new RR.
4.2 Digital Signature Algorithm Implementations
Documents describing the implementation details of a specific digital
signature algorithm such as [RFC 2536, RFC 2537] for use with DNS
Security should include the following information:
* The format/encoding of the algorithm's public key for use in a
KEY Resource Record.
* The acceptable key size for use with the algorithm.
* The current known status of the algorithm (as one of REQUIRED,
RECOMMENDED, or OPTIONAL).
In addition, authors are encouraged to include any necessary descrip-
tion of the algorithm itself, as well as any know/suspected
weaknesses as an appendix to the document. This is for reference
only, as the goals of the DNSEXT working group is to propose exten-
sions to the DNS protocol, not cryptographic research.
4.3 Refinement of Security Procedures
This set of documents includes DNS protocol operations that relate to
DNS Security specifically such as DNS secret key establishment [TKEY]
and security extensions to pre-existing or proposed DNS operations
such as dynamic update [RFC2137]. Documents that describe a new set
of DNS message transactions, or seek to refine a current series of
transaction that make up a DNS operation SHOULD include the following
information:
* The order in which the DNS messages are sent by the operation ini-
tiator and target.
* The format of these DNS messages.
* Any required authentication mechanisms for each stage of the
Rose [Page 7]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
operation and the required authority for that mechanism (i.e. zone,
host, or some other trusted authority such as a DNS administrator or
certificate authority).
4.4 The Use of DNS Security Extensions with Other Protocols
Because of the flexibility and ubiquity of the DNS, there may exist
other Internet protocols and applications that could make use of, or
extend, the DNS security protocols. Examples of this type of docu-
ment include the use of DNS to support the Public Key Infrastructure
(PKI). It is beyond the scope of this roadmap to describe the con-
tents of this class of documents. However, if uses or extensions
require the addition or modification of a DNS Resource Record type or
DNS query/response transactions, then the guidelines laid out in the
previous sections of this document SHOULD be adhered too.
5. Security Considerations
This document provides a roadmap and guidelines for writing DNS Secu-
rity related documents. The reader should follow all the security
procedures and guidelines described in the DNS Security Extensions
document [RFC2535].
6. Acknowledgements
In addition to the RFCs mentioned in this document, there are also
numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may
not be able to access these documents through the RFC repositories.
For that reason, the version of the Internet drafts that were refer-
enced in this document are given below:
* SIG0: D. Eastlake. "DNS Request and Transaction Signatures
(SIG(0))" <draft-ietf-dnsext-sig-zero-02.txt>.
* TKEY: D. Eastlake. "Secret Key Establishment for DNS" <draft-
ietf-dnsext-tkey-03.txt>.
* SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". <draft-ietf-
dnsind-sigalgopt-00.txt>
* CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone
Status" <draft-ietf-dnsext-zone-status-01.txt>
* AUTH: B. Wellington. "Domain Name System Security (DNSSEC)
Signing Authority" <draft-ietf-dnsext-signing-auth-01.txt>
* CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa-
tion in the CAIRN Testbed". <draft-ietf-dnsop-dnsseccairn-00.txt>
Rose [Page 8]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
* UPDATE: X. Wang, Y. Huang, and D. Rine. "Secure Online Domain
Name System (DNS) Dynamic Update". <draft-whr-dnsext-secure-online-
update-00.txt>
* SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver
message size requirements". <draft-ietf-dnsext-message-size-00.txt>
7. References
[RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys-
tem (DNS)", RFC 2537, March 1999.
[RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997.
[RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", RFC 2539, March 1999.
[RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[RFC1591] J. Postal, "Domain Name System Structure and Delegation",
RFC 1591, March 1994.
[RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[RFC2541] D. Eastlake, "DNS Security Operational Considerations", RFC
541, March 1999.
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, and B. Wellington.
"Secret Key Transaction Authentication for DNS (TSIG)". RFC 2845,
May 2000.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC-2119, March 1997.
8. Authors' Addresses
Rose [Page 9]
INTERNET-DRAFT DNS Security Document Roadmap July 2000
Scott Rose
National Institute for Standards and Technology
Gaithersburg, MD
Email: scott.rose@nist.gov
Expiration and File Name:
This draft, titled <draft-srose-dnsext-dnssec-roadmap-00.txt> expires January 2001
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Rose [Page 10]