rfc2065.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,439 行 · 第 1/5 页

   The AXFR SIG must be calculated last of all zone key signed SIGs in
   the zone.  In effect, when signing the zone, you order, as described
   above, all RRs to be signed by the zone, and all associated glue RRs
   and delegation point NS RRs.  You can then make one pass inserting
   all the zone SIGs.  As you proceed you hash RRs to be signed into
   both an RRset hash and the zone hash.  When the name or type changes
   you calculate and insert the RRset zone SIG, clear the RRset hash,
   and hash that SIG into the zone hash (note that glue RRs and
   delegation point NSs are not zone signed but zone apex NSs are).
   When you have finished processing all the starting RRs as described
   above, you can then use the cumulative zone hash RR to calculate and
   insert an AXFR SIG covering the zone.  Of course any computational
   technique producing the same results as above is permitted.

   The AXFR SIG really belongs to the zone as a whole, not to the zone
   name.  Although it should be correct for the zone name, the labels
   field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only
   retrieved as part of a zone transfer.  After validation of the AXFR
   SIG, the zone MAY be considered valid without verification of the
   internal zone signed SIGs in the zone; however, any RRs authenticated
   by SIGs signed by entity keys or the like MUST still be validated.
   The AXFR SIG SHOULD be transmitted first in a zone transfer so the



Eastlake & Kaufman          Standards Track                    [Page 21]

RFC 2065                DNS Security Extensions             January 1997


   receiver can tell immediately that they may be able to avoid
   verifying other zone signed SIGs.

   RRs which are authenticated by a dynamic update key and not by the
   zone key (see Section 3.2) are not included in the AXFR SIG. They may
   originate in the network and might not, in general, be migrated to
   the recommended off line zone signing procedure (see Section 7.2).
   Thus, such RRs are not directly signed by the zone, are not included
   in the AXFR SIG, and are protected against omission from zone
   transfers only to the extent that the server and communication can be
   trusted.

4.1.4 Transaction and Request SIGs

   A response message from a security aware server may optionally
   contain a special SIG as the last item in 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.2) of the
   entire preceding DNS reply message, including DNS header but not the
   IP header, concatenated with the entire DNS query message that
   produced this response, including the query's DNS header but not its
   IP header.  That is

        data = full response (less final 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 at the
   begining or any preceding request SIGs at the end. Such request SIGs
   are included in the "data" used to form any optional response
   transaction SIG.

   WARNING: Request SIGs are unnecessary for currently defined queries
   and will cause almost all existing DNS servers to completely ignore a
   query.  However, such SIGs may be needed to authenticate future DNS
   secure dynamic update or other requests.






Eastlake & Kaufman          Standards Track                    [Page 22]

RFC 2065                DNS Security Extensions             January 1997


4.2 SIG RRs in the Construction of Responses

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

   1. when an RR set is placed in a response, its SIG RR has a higher
      priority for inclusion than other 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 its SIG RR.

   3. SIGs to authenticate non-authoritative data (glue records and NS
      RRs for subzones) are unnecessary and MUST NOT be sent.  (Note
      that KEYs for subzones are controlling in a superzone so the
      superzone's signature on the KEY MUST be included (unless the KEY
      was additional information and the SIG did not fit).)

   4. If a SIG covers any RR that would be in the answer section of the
      response, its automatic inclusion MUST be 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 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.4).  Such SIG RRs are signed by the DNS server
      originating the response.  Although the signer field MUST be the
      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 higher priority for inclusion than
      any other RR in the response.










Eastlake & Kaufman          Standards Track                    [Page 23]

RFC 2065                DNS Security Extensions             January 1997


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 what it
      believes to be 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
      getting a response from an insecure server.  (As explained in 4.2
      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 reasonable 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 a set of
   RRs are invalid, then the set of RR(s) 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 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
   authenticate RRs.  If a resolver does not implement transaction
   and/or request SIGs, it MUST ignore them without error.

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

4.4 Signature Expiration, TTLs, and Validity

   Security aware servers must not consider SIG RRs to authenticate
   anything after their expiration time and not consider any RR to be
   authenticated after its signatures have expired.  Within that



Eastlake & Kaufman          Standards Track                    [Page 24]

RFC 2065                DNS Security Extensions             January 1997


   constraint, 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.  In addition, when RRs
   are transmitted in a query response, the TTL should be trimmed so
   that current time plus the TTL does not extend beyond the signature
   expiration time.  Thus, in general, the TTL on an transmitted RR
   would be

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

4.5 File Representation of SIG RRs

   A SIG RR can be represented as a single logical line in a zone data
   file [RFC1033] but there are some special considerations as described
   below.  (It does not make sense to include a transaction or request
   authenticating SIG RR in a file as they are a transient
   authentication that covers data including an ephemeral transaction
   number and so must be calculated in real time.)

   There is no particular problem with the signer, covered type, and
   times.  The time fields appears in the form YYYYMMDDHHMMSS where YYYY
   is the year, the first MM is the month number (01-12), DD is the day
   of the month (01-31), HH is the hour in 24 hours notation (00-23),
   the second MM is the minute (00-59), and SS is the second (00-59).

   The original TTL and algorithm fields appear as unsigned integers.

   If the original TTL, which applies to the type signed, is the same as
   the TTL of the SIG RR itself, it may be omitted.  The date field
   which follows it is larger than the maximum possible TTL so there is
   no ambiguity.

   The "labels" field does not appear in the file representation as it
   can be calculated from the owner name.

   The key footprint appears as an unsigned decimal number.

   However, the signature itself can be very long.  It is the last data
   field and is represented in base 64 (see Appendix) and may be divided
   up into any number of white space separated substrings, down to
   single base 64 digits, which are concatenated to obtain the full
   signature.  These substrings can be split between lines using the
   standard parenthesis.







Eastlake & Kaufman          Standards Track                    [Page 25]

RFC 2065                DNS Security Extensions             January 1997


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 is it not clear
   above how to authenticatably 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. A NXT RR and
   its SIG 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.  This is a change in the existing
   standard 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 always result in an reply containing at least
   one signed RR.

   NXT RRs do not appear in zone master files since they can be derived
   from the rest of the zone.

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 zone signed RR types are present for an existing name.

   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. The presence of the NXT RR
   means that generally no name between its owner name