rfc2535.txt

RFC 的详细文档！

   query message that produced this response, including the query's DNS
   header and any request SIGs but not its IP header.  That is

      data = full response (less transaction SIG) | full query

   Verification of the transaction SIG (which is signed by the server
   host key, not the zone key) by the requesting resolver shows that the
   query and response were not tampered with in transit, that the
   response corresponds to the intended query, and that the response
   comes from the queried server.

   A DNS request may be optionally signed by including one or more SIGs
   at the end of the query. Such SIGs are identified by having a "type
   covered" field of zero. They sign the preceding DNS request message
   including DNS header but not including the IP header or any request
   SIGs at the end and before the request RR counts have been adjusted
   for the inclusions of any request SIG(s).

   WARNING: Request SIGs are unnecessary for any currently defined
   request other than update [RFC 2136, 2137] and will cause some old
   DNS servers to give an error return or ignore a query.  However, such
   SIGs may in the future be needed for other requests.

   Except where needed to authenticate an update or similar privileged
   request, servers are not required to check request SIGs.

4.2 SIG RRs in the Construction of Responses

   Security aware DNS servers SHOULD, for every authenticated RRset the
   query will return, attempt to send the available SIG RRs which
   authenticate the requested RRset.  The following rules apply to the
   inclusion of SIG RRs in responses:





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


     1. when an RRset is placed in a response, its SIG RR has a higher
        priority for inclusion than additional RRs that may need to be
        included.  If space does not permit its inclusion, the response
        MUST be considered truncated except as provided in 2 below.

     2. When a SIG RR is present in the zone for an additional
        information section RR, the response MUST NOT be considered
        truncated merely because space does not permit the inclusion of
        the SIG RR with the additional information.

     3. SIGs to authenticate glue records and NS RRs for subzones at a
        delegation point are unnecessary and MUST NOT be sent.

     4. If a SIG covers any RR that would be in the answer section of
        the response, its automatic inclusion MUST be in the answer
        section.  If it covers an RR that would appear in the authority
        section, its automatic inclusion MUST be in the authority
        section.  If it covers an RR that would appear in the additional
        information section it MUST appear in the additional information
        section.  This is a change in the existing standard [RFCs 1034,
        1035] which contemplates only NS and SOA RRs in the authority
        section.

     5. Optionally, DNS transactions may be authenticated by a SIG RR at
        the end of the response in the additional information section
        (Section 4.1.8.1).  Such SIG RRs are signed by the DNS server
        originating the response.  Although the signer field MUST be a
        name of the originating server host, the owner name, class, TTL,
        and original TTL, are meaningless.  The class and TTL fields
        SHOULD be zero.  To conserve space, the owner name SHOULD be
        root (a single zero octet).  If transaction authentication is
        desired, that SIG RR must be considered the highest priority for
        inclusion.

4.3 Processing Responses and SIG RRs

   The following rules apply to the processing of SIG RRs included in a
   response:

     1. A security aware resolver that receives a response from a
        security aware server via a secure communication with the AD bit
        (see Section 6.1) set, MAY choose to accept the RRs as received
        without verifying the zone SIG RRs.

     2. In other cases, a security aware resolver SHOULD verify the SIG
        RRs for the RRs of interest.  This may involve initiating
        additional queries for SIG or KEY RRs, especially in the case of




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


        getting a response from a server that does not implement
        security.  (As explained in 2.3.5 above, it will not be possible
        to secure CNAMEs being served up by non-secure resolvers.)

        NOTE: Implementers might expect the above SHOULD to be a MUST.
        However, local policy or the calling application may not require
        the security services.

     3. If SIG RRs are received in response to a user query explicitly
        specifying the SIG type, no special processing is required.

   If the message does not pass integrity checks or the SIG does not
   check against the signed RRs, the SIG RR is invalid and should be
   ignored.  If all of the SIG RR(s) purporting to authenticate an RRset
   are invalid, then the RRset is not authenticated.

   If the SIG RR is the last RR in a response in the additional
   information section and has a type covered of zero, it is a
   transaction signature of the response and the query that produced the
   response.  It MAY be optionally checked and the message rejected if
   the checks fail.  But even if the checks succeed, such a transaction
   authentication SIG does NOT directly authenticate any RRs in the
   message.  Only a proper SIG RR signed by the zone or a key tracing
   its authority to the zone or to static resolver configuration can
   directly authenticate RRs, depending on resolver policy (see Section
   6).  If a resolver does not implement transaction and/or request
   SIGs, it MUST ignore them without error.

   If all checks indicate that the SIG RR is valid then RRs verified by
   it should be considered authenticated.

4.4 Signature Lifetime, Expiration, TTLs, and Validity

   Security aware servers MUST NOT consider SIG RRs to authenticate
   anything before their signature inception or after its expiration
   time (see also Section 6).  Security aware servers MUST NOT consider
   any RR to be authenticated after all its signatures have expired.
   When a secure server caches authenticated data, if the TTL would
   expire at a time further in the future than the authentication
   expiration time, the server SHOULD trim the TTL in the cache entry
   not to extent beyond the authentication expiration time.  Within
   these constraints, servers should continue to follow DNS TTL aging.
   Thus authoritative servers should continue to follow the zone refresh
   and expire parameters and a non-authoritative server should count
   down the TTL and discard RRs when the TTL is zero (even for a SIG
   that has not yet reached its authentication expiration time).  In
   addition, when RRs are transmitted in a query response, the TTL




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


   should be trimmed so that current time plus the TTL does not extend
   beyond the authentication expiration time.  Thus, in general, the TTL
   on a transmitted RR would be

      min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))

   When signatures are generated, signature expiration times should be
   set far enough in the future that it is quite certain that new
   signatures can be generated before the old ones expire.  However,
   setting expiration too far into the future could mean a long time to
   flush any bad data or signatures that may have been generated.

   It is recommended that signature lifetime be a small multiple of the
   TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
   maximum re-signing interval and not less than the zone expiry time.

5. Non-existent Names and Types

   The SIG RR mechanism described in Section 4 above provides strong
   authentication of RRs that exist in a zone.  But it is not clear
   above how to verifiably deny the existence of a name in a zone or a
   type for an existent name.

   The nonexistence of a name in a zone is indicated by the NXT ("next")
   RR for a name interval containing the nonexistent name. An NXT RR or
   RRs and its or their SIG(s) are returned in the authority section,
   along with the error, if the server is security aware.  The same is
   true for a non-existent type under an existing name except that there
   is no error indication other than an empty answer section
   accompanying the NXT(s). This is a change in the existing standard
   [RFCs 1034/1035] which contemplates only NS and SOA RRs in the
   authority section. NXT RRs will also be returned if an explicit query
   is made for the NXT type.

   The existence of a complete set of NXT records in a zone means that
   any query for any name and any type to a security aware server
   serving the zone will result in an reply containing at least one
   signed RR unless it is a query for delegation point NS or glue A or
   AAAA RRs.

5.1 The NXT Resource Record

   The NXT resource record is used to securely indicate that RRs with an
   owner name in a certain name interval do not exist in a zone and to
   indicate what RR types are present for an existing name.






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


   The owner name of the NXT RR is an existing name in the zone.  It's
   RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
   create a chain of all of the literal owner names in that zone,
   including unexpanded wildcards but omitting the owner name of glue
   address records unless they would otherwise be included. This implies
   a canonical ordering of all domain names in a zone as described in
   Section 8. The presence of the NXT RR means that no name between its
   owner name and the name in its RDATA area exists and that no other
   types exist under its owner name.

   There is a potential problem with the last NXT in a zone as it wants
   to have an owner name which is the last existing name in canonical
   order, which is easy, but it is not obvious what name to put in its
   RDATA to indicate the entire remainder of the name space.  This is
   handled by treating the name space as circular and putting the zone
   name in the RDATA of the last NXT in a zone.

   The NXT RRs for a zone SHOULD be automatically calculated and added
   to the zone when SIGs are added.  The NXT RR's TTL SHOULD NOT exceed
   the zone minimum TTL.

   The type number for the NXT RR is 30.

   NXT RRs are only signed by zone level keys.

5.2 NXT RDATA Format

   The RDATA for an NXT RR consists simply of a domain name followed by
   a bit map, 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 map                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The NXT RR type bit map format currently defined is one bit per RR
   type present for the owner name.  A one bit indicates that at least
   one RR of that type is present for the owner name.  A zero indicates
   that no such RR is present.  All bits not specified because they are
   beyond the end of the bit map are assumed to be zero.  Note that bit
   30, for NXT, will always be on so the minimum bit map length is
   actually four octets. Trailing zero octets are prohibited in this
   format.  The first bit represents RR type zero (an illegal type which
   can not be present) and so will be zero in this format.  This format
   is not used if there exists an RR with a type number greater than



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


   127.  If the zero bit of the type bit map is a one, it indicates that
   a different format is being used which will always be the case if a
   type number greater than 127 is present.

   The domain name may be compressed with standard DNS name compression
   when being transmitted over the network.  The size of the bit map can
   be inferred from the RDLENGTH and the length of the next domain name.

5.3 Additional Complexity Due to Wildcards

   Proving that a non-existent name response is correct or that a
   wildcard expansion response is correct makes things a little more
   complex.

   In particular, when a non-existent name response is returned, an NXT
   must be returned showing that the exact name queried did not exist
   and, in general, one or more additional NXT's need to be returned to
   also prove that there wasn't a wildcard whose expansion should have
   been returned. (There is no need to return multiple