[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-srose-dnsext-dnssec-roadmap) 00 01 02 03 04 05 06 07

DNEXT Working Group                                             S. Rose
Internet Draft                                                     NIST
Expires: May 2001                                         November 2001
Category: Informational

                     DNS Security Document Roadmap

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

   The list of Internet-Draft Shadow Directories can be accessed at


   DNS Security (DNSSEC)technology is composed 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 find in which document and author guidelines for
   what to include in new DNS Security documents, or revisions to
   existing documents, is described.

Rose                                                            [Page 1]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

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         November 2001

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 they do 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",
   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         November 2001

   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, |          |  [SSH-DNS]  |
      |  RFC2931,  |                |  RFC3007, |          +-------------+
      |  DSIG]     |          |  RFC3008, |
      +------------+          |  RFC3090, |
                              |  SIZE,    |
                              |  OKBIT,   |
                              |  ADBIT,   |
                              |  OPTIN,   |
                              |  PARSIG,  |
                                      |    PARKEY,  |
                                      |  LIMIT ]  |
             |                      |                      *
             |                      |                      *
       +------------+       +---------------+      +-*-*-*-*-*-*-*-*-+
       |  DS        |       |               |      | Implementation  |
       |  Algorithm |       |  Transactions |      * Notes           *
       |  Impl.     |       |               |      |                 |
       | [RFC2536,  |       |  [RFC2845,    |      *  [CAIRN,        *
       |  RFC2537   |       |   RFC2930,    |      |   ROLLOVER,     |
       |  RFC2539   |       |   RENEW ]     |      *   RESROLLOVER ] *
       |  GSS-TSIG, |       |               |      +-*-*-*-*-*-*-*-*-+
       |  RFC3110,  |       +---------------+
       |  ECC, DH ] |

Rose                                                            [Page 4]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

                     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 signa-
   ture algorithms with DNSSEC, and documents further refining the tran-
   saction of messages.  It is expected that RFC 2535 will be obsoleted
   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 guide-
   lines of RFC/Internet Draft author guidelines).  Also, the portions
   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], [RFC3007], [RFC3008], [RFC3090] and
   their derivative documents.

   The "New Security RRs" set refers to the group of documents that seek
   to add additional Resource Records to the set of base DNS Record
   types.  These new records can be related to securing the DNS protocol
   [RFC2535], [RFC2931], 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], [RFC2539] and

   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 [RFC2930], 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 storage and distribution of certificates and indi-
   vidual user public keys (PGP, e-mail, etc.)  Some documents in this

Rose                                                            [Page 5]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

   group may fall beyond the DNSEXT WG scope, but they are included
   because of their use of the security extensions.  The documents in
   this group should not propose any changes to the DNS protocol to sup-
   port other protocols; only how existing DNS security records and
   transactions can be used to support other protocols.  One such docu-
   ment is [SSH-DNS] which deals with storing SSH keys in the DNS using
   the security records.

   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 are
   three Internet Drafts that fall under this category: the report on
   the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
   [ROLLOVER] and the draft on resolver configured key rollover [RES-
   ROLLOVER].  These documents were submitted through the DNSOP Working
   Group, however the main concern of these documents is the implementa-
   tion and limitations of the DNS security extensions, hence their
   interest to the DNS security community.  The CAIRN draft deals with
   the implementation of a secure DNS, and the draft on key rollover
   deals with updating DNS keys in a secure fashion.  Authors of docu-
   ments that deal with the implementation and operational 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.  These criteria

Rose                                                            [Page 6]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

   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 extension 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:

   *  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,

Rose                                                            [Page 7]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

   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 specifi-
   cally relate to DNS Security, such as DNS secret key establishment
   [TKEY] and security extensions to pre-existing or proposed DNS opera-
   tions such as dynamic update [RFC2137].  Documents that describe a
   new set of DNS message transactions, or seek to refine a current
   series of transactions 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
   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 to.

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].

Rose                                                            [Page 8]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

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.
   All of these documents are "Work in Progress" and are subject to
   change, therefore a version number is not supplied for the current

   *   SIGALG:  R. Austein, P. Vixie.  "DNS SIGALGOPT".  <draft-ietf-
   *   CAIRN:  D. Massey, T. Lehman, and E. Lewis.  "DNSSEC Implementa-
   tion in the CAIRN Testbed".  <draft-ietf-dnsop-dnsseccairn-NN.txt>
   *   UPDATE: B. Wellington.  "Secure Domain Name System (DNS) Dynamic
   Update".  <draft-ietf-simple-secure-update-NN.txt>
   *   SIZE:  O. Gudmundsson.  "DNSSEC and IPv6 A6 aware server/resolver
   message size requirements". <draft-ietf-dnsext-message-size-NN.txt>
   *   GSS-TSIG:  S. Kwan, P. Garg, J. Gilroy, and L. Esibov.  "GSS
   Algorithm for TSIG (GSS-TSIG)".  <draft-ietf-dnsext-gss-tsig-NN.txt>
   *   OKBIT: D. Conrad.  "Indicting Resolver Support of DNSSEC".
   *   ROLLOVER:  M. Andrews, D. Eastlake.  "Domain Name System (DNS)
   Security Key Rollover" <draft-ietf-dnsopt-rollover-NN.txt>.
   *   ADBIT:  B. Wellington.  "Redefinition of DNS AD bit"  <draft-
   *   OPTIN:  M. Kosters.  "DNSSEC Opt-in for Large Zones"  <draft-
   *   SSH-DNS:  W. Griffin.  "Storing SSH Host Keys in DNS"  <draft-
   *   PARKEY:  R. Geiben, T. Lindgreen.  "Parent stores the child's
   zone KEYs" <draft-ietf-dnsext-parent-stores-zone-keys-NN.txt>
   *   PARSIG: R. Geiben, T. Lindgreen.  "Parent's SIG over Child's KEY"
   *   DSIG:  O. Gudmundsson.  "Delegation Signer Record in Parent".
   *   RESROLLOVER: O. Kolkman, M. Gieben, R. Arends.  "Rollover of
   statically configured resolver keys". <draft-ietf-dnsop-resolver-
   *   ECC:  D. Eastlake and R. Schroeppel.  "Elliptic Curve KEYs in the
   DNS".  <draft-ietf-dnsext-ecc-key-NN.txt>
   *   RENEW:  Y. Kamite, M. Nakayama.  "TKEY Secret Key Renewal Mode".
   *   LIMIT:  D. Massey and S. Rose.  "Limiting the Scope of the KEY
   Resource Record".  <draft-ietf-dnsext-restrict-key-for-dnssec-NN.txt>
   *   DH:  D. Eastlake.  "Storage of Diffie-Hellman Keys in the Domain
   Name System (DNS)".  <draft-ietf-dnsext-rfc2539bis-dhk-NN.txt>

Rose                                                            [Page 9]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

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.

   [RFC2930] D. Eastlake,  "Secret Key Establishment for DNS" RFC 2930,
   September 2000.

   [RFC2931] D. Eastlake,  "DNS Request and Transaction Signatures
   (SIG(0))" RFC 2931, September 2000.

   [RFC3110] D. Eastlake, "RSA/SHA-1 SIGs and RSA KEYs in the Domain
   Name System (DNS)", May 2001.

   [RFC3090] E. Lewis  "DNS Security Extensions Clarification on Zone
   Status" RFC 3090, March 2001.

   [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.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
   ment Levels", RFC-2119, March 1997.

Rose                                                           [Page 10]

INTERNET-DRAFT       DNS Security Document Roadmap         November 2001

   [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
   Update".  RFC 3007, November 2000.

   [RFC3008] B. Wellington, "Domain Name System Security (DNSSEC) Sign-
   ing Authority".  RFC 3008, November 2000.

8. Author's Addresses

   Scott Rose
   National Institute for Standards and Technology
   Gaithersburg, MD
   Email: scott.rose@nist.gov

Expiration and File Name:

   This draft, titled <draft-ietf-dnsext-dnssec-roadmap-05.txt> expires May 2001.


Rose                                                           [Page 11]

INTERNET-DRAFT       DNS Security Document Roadmap         November 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

Rose                                                           [Page 12]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/