rfc2535.txt

RFC 的详细文档！

      zone says there is no key for that zone, it is unsecured for that
      algorithm.

   2. If, there is at least one trusted no-key zone KEY RR and one
      trusted key specifying zone KEY RR, then that zone is only
      experimentally secure for the algorithm.  Both authenticated and
      non-authenticated RRs for it should be accepted by the resolver.

   3. If every trusted zone KEY RR that the zone and algorithm has is
      key specifying, then it is secure for that algorithm and only
      authenticated RRs from it will be accepted.

   Examples:

   (1)  A resolver initially trusts only signatures by the superzone of
   zone Z within the DNS hierarchy.  Thus it will look only at the KEY
   RRs that are signed by the superzone.  If it finds only no-key KEY
   RRs, it will assume the zone is not secure.  If it finds only key
   specifying KEY RRs, it will assume the zone is secure and reject any
   unsigned responses.  If it finds both, it will assume the zone is
   experimentally secure

   (2)  A resolver trusts the superzone of zone Z (to which it got
   securely from its local zone) and a third party, cert-auth.example.
   When considering data from zone Z, it may be signed by the superzone
   of Z, by cert-auth.example, by both, or by neither.  The following
   table indicates whether zone Z will be considered secure,
   experimentally secure, or unsecured, depending on the signed zone KEY
   RRs for Z;

                      c e r t - a u t h . e x a m p l e

        KEY RRs|   None    |  NoKeys   |  Mixed   |   Keys   |
     S       --+-----------+-----------+----------+----------+
     u  None   | illegal   | unsecured | experim. | secure   |
     p       --+-----------+-----------+----------+----------+
     e  NoKeys | unsecured | unsecured | experim. | secure   |
     r       --+-----------+-----------+----------+----------+
     Z  Mixed  | experim.  | experim.  | experim. | secure   |



Eastlake                    Standards Track                    [Page 16]

RFC 2535                DNS Security Extensions               March 1999


     o       --+-----------+-----------+----------+----------+
     n  Keys   | secure    | secure    | secure   | secure   |
     e         +-----------+-----------+----------+----------+

3.5 KEY RRs in the Construction of Responses

   An explicit request for KEY RRs does not cause any special additional
   information processing except, of course, for the corresponding SIG
   RR from a security aware server (see Section 4.2).

   Security aware DNS servers include KEY RRs as additional information
   in responses, where a KEY is available, in the following cases:

   (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
   name (perhaps just a zone key) SHOULD be included as additional
   information if space is available. If not all additional information
   will fit, type A and AAAA glue RRs have higher priority than KEY
   RR(s).

   (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
   name (usually just a host RR and NOT the zone key (which usually
   would have a different name)) SHOULD be included if space is
   available.  On inclusion of A or AAAA RRs as additional information,
   the KEY RRset with the same name should also be included but with
   lower priority than the A or AAAA RRs.

4. The SIG Resource Record

   The SIG or "signature" resource record (RR) is the fundamental way
   that data is authenticated in the secure Domain Name System (DNS). As
   such it is the heart of the security provided.

   The SIG RR unforgably authenticates an RRset [RFC 2181] of a
   particular type, class, and name and binds it to a time interval and
   the signer's domain name.  This is done using cryptographic
   techniques and the signer's private key.  The signer is frequently
   the owner of the zone from which the RR originated.

   The type number for the SIG RR type is 24.

4.1 SIG RDATA Format

   The RDATA portion of a SIG RR is as shown below.  The integrity of
   the RDATA information is protected by the signature field.







Eastlake                    Standards Track                    [Page 17]

RFC 2535                DNS Security Extensions               March 1999


                           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                          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1 Type Covered Field

   The "type covered" is the type of the other RRs covered by this SIG.

4.1.2 Algorithm Number Field

   This octet is as described in section 3.2.

4.1.3 Labels Field

   The "labels" octet is an unsigned count of how many labels there are
   in the original SIG RR owner name not counting the null label for
   root and not counting any initial "*" for a wildcard.  If a secured
   retrieval is the result of wild card substitution, it is necessary
   for the resolver to use the original form of the name in verifying
   the digital signature.  This field makes it easy to determine the
   original form.

   If, on retrieval, the RR appears to have a longer name than indicated
   by "labels", the resolver can tell it is the result of wildcard
   substitution.  If the RR owner name appears to be shorter than the
   labels count, the SIG RR must be considered corrupt and ignored.  The
   maximum number of labels allowed in the current DNS is 127 but the
   entire octet is reserved and would be required should DNS names ever
   be expanded to 255 labels.  The following table gives some examples.
   The value of "labels" is at the top, the retrieved owner name on the
   left, and the table entry is the name to use in signature
   verification except that "bad" means the RR is corrupt.



Eastlake                    Standards Track                    [Page 18]

RFC 2535                DNS Security Extensions               March 1999


   labels= |  0  |   1  |    2   |      3   |      4   |
   --------+-----+------+--------+----------+----------+
          .|   . | bad  |  bad   |    bad   |    bad   |
         d.|  *. |   d. |  bad   |    bad   |    bad   |
       c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
     b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
   a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |

4.1.4 Original TTL Field

   The "original TTL" field is included in the RDATA portion to avoid
   (1) authentication problems that caching servers would otherwise
   cause by decrementing the real TTL field and (2) security problems
   that unscrupulous servers could otherwise cause by manipulating the
   real TTL field.  This original TTL is protected by the signature
   while the current TTL field is not.

   NOTE:  The "original TTL" must be restored into the covered RRs when
   the signature is verified (see Section 8).  This generaly implies
   that all RRs for a particular type, name, and class, that is, all the
   RRs in any particular RRset, must have the same TTL to start with.

4.1.5 Signature Expiration and Inception Fields

   The SIG is valid from the "signature inception" time until the
   "signature expiration" time.  Both are unsigned numbers of seconds
   since the start of 1 January 1970, GMT, ignoring leap seconds.  (See
   also Section 4.4.)  Ring arithmetic is used as for DNS SOA serial
   numbers [RFC 1982] which means that these times can never be more
   than about 68 years in the past or the future.  This means that these
   times are ambiguous modulo ~136.09 years.  However there is no
   security flaw because keys are required to be changed to new random
   keys by [RFC 2541] at least every five years.  This means that the
   probability that the same key is in use N*136.09 years later should
   be the same as the probability that a random guess will work.

   A SIG RR may have an expiration time numerically less than the
   inception time if the expiration time is near the 32 bit wrap around
   point and/or the signature is long lived.

   (To prevent misordering of network requests to update a zone
   dynamically, monotonically increasing "signature inception" times may
   be necessary.)

   A secure zone must be considered changed for SOA serial number
   purposes not only when its data is updated but also when new SIG RRs
   are inserted (ie, the zone or any part of it is re-signed).




Eastlake                    Standards Track                    [Page 19]

RFC 2535                DNS Security Extensions               March 1999


4.1.6 Key Tag Field

   The "key Tag" is a two octet quantity that is used to efficiently
   select between multiple keys which may be applicable and thus check
   that a public key about to be used for the computationally expensive
   effort to check the signature is possibly valid.  For algorithm 1
   (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
   octets of the public key modulus needed to decode the signature
   field.  That is to say, the most significant 16 of the least
   significant 24 bits of the modulus in network (big endian) order. For
   all other algorithms, including private algorithms, it is calculated
   as a simple checksum of the KEY RR as described in Appendix C.

4.1.7 Signer's Name Field

   The "signer's name" field is the domain name of the signer generating
   the SIG RR.  This is the owner name of the public KEY RR that can be
   used to verify the signature.  It is frequently the zone which
   contained the RRset being authenticated.  Which signers should be
   authorized to sign what is a significant resolver policy question as
   discussed in Section 6. The signer's name may be compressed with
   standard DNS name compression when being transmitted over the
   network.

4.1.8 Signature Field

   The actual signature portion of the SIG RR binds the other RDATA
   fields to the RRset of the "type covered" RRs with that owner name
   and class.  This covered RRset is thereby authenticated.  To
   accomplish this, a data sequence is constructed as follows:

         data = RDATA | RR(s)...

   where "|" is concatenation,

   RDATA is the wire format of all the RDATA fields in the SIG RR itself
   (including the canonical form of the signer's name) before but not
   including the signature, and

   RR(s) is the RRset of the RR(s) of the type covered with the same
   owner name and class as the SIG RR in canonical form and order as
   defined in Section 8.

   How this data sequence is processed into the signature is algorithm
   dependent.  These algorithm dependent formats and procedures are
   described in separate documents (Section 3.2).





Eastlake                    Standards Track                    [Page 20]

RFC 2535                DNS Security Extensions               March 1999


   SIGs SHOULD NOT be included in a zone for any "meta-type" such as
   ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).

4.1.8.1 Calculating Transaction and Request SIGs

   A response message from a security aware server may optionally
   contain a special SIG at the end of the additional information
   section to authenticate the transaction.

   This SIG has a "type covered" field of zero, which is not a valid RR
   type.  It is calculated by using a "data" (see Section 4.1.8) of the
   entire preceding DNS reply message, including DNS header but not the
   IP header and before the reply RR counts have been adjusted for the
   inclusion of any transaction SIG, concatenated with the entire DNS