rfc4034.txt

非常好的dns解析软件

Network Working Group                                          R. Arends
Request for Comments: 4034                          Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
           3755, 3757, 3845                                          ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign
Category: Standards Track                                      D. Massey
                                               Colorado State University
                                                                 S. Rose
                                                                    NIST
                                                              March 2005


            Resource Records for the DNS Security Extensions

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document is part of a family of documents that describe 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
   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.











Arends, et al.              Standards Track                     [Page 1]

RFC 4034                DNSSEC Resource Records               March 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Background and Related Documents . . . . . . . . . . .  3
       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .  3
   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . .  4
       2.1.  DNSKEY RDATA Wire Format . . . . . . . . . . . . . . .  4
             2.1.1.  The Flags Field. . . . . . . . . . . . . . . .  4
             2.1.2.  The Protocol Field . . . . . . . . . . . . . .  5
             2.1.3.  The Algorithm Field. . . . . . . . . . . . . .  5
             2.1.4.  The Public Key Field . . . . . . . . . . . . .  5
             2.1.5.  Notes on DNSKEY RDATA Design . . . . . . . . .  5
       2.2.  The DNSKEY RR Presentation Format. . . . . . . . . . .  5
       2.3.  DNSKEY RR Example  . . . . . . . . . . . . . . . . . .  6
   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . .  6
       3.1.  RRSIG RDATA Wire Format. . . . . . . . . . . . . . . .  7
             3.1.1.  The Type Covered Field . . . . . . . . . . . .  7
             3.1.2.  The Algorithm Number Field . . . . . . . . . .  8
             3.1.3.  The Labels Field . . . . . . . . . . . . . . .  8
             3.1.4.  Original TTL Field . . . . . . . . . . . . . .  8
             3.1.5.  Signature Expiration and Inception Fields. . .  9
             3.1.6.  The Key Tag Field. . . . . . . . . . . . . . .  9
             3.1.7.  The Signer's Name Field. . . . . . . . . . . .  9
             3.1.8.  The Signature Field. . . . . . . . . . . . . .  9
       3.2.  The RRSIG RR Presentation Format . . . . . . . . . . . 10
       3.3.  RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
       4.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
             4.1.1.  The Next Domain Name Field . . . . . . . . . . 13
             4.1.2.  The Type Bit Maps Field. . . . . . . . . . . . 13
             4.1.3.  Inclusion of Wildcard Names in NSEC RDATA. . . 14
       4.2.  The NSEC RR Presentation Format. . . . . . . . . . . . 14
       4.3.  NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
       5.1.  DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
             5.1.1.  The Key Tag Field. . . . . . . . . . . . . . . 16
             5.1.2.  The Algorithm Field. . . . . . . . . . . . . . 16
             5.1.3.  The Digest Type Field. . . . . . . . . . . . . 17
             5.1.4.  The Digest Field . . . . . . . . . . . . . . . 17
       5.2.  Processing of DS RRs When Validating Responses . . . . 17
       5.3.  The DS RR Presentation Format. . . . . . . . . . . . . 17
       5.4.  DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
   6.  Canonical Form and Order of Resource Records . . . . . . . . 18
       6.1.  Canonical DNS Name Order . . . . . . . . . . . . . . . 18
       6.2.  Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
       6.3.  Canonical RR Ordering within an RRset. . . . . . . . . 20
   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . 21



Arends, et al.              Standards Track                     [Page 2]

RFC 4034                DNSSEC Resource Records               March 2005


   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
       10.1. Normative References . . . . . . . . . . . . . . . . . 22
       10.2. Informative References . . . . . . . . . . . . . . . . 23
   A.  DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
       A.1.  DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
             A.1.1.  Private Algorithm Types. . . . . . . . . . . . 25
       A.2.  DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
   B.  Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
       B.1.  Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29

1.  Introduction

   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
   record types: DNS Public Key (DNSKEY), Resource Record Signature
   (RRSIG), Next Secure (NSEC), and Delegation Signer (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

   This document is part of a family of documents defining DNSSEC, which
   should be read together as a set.

   [RFC4033] contains an introduction to DNSSEC and definition of common
   terms; the reader is assumed to be familiar with this document.
   [RFC4033] also contains a list of other documents updated by and
   obsoleted by this document set.

   [RFC4035] defines the DNSSEC protocol operations.

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

   This document defines the DNSSEC resource records.  All numeric DNS
   type codes given in this document are decimal integers.

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






Arends, et al.              Standards Track                     [Page 3]

RFC 4034                DNSSEC Resource Records               March 2005


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 [RFC4035]: A zone signs its authoritative RRsets by
   using a private key and stores the corresponding public key in a
   DNSKEY RR.  A resolver can then use the public key to validate
   signatures covering the RRsets in the zone, and thus to authenticate
   them.

   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.              Standards Track                     [Page 4]

RFC 4034                DNSSEC Resource Records               March 2005


   intended to be 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 that a DNSKEY RR with the
   SEP bit set would also need the Zone Key flag set in order to be able
   to generate signatures legally.  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 receipt.

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 it is 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 is 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,
   and 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.              Standards Track                     [Page 5]

RFC 4034                DNSSEC Resource Records               March 2005


   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.

3.  The RRSIG Resource Record

   DNSSEC uses public key cryptography to sign and authenticate DNS
   resource record sets (RRsets).  Digital signatures are stored in
   RRSIG resource records and are used in the DNSSEC authentication
   process described in [RFC4035].  A validator can use these RRSIG RRs
   to authenticate RRsets from the zone.  The RRSIG RR MUST only be used
   to carry verification material (digital signatures) used to secure
   DNS operations.

   An RRSIG record contains the signature for an RRset with a particular
   name, class, and type.  The RRSIG RR specifies a validity interval
   for the signature and uses the Algorithm, the Signer's Name, and the
   Key Tag to identify the DNSKEY RR containing the public key that a
   validator can use to verify the signature.