rfc4034.txt

非常好的dns解析软件

   See [RFC4035] for discussion of how a zone signer determines
   precisely which NSEC RRs it has 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]).












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


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) that 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
   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 for which the given zone is not authoritative
   (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 that 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.



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


   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, and 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, as they do not appear
   in zone data.  If encountered, they MUST be ignored upon being read.

   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
   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 the purposes of generating NSEC RRs.  Wildcard owner
   names appear in the Next Domain Name field without any wildcard
   expansion.  [RFC4035] 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
   described in [RFC3597], Section 5, MUST be used.





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


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 that 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:

            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 to
   prove that there is no AAAA record associated with alfa.example.com.
   Authenticated denial of existence is discussed in [RFC4035].

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

   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



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


   "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
   [RFC4035].

   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 1 octet
   Algorithm field, a 1 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                             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.








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


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 this 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
   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
   zone key, the DS RR (and the 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.






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


   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 )