rfc4035.txt

非常好的dns解析软件

   NOT set the TC bit solely because these RRs didn't fit (see Section
   3.1.1).

3.1.3.  Including NSEC RRs in a Response

   When responding to a query that has the DO bit set, a security-aware
   authoritative name server for a signed zone MUST include NSEC RRs in
   each of the following cases:

   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
      but does not contain any RRsets that exactly match <SNAME, SCLASS,
      STYPE>.

   Name Error: The zone does not contain any RRsets that match <SNAME,
      SCLASS> either exactly or via wildcard name expansion.

   Wildcard Answer: The zone does not contain any RRsets that exactly
      match <SNAME, SCLASS> but does contain an RRset that matches
      <SNAME, SCLASS, STYPE> via wildcard name expansion.

   Wildcard No Data: The zone does not contain any RRsets that exactly
      match <SNAME, SCLASS> and does contain one or more RRsets that
      match <SNAME, SCLASS> via wildcard name expansion, but does not
      contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
      name expansion.

   In each of these cases, the name server includes NSEC RRs in the
   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
   not present in the zone and that the response that the name server is
   returning is correct given the data in the zone.









Arends, et al.              Standards Track                    [Page 11]

RFC 4035             DNSSEC Protocol Modifications            March 2005


3.1.3.1.  Including NSEC RRs: No Data Response

   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
   include the NSEC RR for <SNAME, SCLASS> along with its associated
   RRSIG RR(s) in the Authority section of the response (see Section
   3.1.1).  If space does not permit inclusion of the NSEC RR or its
   associated RRSIG RR(s), the name server MUST set the TC bit (see
   Section 3.1.1).

   Since the search name exists, wildcard name expansion does not apply
   to this query, and a single signed NSEC RR suffices to prove that the
   requested RR type does not exist.

3.1.3.2.  Including NSEC RRs: Name Error Response

   If the zone does not contain any RRsets matching <SNAME, SCLASS>
   either exactly or via wildcard name expansion, then the name server
   MUST include the following NSEC RRs in the Authority section, along
   with their associated RRSIG RRs:

   o  An NSEC RR proving that there is no exact match for <SNAME,
      SCLASS>.

   o  An NSEC RR proving that the zone contains no RRsets that would
      match <SNAME, SCLASS> via wildcard name expansion.

   In some cases, a single NSEC RR may prove both of these points.  If
   it does, the name server SHOULD only include the NSEC RR and its
   RRSIG RR(s) once in the Authority section.

   If space does not permit inclusion of these NSEC and RRSIG RRs, the
   name server MUST set the TC bit (see Section 3.1.1).

   The owner names of these NSEC and RRSIG RRs are not subject to
   wildcard name expansion when these RRs are included in the Authority
   section of the response.

   Note that this form of response includes cases in which SNAME
   corresponds to an empty non-terminal name within the zone (a name
   that is not the owner name for any RRset but that is the parent name
   of one or more RRsets).

3.1.3.3.  Including NSEC RRs: Wildcard Answer Response

   If the zone does not contain any RRsets that exactly match <SNAME,
   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
   via wildcard name expansion, the name server MUST include the



Arends, et al.              Standards Track                    [Page 12]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   wildcard-expanded answer and the corresponding wildcard-expanded
   RRSIG RRs in the Answer section and MUST include in the Authority
   section an NSEC RR and associated RRSIG RR(s) proving that the zone
   does not contain a closer match for <SNAME, SCLASS>.  If space does
   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
   server MUST set the TC bit (see Section 3.1.1).

3.1.3.4.  Including NSEC RRs: Wildcard No Data Response

   This case is a combination of the previous cases.  The zone does not
   contain an exact match for <SNAME, SCLASS>, and although the zone
   does contain RRsets that match <SNAME, SCLASS> via wildcard
   expansion, none of those RRsets matches STYPE.  The name server MUST
   include the following NSEC RRs in the Authority section, along with
   their associated RRSIG RRs:

   o  An NSEC RR proving that there are no RRsets matching STYPE at the
      wildcard owner name that matched <SNAME, SCLASS> via wildcard
      expansion.

   o  An NSEC RR proving that there are no RRsets in the zone that would
      have been a closer match for <SNAME, SCLASS>.

   In some cases, a single NSEC RR may prove both of these points.  If
   it does, the name server SHOULD only include the NSEC RR and its
   RRSIG RR(s) once in the Authority section.

   The owner names of these NSEC and RRSIG RRs are not subject to
   wildcard name expansion when these RRs are included in the Authority
   section of the response.

   If space does not permit inclusion of these NSEC and RRSIG RRs, the
   name server MUST set the TC bit (see Section 3.1.1).

3.1.3.5.  Finding the Right NSEC RRs

   As explained above, there are several situations in which a
   security-aware authoritative name server has to locate an NSEC RR
   that proves that no RRsets matching a particular SNAME exist.
   Locating such an NSEC RR within an authoritative zone is relatively
   simple, at least in concept.  The following discussion assumes that
   the name server is authoritative for the zone that would have held
   the non-existent RRsets matching SNAME.  The algorithm below is
   written for clarity, not for efficiency.

   To find the NSEC that proves that no RRsets matching name N exist in
   the zone Z that would have held them, construct a sequence, S,
   consisting of the owner names of every RRset in Z, sorted into



Arends, et al.              Standards Track                    [Page 13]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   canonical order ([RFC4034]), with no duplicate names.  Find the name
   M that would have immediately preceded N in S if any RRsets with
   owner name N had existed.  M is the owner name of the NSEC RR that
   proves that no RRsets exist with owner name N.

   The algorithm for finding the NSEC RR that proves that a given name
   is not covered by any applicable wildcard is similar but requires an
   extra step.  More precisely, the algorithm for finding the NSEC
   proving that no RRsets exist with the applicable wildcard name is
   precisely the same as the algorithm for finding the NSEC RR that
   proves that RRsets with any other owner name do not exist.  The part
   that's missing is a method of determining the name of the non-
   existent applicable wildcard.  In practice, this is easy, because the
   authoritative name server has already checked for the presence of
   precisely this wildcard name as part of step (1)(c) of the normal
   lookup algorithm described in Section 4.3.2 of [RFC1034].

3.1.4.  Including DS RRs in a Response

   When responding to a query that has the DO bit set, a security-aware
   authoritative name server returning a referral includes DNSSEC data
   along with the NS RRset.

   If a DS RRset is present at the delegation point, the name server
   MUST return both the DS RRset and its associated RRSIG RR(s) in the
   Authority section along with the NS RRset.

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR that proves that the DS RRset is not
   present and the NSEC RR's associated RRSIG RR(s) along with the NS
   RRset.  The name server MUST place the NS RRset before the NSEC RRset
   and its associated RRSIG RR(s).

   Including these DS, NSEC, and RRSIG RRs increases the size of
   referral messages and may cause some or all glue RRs to be omitted.
   If space does not permit inclusion of the DS or NSEC RRset and
   associated RRSIG RRs, the name server MUST set the TC bit (see
   Section 3.1.1).

3.1.4.1.  Responding to Queries for DS RRs

   The DS resource record type is unusual in that it appears only on the
   parent zone's side of a zone cut.  For example, the DS RRset for the
   delegation of "foo.example" is stored in the "example" zone rather
   than in the "foo.example" zone.  This requires special processing
   rules for both name servers and resolvers, as the name server for the
   child zone is authoritative for the name at the zone cut by the
   normal DNS rules but the child zone does not contain the DS RRset.



Arends, et al.              Standards Track                    [Page 14]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   A security-aware resolver sends queries to the parent zone when
   looking for a needed DS RR at a delegation point (see Section 4.2).
   However, special rules are necessary to avoid confusing
   security-oblivious resolvers which might become involved in
   processing such a query (for example, in a network configuration that
   forces a security-aware resolver to channel its queries through a
   security-oblivious recursive name server).  The rest of this section
   describes how a security-aware name server processes DS queries in
   order to avoid this problem.

   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for the parent zone.

   o  The name server does not offer recursion.

   In all other cases, the name server either has some way of obtaining
   the DS RRset or could not have been expected to have the DS RRset
   even by the pre-DNSSEC processing rules, so the name server can
   return either the DS RRset or an error response according to the
   normal processing rules.

   If all the above conditions are met, however, the name server is
   authoritative for SNAME but cannot supply the requested RRset.  In
   this case, the name server MUST return an authoritative "no data"
   response showing that the DS RRset does not exist in the child zone's
   apex.  See Appendix B.8 for an example of such a response.

3.1.5.  Responding to Queries for Type AXFR or IXFR

   DNSSEC does not change the DNS zone transfer process.  A signed zone
   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
   records have no special meaning with respect to a zone transfer
   operation.

   An authoritative name server is not required to verify that a zone is
   properly signed before sending or accepting a zone transfer.
   However, an authoritative name server MAY choose to reject the entire
   zone transfer if the zone fails to meet any of the signing
   requirements described in Section 2.  The primary objective of a zone
   transfer is to ensure that all authoritative name servers have
   identical copies of the zone.  An authoritative name server that



Arends, et al.              Standards Track                    [Page 15]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   chooses to perform its own zone validation MUST NOT selectively
   reject some RRs and accept others.

   DS RRsets appear only on the parental side of a zone cut and are
   authoritative data in the parent zone.  As with any other
   authoritative RRset, the DS RRset MUST be included in zone transfers
   of the zone in which the RRset is authoritative data.  In the case of
   the DS RRset, this is the parent zone.

   NSEC RRs appear in both the parent and child zones at a zone cut and
   are authoritative data in both the parent and child zones.  The
   parental and child NSEC RRs at a zone cut are never identical to each
   other, as the NSEC RR in the child zone's apex will always indicate
   the presence of the child zone's SOA RR whereas the parental NSEC RR
   at the zone cut will never indicate the presence of an SOA RR.  As
   with any other authoritative RRs, NSEC RRs MUST be included in zone
   transfers of the zone in which they are authoritative data.  The
   parental NSEC RR at a zone cut MUST be included in zone transfers of
   the parent zone, and the NSEC at the zone apex of the child zone MUST
   be included in zone transfers of the child zone.