rfc4035.txt

非常好的dns解析软件

   An RRSIG RR itself MUST NOT be signed, as 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 that 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 [RFC4034].

   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 name nodes that 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.

   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



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


   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
   visible only during the zone signing process, as NSEC RRsets are
   authoritative data and are therefore signed.  Thus, any owner name
   that 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 that is present in the child's
   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
   by the corresponding private key.  DS RRs that fail to meet these
   conditions are not useful for validation, but because the DS RR and
   its corresponding DNSKEY RR are in different zones, and because the
   DNS is only loosely consistent, temporary mismatches can occur.

   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 ([RFC3007]).
   Other types MUST NOT be present at that name.

   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



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


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

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.

   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
   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.  As IPv6
   packets can only be fragmented by the source host, a security aware
   name server SHOULD take steps to ensure that UDP datagrams it
   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
   and [RFC3226] for further discussion of packet size and fragmentation
   issues.





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


   A security-aware name server that 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.
   Because 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 that 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.  As long as the response is always
   consistent for each query to the name server, 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.

   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 Sections 3.1.6,
   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.

   A security aware name server that 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.







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


   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 where the semantics 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 have 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 have 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
      associated RRSIG RRs, the name server MAY retain the RRset while
      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
      set the TC bit solely because these RRSIG RRs didn't fit.








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


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 does
   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
   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST