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

bind 9.3结合mysql数据库

   for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol].

   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] that
   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 a CNAME resource record in a signed zone.

   See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone
   signer determines precisely which NSEC RRs it needs to include in a
   zone.

   The type value for the NSEC RR is 47.

   The NSEC RR is class independent.

   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
   field.  This is in the spirit of negative caching [RFC2308].

4.1  NSEC RDATA Wire Format

   The RDATA of the NSEC RR is as shown below:

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                      Next Domain Name                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Type Bit Maps                           /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.1.1  The Next Domain Name Field

   The Next Domain field contains the next owner name (in the canonical
   ordering of the zone) which has authoritative data or contains a
   delegation point NS RRset; see Section 6.1 for an explanation of
   canonical ordering.  The value of the Next Domain Name field in the



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


   last NSEC record in the zone is the name of the zone apex (the owner
   name of the zone's SOA RR).  This indicates that the owner name of
   the NSEC RR is the last name in the canonical ordering of the zone.

   A sender MUST NOT use DNS name compression on the Next Domain Name
   field when transmitting an NSEC RR.

   Owner names of RRsets not authoritative for the given zone (such as
   glue records) MUST NOT be listed in the Next Domain Name unless at
   least one authoritative RRset exists at the same owner name.

4.1.2  The Type Bit Maps Field

   The Type Bit Maps field identifies the RRset types which exist at the
   NSEC RR's owner name.

   The RR type space is split into 256 window blocks, each representing
   the low-order 8 bits of the 16-bit RR type space.  Each block that
   has at least one active RR type is encoded using a single octet
   window number (from 0 to 255), a single octet bitmap length (from 1
   to 32) indicating the number of octets used for the window block's
   bitmap, and up to 32 octets (256 bits) of bitmap.

   Blocks are present in the NSEC RR RDATA in increasing numerical
   order.

      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

      where "|" denotes concatenation.

   Each bitmap encodes the low-order 8 bits of RR types within the
   window block, in network bit order.  The first bit is bit 0.  For
   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
   to RR type 2 (NS), and so forth.  For window block 1, bit 1
   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set,
   it indicates that an RRset of that type is present for the NSEC RR's
   owner name.  If a bit is clear, it indicates that no RRset of that
   type is present for the NSEC RR's owner name.

   Bits representing pseudo-types MUST be clear, since they do not
   appear in zone data.  If encountered, they MUST be ignored upon
   reading.

   Blocks with no types present MUST NOT be included.  Trailing zero
   octets in the bitmap MUST be omitted.  The length of each block's
   bitmap is determined by the type code with the largest numerical
   value, within that block, among the set of RR types present at the
   NSEC RR's owner name.  Trailing zero octets not specified MUST be



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


   interpreted as zero octets.

   The bitmap for the NSEC RR at a delegation point requires special
   attention.  Bits corresponding to the delegation NS RRset and the RR
   types for which the parent zone has authoritative data MUST be set;
   bits corresponding to any non-NS RRset for which the parent is not
   authoritative MUST be clear.

   A zone MUST NOT include an NSEC RR for any domain name that only
   holds glue records.

4.1.3  Inclusion of Wildcard Names in NSEC RDATA

   If a wildcard owner name appears in a zone, the wildcard label ("*")
   is treated as a literal symbol and is treated the same as any other
   owner name for purposes of generating NSEC RRs.  Wildcard owner names
   appear in the Next Domain Name field without any wildcard expansion.
   [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
   on authenticated denial of existence.

4.2  The NSEC RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Next Domain Name field is represented as a domain name.

   The Type Bit Maps field is represented as a sequence of RR type
   mnemonics.  When the mnemonic is not known, the TYPE representation
   as described in [RFC3597] (section 5) MUST be used.

4.3  NSEC RR Example

   The following NSEC RR identifies the RRsets associated with
   alfa.example.com.  and identifies the next authoritative name after
   alfa.example.com.

   alfa.example.com. 86400 IN NSEC host.example.com. (
                                   A MX RRSIG NSEC TYPE1234 )

   The first four text fields specify the name, TTL, Class, and RR type
   (NSEC).  The entry host.example.com.  is the next authoritative name
   after alfa.example.com.  in canonical order.  The A, MX, RRSIG, NSEC,
   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
   TYPE1234 RRsets associated with the name alfa.example.com.

   The RDATA section of the NSEC RR above would be encoded as:





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


            0x04 'h'  'o'  's'  't'
            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
            0x03 'c'  'o'  'm'  0x00
            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x20

   Assuming that the validator can authenticate this NSEC record, it
   could be used to prove that beta.example.com does not exist, or could
   be used to prove there is no AAAA record associated with
   alfa.example.com.  Authenticated denial of existence is discussed in
   [I-D.ietf-dnsext-dnssec-protocol].





































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


5.  The DS Resource Record

   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
   Note that while the digest should be sufficient to identify the
   public key, storing the key tag and key algorithm helps make the
   identification process more efficient.  By authenticating the DS
   record, a resolver can authenticate the DNSKEY RR to which the DS
   record points.  The key authentication process is described in
   [I-D.ietf-dnsext-dnssec-protocol].

   The DS RR and its corresponding DNSKEY RR have the same owner name,
   but they are stored in different locations.  The DS RR appears only
   on the upper (parental) side of a delegation, and is authoritative
   data in the parent zone.  For example, the DS RR for "example.com" is
   stored in the "com" zone (the parent zone) rather than in the
   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
   stored in the "example.com" zone (the child zone).  This simplifies
   DNS zone management and zone signing, but introduces special response
   processing requirements for the DS RR; these are described in
   [I-D.ietf-dnsext-dnssec-protocol].

   The type number for the DS record is 43.

   The DS resource record is class independent.

   The DS RR has no special TTL requirements.

5.1  DS RDATA Wire Format

   The RDATA for a DS RR consists of a 2 octet Key Tag field, a one
   octet Algorithm field, a one octet Digest Type field, and a Digest
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Key Tag             |  Algorithm    |  Digest Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Digest                             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







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


5.1.1  The Key Tag Field

   The Key Tag field lists the key tag of the DNSKEY RR referred to by
   the DS record, in network byte order.

   The Key Tag used by the DS RR is identical to the Key Tag used by
   RRSIG RRs.  Appendix B describes how to compute a Key Tag.

5.1.2  The Algorithm Field

   The Algorithm field lists the algorithm number of the DNSKEY RR
   referred to by the DS record.

   The algorithm number used by the DS RR is identical to the algorithm
   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
   algorithm number types.

5.1.3  The Digest Type Field

   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
   RR.  The Digest Type field identifies the algorithm used to construct
   the digest.  Appendix A.2 lists the possible digest algorithm types.

5.1.4  The Digest Field

   The DS record refers to a DNSKEY RR by including a digest of that
   DNSKEY RR.

   The digest is calculated by concatenating the canonical form of the
   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
   and then applying the digest algorithm.

     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

      "|" denotes concatenation

     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.


   The size of the digest may vary depending on the digest algorithm and
   DNSKEY RR size.  As of the time of writing, the only defined digest
   algorithm is SHA-1, which produces a 20 octet digest.

5.2  Processing of DS RRs When Validating Responses

   The DS RR links the authentication chain across zone boundaries, so
   the DS RR requires extra care in processing.  The DNSKEY RR referred
   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST



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


   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
   zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in
   the validation process.

5.3  The DS RR Presentation Format

   The presentation format of the RDATA portion is as follows:

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

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

   The Digest Type field MUST be represented as an unsigned decimal
   integer.

   The Digest MUST be represented as a sequence of case-insensitive
   hexadecimal digits.  Whitespace is allowed within the hexadecimal
   text.

5.4  DS RR Example

   The following example shows a DNSKEY RR and its corresponding DS RR.

   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                             fwJr1AYtsmx3TGkJaNXVbfi/
                                             2pHm822aJ5iI9BMzNXxeYCmZ
                                             DRD99WYwYqUSdjMmmAphXdvx
                                             egXd/M5+X7OrzKBaMbCVdFLU
                                             Uh6DhweJBjEVv5f2wwjM9Xzc
                                             nOf+EPbtG9DMBmADjFDc2w/r
                                             ljwvFw==
                                             ) ;  key id = 60485

   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )


   The first four text fields specify the name, TTL, Class, and RR type
   (DS).  Value 60485 is the key tag for the corresponding
   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
   algorithm used to construct the digest, and the rest of the RDATA