draft-ietf-dnsext-dnssec-records-03.txt

bind-3.2.

DNS Extensions                                                 R. Arends
Internet-Draft                                      Telematica Instituut
Expires: August 26, 2003                                      R. Austein
                                                                     ISC
                                                               M. Larson
                                                                VeriSign
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                       February 25, 2003


            Resource Records for the DNS Security Extensions
                  draft-ietf-dnsext-dnssec-records-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire on August 26, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document is part of a family of documents that describes the DNS
   Security Extensions (DNSSEC).  The DNS Security Extensions are a
   collection of resource records and protocol modifications that
   provide source authentication for the DNS.  This document defines the



Arends, et al.           Expires August 26, 2003                [Page 1]

Internet-Draft           DNSSEC Resource Records           February 2003


   KEY, DS, SIG, and NXT resource records.  The purpose and format of
   each resource record is described in detail and an example of each
   resource record is given.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Background and Related Documents . . . . . . . . . . . . . .  4
   1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3   Editors Notes  . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.1 Open Technical Issues  . . . . . . . . . . . . . . . . . . .  4
   1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . .  4
   1.3.3 Typos and Minor Corrections  . . . . . . . . . . . . . . . .  5
   2.    The KEY Resource Record  . . . . . . . . . . . . . . . . . .  6
   2.1   KEY RDATA Wire Format  . . . . . . . . . . . . . . . . . . .  6
   2.1.1 The Flags Field  . . . . . . . . . . . . . . . . . . . . . .  6
   2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . .  7
   2.1.3 The Algorithm Field  . . . . . . . . . . . . . . . . . . . .  7
   2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . .  7
   2.1.5 Notes on KEY RDATA Design  . . . . . . . . . . . . . . . . .  7
   2.2   The KEY RR Presentation Format . . . . . . . . . . . . . . .  7
   2.3   KEY RR Example . . . . . . . . . . . . . . . . . . . . . . .  7
   3.    The SIG Resource Record  . . . . . . . . . . . . . . . . . .  9
   3.1   SIG RDATA Wire Format  . . . . . . . . . . . . . . . . . . .  9
   3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10
   3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10
   3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10
   3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11
   3.1.5 Signature Expiration and Inception Fields  . . . . . . . . . 11
   3.1.6 The Key Tag Field  . . . . . . . . . . . . . . . . . . . . . 11
   3.1.7 The Signer's Name Field  . . . . . . . . . . . . . . . . . . 11
   3.1.8 The Signature Field  . . . . . . . . . . . . . . . . . . . . 12
   3.2   The SIG RR Presentation Format . . . . . . . . . . . . . . . 12
   3.3   SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13
   4.    The NXT Resource Record  . . . . . . . . . . . . . . . . . . 15
   4.1   NXT RDATA Wire Format  . . . . . . . . . . . . . . . . . . . 15
   4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15
   4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15
   4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16
   4.2   The NXT RR Presentation Format . . . . . . . . . . . . . . . 16
   4.3   NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16
   5.    The DS Resource Record . . . . . . . . . . . . . . . . . . . 18
   5.1   DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18
   5.1.1 The Key Tag Field  . . . . . . . . . . . . . . . . . . . . . 18
   5.1.2 The Algorithm Field  . . . . . . . . . . . . . . . . . . . . 19
   5.1.3 The Digest Type Field  . . . . . . . . . . . . . . . . . . . 19
   5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19
   5.2   The DS RR Presentation Format  . . . . . . . . . . . . . . . 19



Arends, et al.           Expires August 26, 2003                [Page 2]

Internet-Draft           DNSSEC Resource Records           February 2003


   5.3   DS RR Example  . . . . . . . . . . . . . . . . . . . . . . . 20
   6.    Canonical Form and Order of Resource Records . . . . . . . . 21
   6.1   Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21
   6.2   Canonical RR Form  . . . . . . . . . . . . . . . . . . . . . 21
   6.3   Canonical RR Ordering Within An RRset  . . . . . . . . . . . 22
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 23
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 24
   9.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 25
         Normative References . . . . . . . . . . . . . . . . . . . . 26
         Informative References . . . . . . . . . . . . . . . . . . . 27
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
   A.    DNSSEC Algorithm and Digest Types  . . . . . . . . . . . . . 29
   A.1   DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29
   A.1.1 Private Algorithm Types  . . . . . . . . . . . . . . . . . . 29
   A.2   DNSSEC Digest Types  . . . . . . . . . . . . . . . . . . . . 30
   B.    Key Tag Calculation  . . . . . . . . . . . . . . . . . . . . 31
   B.1   Key Tag for Algorithm 1 (RSA/MD5)  . . . . . . . . . . . . . 32
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 33

































Arends, et al.           Expires August 26, 2003                [Page 3]

Internet-Draft           DNSSEC Resource Records           February 2003


1. Introduction

   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
   record types: KEY, SIG, NXT, and DS.  This document defines the
   purpose of each resource record (RR), the RR's RDATA format, and its
   ASCII representation.

1.1 Background and Related Documents

   The reader is assumed to be familiar with the basic DNS concepts
   described in RFC1034 [1] and RFC1035 [2].

   This document is part of a family of documents that define the DNS
   security extensions.  The DNS security extensions (DNSSEC) are a
   collection of resource records and DNS protocol modifications that
   add source authentication the Domain Name System (DNS).  An
   introduction to DNSSEC and definition of common terms can be found in
   [10].  A description of DNS protocol modifications can be found in
   [11].  This document defines the DNSSEC resource records.

1.2 Reserved Words

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

1.3 Editors Notes

1.3.1 Open Technical Issues

   The NXT section (Section 4) may be updated in the next version if
   DNSSEC-Opt-In [13] becomes part of DNSSEC.

   The cryptographic algorithm types (Appendix A) requires input from
   the working group.  The DSA algorithm was moved to OPTIONAL.  This
   had strong consensus in workshops and various discussions and a
   separate internet draft solely to move DSA from MANDATORY to OPTIONAL
   seemed excessive.  This draft solicits input on that proposed change.

1.3.2 Technical Changes or Corrections

   Please report technical corrections to [e-mail].
   To assist the editors, please indicate the text in error and point
   out the RFC that defines the correct behavior.  For a technical
   change where no RFC that defines the correct behavior, or if there's
   more than one applicable RFC and the definitions conflict, please
   post the issue to namedroppers.




Arends, et al.           Expires August 26, 2003                [Page 4]

Internet-Draft           DNSSEC Resource Records           February 2003


   An example correction to dnssec-editors might be: Page X says
   "DNSSEC RRs SHOULD be automatically returned in responses."  This was
   true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
   DNSSEC RR types MUST NOT be included in responses unless the resolver
   indicated support for DNSSEC.

1.3.3 Typos and Minor Corrections

   Please report any typos corrections to [e-mail].
   To assist the editors, please provide enough context for us to find
   the incorrect text quickly.

   An example message to dnssec-editors might be: page X says "the
   DNSSEC standard has been in development for over 1 years".   It
   should read "over 10 years".




































Arends, et al.           Expires August 26, 2003                [Page 5]

Internet-Draft           DNSSEC Resource Records           February 2003


2. The KEY Resource Record

   DNSSEC uses public key cryptography to sign and authenticate DNS
   resource record sets (RRsets).  The public keys are stored in KEY
   resource records and are used in the DNSSEC authentication process
   described in [11].  In a typical example, a zone signs its
   authoritative RRsets using a private key and stores the corresponding
   public key in a KEY RR.  A resolver can then use these signatures to
   authenticate RRsets from the zone.

   The KEY RR may also be used to store public keys associated with
   other DNS operations such as TKEY [15].  In all cases, the KEY RR
   plays a special role in secure DNS resolution and DNS message
   processing.  The KEY RR is not intended as a record for storing
   arbitrary public keys.  The KEY RR MUST NOT be used to store
   certificates or public keys that do not directly relate to the DNS
   infrastructure.  Examples of certificates and public keys that MUST
   NOT be stored in the KEY RR include X.509 certificates, IPSEC public
   keys, and SSH public keys.

   The Type value for the KEY RR type is 25.

   The KEY RR is class independent.

   There are no special TTL requirements on the KEY record.

2.1 KEY RDATA Wire Format

   The RDATA for a KEY RR consists of a 2 octet Flags Field, a 1 octet
   Protocol Field, a 1 octet Algorithm Field , and the Public Key Field.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Flags            |    Protocol   |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Public Key                         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.1.1 The Flags Field

   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
   then the KEY record holds a DNS zone key and the KEY's owner name
   MUST be the name of a zone.  If bit 7 has value 0, then the KEY
   record holds some other type of DNS public key, such as a public key



Arends, et al.           Expires August 26, 2003                [Page 6]

Internet-Draft           DNSSEC Resource Records           February 2003


   used by TKEY.

   Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of
   the KEY RR, and MUST be ignored upon reception.

   Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this
   by allocating bit 15 as the KSK bit.

2.1.2 The Protocol Field

   The Protocol Field MUST have value 3.

2.1.3 The Algorithm Field

   The Algorithm field identifies the public key's cryptographic
   algorithm and determines the format of the Public Key field.  A list
   of DNSSEC algorithm types can be found in Appendix A.1

2.1.4 The Public Key Field

   The Public Key Field holds the public key material.

2.1.5 Notes on KEY RDATA Design

   Although the Protocol Field always has value 3, it is retained for
   backward compatibility with an earlier version of the KEY record.

2.2 The KEY RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Flag field is represented as an unsigned decimal integer with a
   value of either 0 or 256.

   The Protocol Field is represented as an unsigned decimal integer with
   a value of 3.

   The Algorithm field is represented either as an unsigned decimal
   integer or as an algorithm mnemonic as specified in Appendix A.1.

   The Public Key field is represented as a Base64 encoding of the
   Public Key.  Whitespace is allowed within the Base64 text.  For a
   definition of Base64 encoding, see [3] Section 5.2.

2.3 KEY RR Example

   The following KEY RR stores a DNS zone key for example.com.




Arends, et al.           Expires August 26, 2003                [Page 7]

Internet-Draft           DNSSEC Resource Records           February 2003


   example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl
                                       +BBZH4b/0PY1kxkmvHjcZc8nokfzj31
                                       GajIQKY+5CptLr3buXA10hWqTkF7H6R
                                       foRqXQeogmMHfpftf6zMv1LyBUgia7z
                                       a6ZEzOJBOztyvhjL742iU/TpPSEDhm2
                                       SNKLijfUppn1UaNvv4w==   )

   The first four text fields specify the owner name, TTL, Class, and RR
   type (KEY).  Value 256 indicates that the Zone Key bit (bit 7) in the
   Flags field has value 1.  Value 3 is the fixed Protocol value.  Value
   5 indicates the public key algorithm.  Appendix A.1 identifies
   algorithm type 5 as RSA/SHA1 and indicates that the format of the
   RSA/SHA1 public key field is defined in [8].  The remaining text is a
   base 64 encoding of the public key.





































Arends, et al.           Expires August 26, 2003                [Page 8]

Internet-Draft           DNSSEC Resource Records           February 2003


3. The SIG Resource Record

   DNSSEC uses public key cryptography to sign and authenticate DNS
   resource record sets (RRsets).  Signatures are stored in SIG resource
   records and are used in the DNSSEC authentication process described
   in [11].  In a typical example, a zone signs its authoritative RRsets
   using a private key and stores the corresponding signatures in SIG
   RRs.  A resolver can then use these SIG RRs to authenticate RRsets
   from the zone.

   A SIG record contains the signature for an RRset with a particular
   name, class, and type.  The SIG RR specifies a validity interval for