rfc4034.txt

非常好的dns解析软件

   Because every authoritative RRset in a zone must be protected by a
   digital signature, RRSIG RRs must be present for names containing a
   CNAME RR.  This is a change to the traditional DNS specification
   [RFC1034], which stated that if a CNAME is present for a name, it is
   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
   MUST exist for the same name as a CNAME resource record in a signed
   zone.




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


   The Type value for the RRSIG RR type is 46.

   The RRSIG RR is class independent.

   An RRSIG RR MUST have the same class as the RRset it covers.

   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
   covers.  This is an exception to the [RFC2181] rules for TTL values
   of individual RRs within a RRset: individual RRSIG RRs with the same
   owner name will have different TTL values if the RRsets they cover
   have different TTL values.

3.1.  RRSIG RDATA Wire Format

   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
   Inception field, a 2 octet Key tag, the Signer's Name field, and the
   Signature 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type Covered           |  Algorithm    |     Labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Inception                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Key Tag            |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Signature                          /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1.  The Type Covered Field

   The Type Covered field identifies the type of the RRset that is
   covered by this RRSIG record.







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


3.1.2.  The Algorithm Number Field

   The Algorithm Number field identifies the cryptographic algorithm
   used to create the signature.  A list of DNSSEC algorithm types can
   be found in Appendix A.1

3.1.3.  The Labels Field

   The Labels field specifies the number of labels in the original RRSIG
   RR owner name.  The significance of this field is that a validator
   uses it to determine whether the answer was synthesized from a
   wildcard.  If so, it can be used to determine what owner name was
   used in generating the signature.

   To validate a signature, the validator needs the original owner name
   that was used to create the signature.  If the original owner name
   contains a wildcard label ("*"), the owner name may have been
   expanded by the server during the response process, in which case the
   validator will have to reconstruct the original owner name in order
   to validate the signature.  [RFC4035] describes how to use the Labels
   field to reconstruct the original owner name.

   The value of the Labels field MUST NOT count either the null (root)
   label that terminates the owner name or the wildcard label (if
   present).  The value of the Labels field MUST be less than or equal
   to the number of labels in the RRSIG owner name.  For example,
   "www.example.com." has a Labels field value of 3, and
   "*.example.com." has a Labels field value of 2.  Root (".") has a
   Labels field value of 0.

   Although the wildcard label is not included in the count stored in
   the Labels field of the RRSIG RR, the wildcard label is part of the
   RRset's owner name when the signature is generated or verified.

3.1.4.  Original TTL Field

   The Original TTL field specifies the TTL of the covered RRset as it
   appears in the authoritative zone.

   The Original TTL field is necessary because a caching resolver
   decrements the TTL value of a cached RRset.  In order to validate a
   signature, a validator requires the original TTL.  [RFC4035]
   describes how to use the Original TTL field value to reconstruct the
   original TTL.







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


3.1.5.  Signature Expiration and Inception Fields

   The Signature Expiration and Inception fields specify a validity
   period for the signature.  The RRSIG record MUST NOT be used for
   authentication prior to the inception date and MUST NOT be used for
   authentication after the expiration date.

   The Signature Expiration and Inception field values specify a date
   and time in the form of a 32-bit unsigned number of seconds elapsed
   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
   byte order.  The longest interval that can be expressed by this
   format without wrapping is approximately 136 years.  An RRSIG RR can
   have an Expiration field value that is numerically smaller than the
   Inception field value if the expiration field value is near the
   32-bit wrap-around point or if the signature is long lived.  Because
   of this, all comparisons involving these fields MUST use "Serial
   number arithmetic", as defined in [RFC1982].  As a direct
   consequence, the values contained in these fields cannot refer to
   dates more than 68 years in either the past or the future.

3.1.6.  The Key Tag Field

   The Key Tag field contains the key tag value of the DNSKEY RR that
   validates this signature, in network byte order.  Appendix B explains
   how to calculate Key Tag values.

3.1.7.  The Signer's Name Field

   The Signer's Name field value identifies the owner name of the DNSKEY
   RR that a validator is supposed to use to validate this signature.
   The Signer's Name field MUST contain the name of the zone of the
   covered RRset.  A sender MUST NOT use DNS name compression on the
   Signer's Name field when transmitting a RRSIG RR.

3.1.8.  The Signature Field

   The Signature field contains the cryptographic signature that covers
   the RRSIG RDATA (excluding the Signature field) and the RRset
   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
   Covered field.  The format of this field depends on the algorithm in
   use, and these formats are described in separate companion documents.

3.1.8.1.  Signature Calculation

   A signature covers the RRSIG RDATA (excluding the Signature Field)
   and covers the data RRset specified by the RRSIG owner name, RRSIG
   class, and RRSIG Type Covered fields.  The RRset is in canonical form
   (see Section 6), and the set RR(1),...RR(n) is signed as follows:



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


         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where

            "|" denotes concatenation;

            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
               with the Signer's Name field in canonical form and
               the Signature field excluded;

            RR(i) = owner | type | class | TTL | RDATA length | RDATA

               "owner" is the fully qualified owner name of the RRset in
               canonical form (for RRs with wildcard owner names, the
               wildcard label is included in the owner name);

               Each RR MUST have the same owner name as the RRSIG RR;

               Each RR MUST have the same class as the RRSIG RR;

               Each RR in the RRset MUST have the RR type listed in the
               RRSIG RR's Type Covered field;

               Each RR in the RRset MUST have the TTL listed in the
               RRSIG Original TTL Field;

               Any DNS names in the RDATA field of each RR MUST be in
               canonical form; and

               The RRset MUST be sorted in canonical order.

   See Sections 6.2 and 6.3 for details on canonical form and ordering
   of RRsets.

3.2.  The RRSIG RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Type Covered field is represented as an RR type mnemonic.  When
   the mnemonic is not known, the TYPE representation as described in
   [RFC3597], Section 5, MUST be used.

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

   The Labels field value MUST be represented as an unsigned decimal
   integer.





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


   The Original TTL field value MUST be represented as an unsigned
   decimal integer.

   The Signature Expiration Time and Inception Time field values MUST be
   represented either as an unsigned decimal integer indicating seconds
   since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
   UTC, where:

      YYYY is the year (0001-9999, but see Section 3.1.5);
      MM is the month number (01-12);
      DD is the day of the month (01-31);
      HH is the hour, in 24 hour notation (00-23);
      mm is the minute (00-59); and
      SS is the second (00-59).

   Note that it is always possible to distinguish between these two
   formats because the YYYYMMDDHHmmSS format will always be exactly 14
   digits, while the decimal representation of a 32-bit unsigned integer
   can never be longer than 10 digits.

   The Key Tag field MUST be represented as an unsigned decimal integer.

   The Signer's Name field value MUST be represented as a domain name.

   The Signature field is represented as a Base64 encoding of the
   signature.  Whitespace is allowed within the Base64 text.  See
   Section 2.2.

3.3.  RRSIG RR Example

   The following RRSIG RR stores the signature for the A RRset of
   host.example.com:

   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642 example.com.
                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

   The first four fields specify the owner name, TTL, Class, and RR type
   (RRSIG).  The "A" represents the Type Covered field.  The value 5
   identifies the algorithm used (RSA/SHA1) to create the signature.
   The value 3 is the number of Labels in the original owner name.  The
   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
   RRset.  20030322173103 and 20030220173103 are the expiration and




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


   inception dates, respectively.  2642 is the Key Tag, and example.com.
   is the Signer's Name.  The remaining text is a Base64 encoding of the
   signature.

   Note that combination of RRSIG RR owner name, class, and Type Covered
   indicates that this RRSIG covers the "host.example.com" A RRset.  The
   Label value of 3 indicates that no wildcard expansion was used.  The
   Algorithm, Signer's Name, and Key Tag indicate that this signature
   can be authenticated using an example.com zone DNSKEY RR whose
   algorithm is 5 and whose key tag is 2642.

4.  The NSEC Resource Record

   The NSEC resource record lists two separate things: the next owner
   name (in the canonical ordering of the zone) that contains
   authoritative data or a delegation point NS RRset, and the set of RR
   types present at the NSEC RR's owner name [RFC3845].  The complete
   set of NSEC RRs in a zone indicates which authoritative RRsets exist
   in a zone and also form a chain of authoritative owner names in the
   zone.  This information is used to provide authenticated denial of
   existence for DNS data, as described in [RFC4035].

   Because every authoritative name in a zone must be part of the NSEC
   chain, NSEC RRs must be present for names containing a CNAME RR.
   This is a change to the traditional DNS specification [RFC1034],
   which stated that if a CNAME is present for a name, it is the only
   type allowed at that name.  An RRSIG (see Section 3) and NSEC MUST
   exist for the same name as does a CNAME resource record in a signed
   zone.