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

bind-3.2.

Arends, et al.           Expires August 15, 2003               [Page 16]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


11. Security Considerations

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

   In order for a security-aware resolver to validate a DNS response,
   all of the intermediate zones must be signed, and all of the
   intermediate name servers 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 which the resolver is
   only able to obtain through a recursive name server which 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, but transaction security is not
   part of DNSSEC per se.

   A 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
   which perform these checks on its behalf and also to attacks on its
   communication with those security-aware recursive name servers.
   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 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 SIG 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 which supports DNS



Arends, et al.           Expires August 15, 2003               [Page 17]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


   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 add the ability for a hostile party to enumerate all the names
   in a zone by following the NXT chain.  NXT 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 NXT 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 does not provide confidentiality, due to a deliberate design
   choice.

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





























Arends, et al.           Expires August 15, 2003               [Page 18]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


12. Acknowledgements

   This document was created from the input and ideas of several members
   of the DNS Extensions Working Group.  The authors would like to
   acknowledge (in alphabetical order) the following people for their
   contributions and comments on this document:

     Derek Atkins
     Donald Eastlake
     Miek Gieben
     Olafur Gudmundsson
     Olaf Kolkman
     Ed Lewis
     Ted Lindgreen
     Bill Manning
     Brian Wellington



































Arends, et al.           Expires August 15, 2003               [Page 19]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


Normative References

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

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

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

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

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

   [6]   Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
         2930, September 2000.

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

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

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

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

   [11]  Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
         System", draft-ietf-dnsext-dns-threats-02 (work in progress),
         February 2002.

   [12]  Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK)
         Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in
         progress), December 2002.

   [13]  Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
         Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-
         records-02 (work in progress), November 2002.

   [14]  Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
         Modifications for the DNS Security Extensions", draft-ietf-
         dnsext-dnssec-protocol-00 (work in progress), October 2002.



Arends, et al.           Expires August 15, 2003               [Page 20]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


Informative References

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

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

   [17]  Schlyter, J., "Storing application public keys in the DNS",
         draft-schlyter-appkey-02 (work in progress), February 2002.

   [18]  Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext-
         dnssec-roadmap-06 (work in progress), November 2001.


Authors' Addresses

   Roy Arends
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   EMail: [e-mail]


   Rob Austein
   Internet Software Consortium
   40 Gavin Circle
   Reading, MA  01867
   USA

   EMail: [e-mail]


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

   EMail: [e-mail]









Arends, et al.           Expires August 15, 2003               [Page 21]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


   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 August 15, 2003               [Page 22]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Arends, et al.           Expires August 15, 2003               [Page 23]