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

bind 9.3结合mysql数据库

   The process for constructing the RRSIG RR for a given RRset is
   described in [I-D.ietf-dnsext-dnssec-records].  An RRset MAY have
   multiple RRSIG RRs associated with it.

   An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
   would add no value and would create an infinite loop in the signing
   process.

   The NS RRset that appears at the zone apex name MUST be signed, but
   the NS RRsets that appear at delegation points (that is, the NS
   RRsets in the parent zone that delegate the name to the child zone's
   name servers) MUST NOT be signed.  Glue address RRsets associated
   with delegations MUST NOT be signed.

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset
   located at the delegating parent (if any).

2.3  Including NSEC RRs in a Zone

   Each owner name in the zone which has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record.  The
   format of NSEC RRs and the process for constructing the NSEC RR for a
   given name is described in [I-D.ietf-dnsext-dnssec-records].

   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
   value field in the zone SOA RR.

   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
   RRset at any particular owner name.  That is, the signing process
   MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
   not the owner name of any RRset before the zone was signed.  The main
   reasons for this are a desire for namespace consistency between
   signed and unsigned versions of the same zone and a desire to reduce
   the risk of response inconsistency in security oblivious recursive
   name servers.

   The type bitmap of every NSEC resource record in a signed zone MUST
   indicate the presence of both the NSEC record itself and its
   corresponding RRSIG record.




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


   The difference between the set of owner names that require RRSIG
   records and the set of owner names that require NSEC records is
   subtle and worth highlighting.  RRSIG records are present at the
   owner names of all authoritative RRsets.  NSEC records are present at
   the owner names of all names for which the signed zone is
   authoritative and also at the owner names of delegations from the
   signed zone to its children.  Neither NSEC nor RRSIG records are
   present (in the parent zone) at the owner names of glue address
   RRsets.  Note, however, that this distinction is for the most part is
   only visible during the zone signing process, because NSEC RRsets are
   authoritative data, and are therefore signed, thus any owner name
   which has an NSEC RRset will have RRSIG RRs as well in the signed
   zone.

   The bitmap for the NSEC RR at a delegation point requires special
   attention.  Bits corresponding to the delegation NS RRset and any
   RRsets for which the parent zone has authoritative data MUST be set;
   bits corresponding to any non-NS RRset for which the parent is not
   authoritative MUST be clear.

2.4  Including DS RRs in a Zone

   The DS resource record establishes authentication chains between DNS
   zones.  A DS RRset SHOULD be present at a delegation point when the
   child zone is signed.  The DS RRset MAY contain multiple records,
   each referencing a public key in the child zone used to verify the
   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed and DS
   RRsets MUST NOT appear at a zone's apex.

   A DS RR SHOULD point to a DNSKEY RR which is present in the child's
   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
   by the corresponding private key.

   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
   (that is, the NS RRset from the same zone containing the DS RRset).

   Construction of a DS RR requires knowledge of the corresponding
   DNSKEY RR in the child zone, which implies communication between the
   child and parent zones.  This communication is an operational matter
   not covered by this document.

2.5  Changes to the CNAME Resource Record.

   If a CNAME RRset is present at a name in a signed zone, appropriate
   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
   name for secure dynamic update purposes is also allowed.  Other types
   MUST NOT be present at that name.




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


   This is a modification to the original CNAME definition given in
   [RFC1034].  The original definition of the CNAME RR did not allow any
   other types to coexist with a CNAME record, but a signed zone
   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
   this conflict, this specification modifies the definition of the
   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.

2.6  DNSSEC RR Types Appearing at Zone Cuts.

   DNSSEC introduced two new RR types that are unusual in that they can
   appear at the parental side of a zone cut.  At the parental side of a
   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
   the owner name.  A DS RR could also be present if the zone being
   delegated is signed and wishes to have a chain of authentication to
   the parent zone.  This is an exception to the original DNS
   specification ([RFC1034]) which states that only NS RRsets could
   appear at the parental side of a zone cut.

   This specification updates the original DNS specification to allow
   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
   are authoritative for the parent when they appear at the parent side
   of a zone cut.

2.7  Example of a Secure Zone

   Appendix A shows a complete example of a small signed zone.

























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


3.  Serving

   This section describes the behavior of entities that include
   security-aware name server functions.  In many cases such functions
   will be part of a security-aware recursive name server, but a
   security-aware authoritative name server has some of the same
   requirements.  Functions specific to security-aware recursive name
   servers are described in Section 3.2; functions specific to
   authoritative servers are described in Section 3.1.

   The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
   are as used in [RFC1034].

   A security-aware name server MUST support the EDNS0 [RFC2671] message
   size extension, MUST support a message size of at least 1220 octets,
   and SHOULD support a message size of 4000 octets [RFC3226].

   A security-aware name server which receives a DNS query that does not
   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,
   and MUST NOT perform any of the additional processing described
   below.  Since the DS RR type has the peculiar property of only
   existing in the parent zone at delegation points, DS RRs always
   require some special processing, as described in Section 3.1.4.1.

   Security aware name servers that receive explicit queries for
   security RR types which match the content of more than one zone that
   it serves (for example, NSEC and RRSIG RRs above and below a
   delegation point where the server is authoritative for both zones)
   should behave self-consistently.  The name server MAY return one of
   the following:
   o  The above-delegation RRsets
   o  The below-delegation RRsets
   o  Both above and below-delegation RRsets
   o  Empty answer section (no records)
   o  Some other response
   o  An error
   As long as the response is always consistent for each query to the
   name server.

   DNSSEC allocates two new bits in the DNS message header: the CD
   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
   is controlled by resolvers; a security-aware name server MUST copy
   the CD bit from a query into the corresponding response.  The AD bit
   is controlled by name servers; a security-aware name server MUST
   ignore the setting of the AD bit in queries.  See Section 3.1.6,
   Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
   on the behavior of these bits.



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


   A security aware name server which synthesizes CNAME RRs from DNAME
   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
   synthesized CNAME RRs.

3.1  Authoritative Name Servers

   Upon receiving a relevant query that has the EDNS [RFC2671] OPT
   pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name
   server for a signed zone MUST include additional RRSIG, NSEC, and DS
   RRs according to the following rules:
   o  RRSIG RRs that can be used to authenticate a response MUST be
      included in the response according to the rules in Section 3.1.1;
   o  NSEC RRs that can be used to provide authenticated denial of
      existence MUST be included in the response automatically according
      to the rules in Section 3.1.3;
   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
      be included in referrals automatically according to the rules in
      Section 3.1.4.

   These rules only apply to responses the semantics of which convey
   information about the presence or absence of resource records.  That
   is, these rules are not intended to rule out responses such as RCODE
   4 ("Not Implemented") or RCODE 5 ("Refused").

   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
   discusses zone transfer requirements.

3.1.1  Including RRSIG RRs in a Response

   When responding to a query that has the DO bit set, a security-aware
   authoritative name server SHOULD attempt to send RRSIG RRs that a
   security-aware resolver can use to authenticate the RRsets in the
   response.  A name server SHOULD make every attempt to keep the RRset
   and its associated RRSIG(s) together in a response.  Inclusion of
   RRSIG RRs in a response is subject to the following rules:
   o  When placing a signed RRset in the Answer section, the name server
      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
      RRs have a higher priority for inclusion than any other RRsets
      that may need to be included.  If space does not permit inclusion
      of these RRSIG RRs, the name server MUST set the TC bit.
   o  When placing a signed RRset in the Authority section, the name
      server MUST also place its RRSIG RRs in the Authority section.
      The RRSIG RRs have a higher priority for inclusion than any other
      RRsets that may need to be included.  If space does not permit
      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
   o  When placing a signed RRset in the Additional section, the name
      server MUST also place its RRSIG RRs in the Additional section.
      If space does not permit inclusion of both the RRset and its



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


      associated RRSIG RRs, the name server MAY drop the RRSIG RRs.  If
      this happens, the name server MUST NOT set the TC bit solely
      because these RRSIG RRs didn't fit.

3.1.2  Including DNSKEY RRs In a Response

   When responding to a query that has the DO bit set and that requests
   the SOA or NS RRs at the apex of a signed zone, a security-aware
   authoritative name server for that zone MAY return the zone apex
   DNSKEY RRset in the Additional section.  In this situation, the
   DNSKEY RRset and associated RRSIG RRs have lower priority than any
   other information that would be placed in the additional section.
   The name server SHOULD NOT include the DNSKEY RRset unless there is
   enough space in the response message for both the DNSKEY RRset and
   its associated RRSIG RR(s).  If there is not enough space to include