draft-ietf-dnsext-dnssec-protocol-07.txt

bind 9.3结合mysql数据库

   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
   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>, 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 that are in the zone.





Arends, et al.          Expires January 13, 2005               [Page 11]

Internet-Draft       DNSSEC Protocol Modifications             July 2004


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 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>; and
   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, in
   that case 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
   which is not the owner name for any RRset but which 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 which exactly match <SNAME,
   SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
   STYPE> via wildcard name expansion, the name server MUST include the
   wildcard-expanded answer and the corresponding wildcard-expanded
   RRSIG RRs in the Answer section, and MUST include in the Authority



Arends, et al.          Expires January 13, 2005               [Page 12]

Internet-Draft       DNSSEC Protocol Modifications             July 2004


   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 while the zone does
   contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
   none of those RRsets match 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 which matched <SNAME, SCLASS> via wildcard
      expansion; and
   o  An NSEC RR proving that there are no RRsets in the zone which
      would have been a closer match for <SNAME, SCLASS>.

   In some cases a single NSEC RR may prove both of these points, in
   which case 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 needs to locate an NSEC RR
   which 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 which would have held
   the nonexistent RRsets matching SNAME.  The algorithm below is
   written for clarity, not efficiency.

   To find the NSEC which proves that no RRsets matching name N exist in
   the zone Z which would have held them, construct sequence S
   consisting of the owner names of every RRset in Z, sorted into
   canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate
   names.  Find the name M which 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 which proves that no RRsets exist with owner name N.



Arends, et al.          Expires January 13, 2005               [Page 13]

Internet-Draft       DNSSEC Protocol Modifications             July 2004


   The algorithm for finding the NSEC RR which 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 which
   proves that RRsets with any other owner name do not exist: the part
   that's missing is how to determine the name of the nonexistent
   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 which 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.  The name server MUST
   place the NS RRset before the DS RRset and its associated RRSIG
   RR(s).

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR which 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, since 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.

   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).



Arends, et al.          Expires January 13, 2005               [Page 14]

Internet-Draft       DNSSEC Protocol Modifications             July 2004


   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; and
   o  the name server is authoritative for the child zone; and
   o  the name server is not authoritative for the parent zone; and
   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 of 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 meets 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 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



Arends, et al.          Expires January 13, 2005               [Page 15]

Internet-Draft       DNSSEC Protocol Modifications             July 2004


   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, since the NSEC RR in the child zone's apex will always
   indicate the presence of the child zone's SOA RR while 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 zone transfers of
   the parent zone, while the NSEC at the zone apex of the child zone
   MUST be included in zone transfers of the child zone.

   RRSIG RRs appear in both the parent and child zones at a zone cut,
   and are authoritative in whichever zone contains the authoritative
   RRset for which the RRSIG RR provides the signature.  That is, the
   RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
   authoritative in the parent zone, while the RRSIG for any RRset in
   the child zone's apex will be authoritative in the child zone.
   Parental and child RRSIG RRs at a zone cut will never be identical to
   each other, since the Signer's Name field of an RRSIG RR in the child
   zone's apex will indicate a DNSKEY RR in the child zone's apex while