rfc4033.txt

非常好的dns解析软件

   accept unverified responses.

   A security-aware resolver should take a signature's validation period
   into consideration when determining the TTL of data in its cache, to
   avoid caching signed data beyond the validity period of the
   signature.  However, it should also allow for the possibility that
   the security-aware resolver's own clock is wrong.  Thus, a
   security-aware resolver that is part of a security-aware recursive
   name server will have to pay careful attention to the DNSSEC
   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
   blocking valid signatures from getting through to other
   security-aware resolvers that are clients of this recursive name
   server.  See [RFC4035] for how a secure recursive server handles
   queries with the CD bit set.

7.  Stub Resolver Considerations

   Although not strictly required to do so by the protocol, most DNS
   queries originate from stub resolvers.  Stub resolvers, by
   definition, are minimal DNS resolvers that use recursive query mode
   to offload most of the work of DNS resolution to a recursive name
   server.  Given the widespread use of stub resolvers, the DNSSEC





Arends, et al.              Standards Track                    [Page 11]

RFC 4033       DNS Security Introduction and Requirements     March 2005


   architecture has to take stub resolvers into account, but the
   security features needed in a stub resolver differ in some respects
   from those needed in a security-aware iterative resolver.

   Even a security-oblivious stub resolver may benefit from DNSSEC if
   the recursive name servers it uses are security-aware, but for the
   stub resolver to place any real reliance on DNSSEC services, the stub
   resolver must trust both the recursive name servers in question and
   the communication channels between itself and those name servers.
   The first of these issues is a local policy issue: in essence, a
   security-oblivious stub resolver has no choice but to place itself at
   the mercy of the recursive name servers that it uses, as it does not
   perform DNSSEC validity checks on its own.  The second issue requires
   some kind of channel security mechanism; proper use of DNS
   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
   Particular implementations may have other choices available, such as
   operating system specific interprocess communication mechanisms.
   Confidentiality is not needed for this channel, but data integrity
   and message authentication are.

   A security-aware stub resolver that does trust both its recursive
   name servers and its communication channel to them may choose to
   examine the setting of the Authenticated Data (AD) bit in the message
   header of the response messages it receives.  The stub resolver can
   use this flag bit as a hint to find out whether the recursive name
   server was able to validate signatures for all of the data in the
   Answer and Authority sections of the response.

   There is one more step that a security-aware stub resolver can take
   if, for whatever reason, it is not able to establish a useful trust
   relationship with the recursive name servers that it uses: it can
   perform its own signature validation by setting the Checking Disabled
   (CD) bit in its query messages.  A validating stub resolver is thus
   able to treat the DNSSEC signatures as trust relationships between
   the zone administrators and the stub resolver itself.

8.  Zone Considerations

   There are several differences between signed and unsigned zones.  A
   signed zone will contain additional security-related records (RRSIG,
   DNSKEY, DS, and NSEC records).  RRSIG and NSEC records may be
   generated by a signing process prior to serving the zone.  The RRSIG
   records that accompany zone data have defined inception and
   expiration times that establish a validity period for the signatures
   and the zone data the signatures cover.





Arends, et al.              Standards Track                    [Page 12]

RFC 4033       DNS Security Introduction and Requirements     March 2005


8.1.  TTL Values vs. RRSIG Validity Period

   It is important to note the distinction between a RRset's TTL value
   and the signature validity period specified by the RRSIG RR covering
   that RRset.  DNSSEC does not change the definition or function of the
   TTL value, which is intended to maintain database coherency in
   caches.  A caching resolver purges RRsets from its cache no later
   than the end of the time period specified by the TTL fields of those
   RRsets, regardless of whether the resolver is security-aware.

   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
   the other hand, specify the time period during which the signature
   can be used to validate the covered RRset.  The signatures associated
   with signed zone data are only valid for the time period specified by
   these fields in the RRSIG RRs in question.  TTL values cannot extend
   the validity period of signed RRsets in a resolver's cache, but the
   resolver may use the time remaining before expiration of the
   signature validity period of a signed RRset as an upper bound for the
   TTL of the signed RRset and its associated RRSIG RR in the resolver's
   cache.

8.2.  New Temporal Dependency Issues for Zones

   Information in a signed zone has a temporal dependency that did not
   exist in the original DNS protocol.  A signed zone requires regular
   maintenance to ensure that each RRset in the zone has a current valid
   RRSIG RR.  The signature validity period of an RRSIG RR is an
   interval during which the signature for one particular signed RRset
   can be considered valid, and the signatures of different RRsets in a
   zone may expire at different times.  Re-signing one or more RRsets in
   a zone will change one or more RRSIG RRs, which will in turn require
   incrementing the zone's SOA serial number to indicate that a zone
   change has occurred and re-signing the SOA RRset itself.  Thus,
   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
   and zone transfer operations.

9.  Name Server Considerations

   A security-aware name server should include the appropriate DNSSEC
   records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
   from resolvers that have signaled their willingness to receive such
   records via use of the DO bit in the EDNS header, subject to message
   size limitations.  Because inclusion of these DNSSEC RRs could easily
   cause UDP message truncation and fallback to TCP, a security-aware
   name server must also support the EDNS "sender's UDP payload"
   mechanism.





Arends, et al.              Standards Track                    [Page 13]

RFC 4033       DNS Security Introduction and Requirements     March 2005


   If possible, the private half of each DNSSEC key pair should be kept
   offline, but this will not be possible for a zone for which DNS
   dynamic update has been enabled.  In the dynamic update case, the
   primary master server for the zone will have to re-sign the zone when
   it is updated, so the private key corresponding to the zone signing
   key will have to be kept online.  This is an example of a situation
   in which the ability to separate the zone's DNSKEY RRset into zone
   signing key(s) and key signing key(s) may be useful, as the key
   signing key(s) in such a case can still be kept offline and may have
   a longer useful lifetime than the zone signing key(s).

   By itself, DNSSEC is not enough to protect the integrity of an entire
   zone during zone transfer operations, as even a signed zone contains
   some unsigned, nonauthoritative data if the zone has any children.
   Therefore, zone maintenance operations will require some additional
   mechanisms (most likely some form of channel security, such as TSIG,
   SIG(0), or IPsec).

10.  DNS Security Document Family

   The DNSSEC document set can be partitioned into several main groups,
   under the larger umbrella of the DNS base protocol documents.

   The "DNSSEC protocol document set" refers to the three documents that
   form the core of the DNS security extensions:

   1.  DNS Security Introduction and Requirements (this document)

   2.  Resource Records for DNS Security Extensions [RFC4034]

   3.  Protocol Modifications for the DNS Security Extensions [RFC4035]

   Additionally, any document that would add to or change the core DNS
   Security extensions would fall into this category.  This includes any
   future work on the communication between security-aware stub
   resolvers and upstream security-aware recursive name servers.

   The "Digital Signature Algorithm Specification" document set refers
   to the group of documents that describe how specific digital
   signature algorithms should be implemented to fit the DNSSEC resource
   record format.  Each document in this set deals with a specific
   digital signature algorithm.  Please see the appendix on "DNSSEC
   Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
   that were defined when this core specification was written.

   The "Transaction Authentication Protocol" document set refers to the
   group of documents that deal with DNS message authentication,
   including secret key establishment and verification.  Although not



Arends, et al.              Standards Track                    [Page 14]

RFC 4033       DNS Security Introduction and Requirements     March 2005


   strictly part of the DNSSEC specification as defined in this set of
   documents, this group is noted because of its relationship to DNSSEC.

   The final document set, "New Security Uses", refers to documents that
   seek to use proposed DNS Security extensions for other security
   related purposes.  DNSSEC does not provide any direct security for
   these new uses but may be used to support them.  Documents that fall
   in this category include those describing the use of DNS in the
   storage and distribution of certificates ([RFC2538]).

11.  IANA Considerations

   This overview document introduces no new IANA considerations.  Please
   see [RFC4034] for a complete review of the IANA considerations
   introduced by DNSSEC.

12.  Security Considerations

   This document introduces DNS security extensions and describes the
   document set that contains the new security records and DNS protocol
   modifications.  The extensions provide data origin authentication and
   data integrity using digital signatures over resource record sets.
   This section discusses the limitations of these extensions.

   In order for a security-aware resolver to validate a DNS response,
   all zones along the path from the trusted starting point to the zone
   containing the response zones must be signed, and all name servers
   and resolvers involved in the resolution process must be
   security-aware, as defined in this document set.  A security-aware
   resolver cannot verify responses originating from an unsigned zone,
   from a zone not served by a security-aware name server, or for any
   DNS data that the resolver is only able to obtain through a recursive
   name server that is not security-aware.  If there is a break in the
   authentication chain such that a security-aware resolver cannot
   obtain and validate the authentication keys it needs, then the
   security-aware resolver cannot validate the affected DNS data.

   This document briefly discusses other methods of adding security to a
   DNS query, such as using a channel secured by IPsec or using a DNS
   transaction authentication mechanism such as TSIG ([RFC2845]) or
   SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
   per se.

   A non-validating security-aware stub resolver, by definition, does
   not perform DNSSEC signature validation on its own and thus is
   vulnerable both to attacks on (and by) the security-aware recursive
   name servers that perform these checks on its behalf and to attacks
   on its communication with those security-aware recursive name



Arends, et al.              Standards Track                    [Page 15]

RFC 4033       DNS Security Introduction and Requirements     March 2005


   servers.  Non-validating security-aware stub resolvers should use
   some form of channel security to defend against the latter threat.
   The only known defense against the former threat would be for the
   security-aware stub resolver to perform its own signature validation,
   at which point, again by definition, it would no longer be a
   non-validating security-aware stub resolver.

   DNSSEC does not protect against denial of service attacks.  DNSSEC
   makes DNS vulnerable to a new class of denial of service attacks
   based on cryptographic operations against security-aware resolvers
   and security-aware name servers, as an attacker can attempt to use
   DNSSEC mechanisms to consume a victim's resources.  This class of
   attacks takes at least two forms.  An attacker may be able to consume
   resources in a security-aware resolver's signature validation code by
   tampering with RRSIG RRs in response messages or by constructing
   needlessly complex signature chains.  An attacker may also be able to
   consume resources in a security-aware name server that supports DNS
   dynamic update, by sending a stream of update messages that force the
   security-aware name server to re-sign some RRsets in the zone more
   frequently than would otherwise be necessary.

   Due to a deliberate design choice, DNSSEC does not provide
   confidentiality.

   DNSSEC introduces the ability for a hostile party to enumerate all
   the names in a zone by following the NSEC chain.  NSEC RRs assert
   which names do not exist in a zone by linking from existing name to
   existing name along a canonical ordering of all the names within a
   zone.  Thus, an attacker can query these NSEC RRs in sequence to
   obtain all the names in a zone.  Although this is not an attack on
   the DNS itself, it could allow an attacker to map network hosts or
   other resources by enumerating the contents of a zone.

   DNSSEC introduces significant additional complexity to the DNS and
   thus introduces many new opportunities for implementation bugs and
   misconfigured zones.  In particular, enabling DNSSEC signature
   validation in a resolver may cause entire legitimate zones to become
   effectively unreachable due to DNSSEC configuration errors or bugs.