draft-ietf-dnsext-dnssec-intro-11.txt

bind 9.3结合mysql数据库

   not perform DNSSEC signature validation on its own, and thus is
   vulnerable both to attacks on (and by) the security-aware recursive
   name servers which perform these checks on its behalf and also to
   attacks on its communication with those security-aware recursive name
   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, since 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



Arends, et al.          Expires January 13, 2005               [Page 20]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


   consume resources in a security-aware name server which 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.

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

   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.  While not an attack on the DNS
   itself, this 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.

   DNSSEC does not protect against tampering with unsigned zone data.
   Non-authoritative data at zone cuts (glue and NS RRs in the parent
   zone) are not signed.  This does not pose a problem when validating
   the authentication chain, but does mean that the non-authoritative
   data itself is vulnerable to tampering during zone transfer
   operations.  Thus, while DNSSEC can provide data origin
   authentication and data integrity for RRsets, it cannot do so for
   zones, and other mechanisms must be used to protect zone transfer
   operations.

   Please see [I-D.ietf-dnsext-dnssec-records] and
   [I-D.ietf-dnsext-dnssec-protocol] for additional security
   considerations.















Arends, et al.          Expires January 13, 2005               [Page 21]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


13.  Acknowledgements

   This document was created from the input and ideas of the members of
   the DNS Extensions Working Group.  While explicitly listing everyone
   who has contributed during the decade during which DNSSEC has been
   under development would be an impossible task, the editors would
   particularly like to thank the following people for their
   contributions to and comments on this document set: Jaap Akkerhuis,
   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
   Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip
   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
   Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid,
   Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob
   Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and
   Suzanne Woolf.

   No doubt the above list is incomplete.  We apologize to anyone we
   left out.



























Arends, et al.          Expires January 13, 2005               [Page 22]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


14.  References

14.1  Normative References

   [I-D.ietf-dnsext-dnssec-protocol]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
              progress), May 2004.

   [I-D.ietf-dnsext-dnssec-records]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "Resource Records for DNS Security Extensions",
              draft-ietf-dnsext-dnssec-records-08 (work in progress),
              May 2004.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.

   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
              3225, December 2001.

   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
              message size requirements", RFC 3226, December 2001.

   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
              Resource Record (RR)", RFC 3445, December 2002.

14.2  Informative References

   [I-D.ietf-dnsext-dns-threats]
              Atkins, D. and R. Austein, "Threat Analysis Of The Domain
              Name System", draft-ietf-dnsext-dns-threats-07 (work in
              progress), April 2004.

   [I-D.ietf-dnsext-nsec-rdata]
              Schlyter, J., "DNSSEC NSEC RDATA Format",
              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
              2004.



Arends, et al.          Expires January 13, 2005               [Page 23]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
              April 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
              the Domain Name System (DNS)", RFC 2538, March 1999.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
              Signing Authority", RFC 3008, November 2000.

   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
              Status", RFC 3090, March 2001.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, September 2003.

   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
              Authenticated Data (AD) bit", RFC 3655, November 2003.

   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
              (RR)", RFC 3658, December 2003.

   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
              Signer", RFC 3755, April 2004.

   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
              Entry Point Flag", RFC 3757, April 2004.








Arends, et al.          Expires January 13, 2005               [Page 24]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


Authors' Addresses

   Roy Arends
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   EMail: [e-mail]


   Rob Austein
   Internet Systems Consortium
   950 Charter Street
   Redwood City, CA  94063
   USA

   EMail: [e-mail]


   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: [e-mail]


   Dan Massey
   USC Information Sciences Institute
   3811 N. Fairfax Drive
   Arlington, VA  22203
   USA

   EMail: [e-mail]


   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-8920
   USA

   EMail: [e-mail]






Arends, et al.          Expires January 13, 2005               [Page 25]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Arends, et al.          Expires January 13, 2005               [Page 26]