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

bind 9.3结合mysql数据库

DNS Extensions                                                 R. Arends
Internet-Draft                                      Telematica Instituut
Expires: January 13, 2005                                     R. Austein
                                                                     ISC
                                                               M. Larson
                                                                VeriSign
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                           July 15, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 January 13, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  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



Arends, et al.          Expires January 13, 2005                [Page 1]

Internet-Draft          DNSSEC Resource Records                July 2004


   collection of resource records and protocol modifications that
   provide source authentication for the DNS.  This document defines the
   public key (DNSKEY), delegation signer (DS), resource record digital
   signature (RRSIG), and authenticated denial of existence (NSEC)
   resource records.  The purpose and format of each resource record is
   described in detail, and an example of each resource record is given.

   This document obsoletes RFC 2535 and incorporates changes from all
   updates to RFC 2535.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Background and Related Documents . . . . . . . . . . . . .  4
     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . . .  5
     2.1   DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . .  5
       2.1.1   The Flags Field  . . . . . . . . . . . . . . . . . . .  5
       2.1.2   The Protocol Field . . . . . . . . . . . . . . . . . .  6
       2.1.3   The Algorithm Field  . . . . . . . . . . . . . . . . .  6
       2.1.4   The Public Key Field . . . . . . . . . . . . . . . . .  6
       2.1.5   Notes on DNSKEY RDATA Design . . . . . . . . . . . . .  6
     2.2   The DNSKEY RR Presentation Format  . . . . . . . . . . . .  6
     2.3   DNSKEY RR Example  . . . . . . . . . . . . . . . . . . . .  7
   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . . .  8
     3.1   RRSIG RDATA Wire Format  . . . . . . . . . . . . . . . . .  8
       3.1.1   The Type Covered Field . . . . . . . . . . . . . . . .  9
       3.1.2   The Algorithm Number Field . . . . . . . . . . . . . .  9
       3.1.3   The Labels Field . . . . . . . . . . . . . . . . . . .  9
       3.1.4   Original TTL Field . . . . . . . . . . . . . . . . . . 10
       3.1.5   Signature Expiration and Inception Fields  . . . . . . 10
       3.1.6   The Key Tag Field  . . . . . . . . . . . . . . . . . . 10
       3.1.7   The Signer's Name Field  . . . . . . . . . . . . . . . 11
       3.1.8   The Signature Field  . . . . . . . . . . . . . . . . . 11
     3.2   The RRSIG RR Presentation Format . . . . . . . . . . . . . 12
     3.3   RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12
   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14
     4.1   NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14
       4.1.1   The Next Domain Name Field . . . . . . . . . . . . . . 14
       4.1.2   The Type Bit Maps Field  . . . . . . . . . . . . . . . 15
       4.1.3   Inclusion of Wildcard Names in NSEC RDATA  . . . . . . 16
     4.2   The NSEC RR Presentation Format  . . . . . . . . . . . . . 16
     4.3   NSEC RR Example  . . . . . . . . . . . . . . . . . . . . . 16
   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18
     5.1   DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
       5.1.1   The Key Tag Field  . . . . . . . . . . . . . . . . . . 19
       5.1.2   The Algorithm Field  . . . . . . . . . . . . . . . . . 19
       5.1.3   The Digest Type Field  . . . . . . . . . . . . . . . . 19



Arends, et al.          Expires January 13, 2005                [Page 2]

Internet-Draft          DNSSEC Resource Records                July 2004


       5.1.4   The Digest Field . . . . . . . . . . . . . . . . . . . 19
     5.2   Processing of DS RRs When Validating Responses . . . . . . 19
     5.3   The DS RR Presentation Format  . . . . . . . . . . . . . . 20
     5.4   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
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 26
   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 26
   10.2  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
       Intellectual Property and Copyright Statements . . . . . . . . 33





























Arends, et al.          Expires January 13, 2005                [Page 3]

Internet-Draft          DNSSEC Resource Records                July 2004


1.  Introduction

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

1.1  Background and Related Documents

   The reader is assumed to be familiar with the basic DNS concepts
   described in [RFC1034], [RFC1035] and subsequent RFCs that update
   them:  [RFC2136], [RFC2181] and [RFC2308].

   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 and data integrity to the Domain Name
   System (DNS).  An introduction to DNSSEC and definitions of common
   terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is
   assumed to be familiar with this document.  A description of DNS
   protocol modifications can be found in
   [I-D.ietf-dnsext-dnssec-protocol].

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





















Arends, et al.          Expires January 13, 2005                [Page 4]

Internet-Draft          DNSSEC Resource Records                July 2004


2.  The DNSKEY Resource Record

   DNSSEC uses public key cryptography to sign and authenticate DNS
   resource record sets (RRsets).  The public keys are stored in DNSKEY
   resource records and are used in the DNSSEC authentication process
   described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
   authoritative RRsets using a private key and stores the corresponding
   public key in a DNSKEY RR.  A resolver can then use the public key to
   authenticate signatures covering the RRsets in the zone.

   The DNSKEY RR is not intended as a record for storing arbitrary
   public keys and MUST NOT be used to store certificates or public keys
   that do not directly relate to the DNS infrastructure.

   The Type value for the DNSKEY RR type is 48.

   The DNSKEY RR is class independent.

   The DNSKEY RR has no special TTL requirements.

2.1  DNSKEY RDATA Wire Format

   The RDATA for a DNSKEY 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 DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
   name MUST be the name of a zone.  If bit 7 has value 0, then the
   DNSKEY record holds some other type of DNS public key and MUST NOT be
   used to verify RRSIGs that cover RRsets.

   Bit 15 of the Flags field is the Secure Entry Point flag, described
   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
   key intended for use as a secure entry point.  This flag is only



Arends, et al.          Expires January 13, 2005                [Page 5]

Internet-Draft          DNSSEC Resource Records                July 2004


   intended to be to a hint to zone signing or debugging software as to
   the intended use of this DNSKEY record; validators MUST NOT alter
   their behavior during the signature validation process in any way
   based on the setting of this bit.  This also means a DNSKEY RR with
   the SEP bit set would also need the Zone Key flag set in order to
   legally be able to generate signatures.  A DNSKEY RR with the SEP set
   and the Zone Key flag not set MUST NOT be used to verify RRSIGs that
   cover RRsets.

   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
   creation of the DNSKEY RR, and MUST be ignored upon reception.

2.1.2  The Protocol Field

   The Protocol Field MUST have value 3 and the DNSKEY RR MUST be
   treated as invalid during signature verification if found to be some
   value other than 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.  The format
   depends on the algorithm of the key being stored and are described in
   separate documents.

2.1.5  Notes on DNSKEY RDATA Design

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

2.2  The DNSKEY RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Flag field MUST be represented as an unsigned decimal integer.
   Given the currently defined flags, the possible values are: 0, 256,
   or 257.

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

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



Arends, et al.          Expires January 13, 2005                [Page 6]

Internet-Draft          DNSSEC Resource Records                July 2004


   The Public Key field MUST be represented as a Base64 encoding of the
   Public Key.  Whitespace is allowed within the Base64 text.  For a
   definition of Base64 encoding, see [RFC3548].

2.3  DNSKEY RR Example

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

   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                          kfzj31GajIQKY+5CptLr3buXA10h
                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                          742iU/TpPSEDhm2SNKLijfUppn1U
                                          aNvv4w==  )

   The first four text fields specify the owner name, TTL, Class, and RR
   type (DNSKEY).  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 [RFC3110].  The remaining
   text is a Base64 encoding of the public key.