draft-ietf-dnsext-mdns-33.txt

bind 9.3结合mysql数据库

   These techniques are described in the following sections.

5.1.  Scope restriction

   With LLMNR it is possible that hosts will allocate conflicting names
   for a period of time, or that attackers will attempt to deny service
   to other hosts by allocating the same name. Such attacks also allow
   hosts to receive packets destined for other hosts.

   Since LLMNR is typically deployed in situations where no trust model
   can be assumed, it is likely that LLMNR queries and responses will be
   unauthenticated.  In the absence of authentication, LLMNR reduces the
   exposure to such threats by utilizing UDP queries sent to a link-
   scope multicast address, as well as setting the TTL (IPv4) or Hop
   Limit (IPv6) fields to one (1) on TCP queries and responses.

   Using a TTL of one (1) to set up a TCP connection in order to send a
   unicast LLMNR query reduces the likelihood of both denial of service
   attacks and spoofed responses.  Checking that an LLMNR query is sent
   to a link-scope multicast address should prevent spoofing of
   multicast queries by off-link attackers.

   While this limits the ability of off-link attackers to spoof LLMNR
   queries and responses, it does not eliminate it. For example, it is



Esibov, Aboba & Thaler       Standards Track                   [Page 20]





INTERNET-DRAFT                    LLMNR                     18 July 2004


   possible for an attacker to spoof a response to a frequent query
   (such as an A or AAAA query for a popular Internet host), and by
   using a TTL or Hop Limit field larger than one (1), for the forged
   response to reach the LLMNR sender.

   When LLMNR queries are sent to a link-scope multicast address, it is
   possible that some routers may not properly implement link-scope
   multicast, or that link-scope multicast addresses may leak into the
   multicast routing system.

   Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
   one in an LLMNR UDP response may enable denial of service attacks
   across the Internet.  However, since LLMNR responders only respond to
   queries for which they are authoritative, and LLMNR does not provide
   wildcard query support, it is believed that this threat is minimal.

   There also are scenarios such as public "hotspots" where attackers
   can be present on the same link.  These threats are most serious in
   wireless networks such as 802.11, since attackers on a wired network
   will require physical access to the home network, while wireless
   attackers may reside outside the home.  Link-layer security can be of
   assistance against these threats if it is available.

5.2.  Usage restriction

   As noted in Sections 2 and 3, LLMNR is intended for usage in a
   limited set of scenarios.

   If an LLMNR query is sent whenever a DNS server does not respond in a
   timely way, then an attacker can poison the LLMNR cache by responding
   to the query with incorrect information.  To some extent, these
   vulnerabilities exist today, since DNS response spoofing tools are
   available that can allow an attacker to respond to a query more
   quickly than a distant DNS server.

   Since LLMNR queries are sent and responded to on the local-link, an
   attacker will need to respond more quickly to provide its own
   response prior to arrival of the response from a legitimate
   responder. If an LLMNR query is sent for an off-link host, spoofing a
   response in a timely way is not difficult, since a legitimate
   response will never be received.

   The vulnerability is more serious if LLMNR is given higher priority
   than DNS among the enabled name resolution mechanisms. In such a
   configuration, a denial of service attack on the DNS server would not
   be necessary in order to poison the LLMNR cache, since LLMNR queries
   would be sent even when the DNS server is available. In addition, the
   LLMNR cache, once poisoned, would take precedence over the DNS cache,



Esibov, Aboba & Thaler       Standards Track                   [Page 21]





INTERNET-DRAFT                    LLMNR                     18 July 2004


   eliminating the benefits of cache separation. As a result, LLMNR is
   only used as a name resolution mechanism of last resort.

5.3.  Cache and port separation

   In order to prevent responses to LLMNR queries from polluting the DNS
   cache, LLMNR implementations MUST use a distinct, isolated cache for
   LLMNR on each interface. The use of separate caches is most effective
   when LLMNR is used as a name resolution mechanism of last resort,
   since this minimizes the opportunities for poisoning the LLMNR cache,
   and decreases reliance on it.

   LLMNR operates on a separate port from DNS, reducing the likelihood
   that a DNS server will unintentionally respond to an LLMNR query.

5.4.  Authentication

   LLMNR implementations may not support DNSSEC or TSIG, and as a
   result, responses to LLMNR queries may be unauthenticated.  If
   authentication is desired, and a pre-arranged security configuration
   is possible, then IPsec ESP with a null-transform MAY be used to
   authenticate LLMNR responses.  In a small network without a
   certificate authority, this can be most easily accomplished through
   configuration of a group pre-shared key for trusted hosts.

6.  IANA Considerations

   This specification creates one new name space:  the reserved bits in
   the LLMNR header.  These are allocated by IETF Consensus, in
   accordance with BCP 26 [RFC2434].

   LLMNR requires allocation of port 5355 for both TCP and UDP.

   LLMNR requires allocation of link-scope multicast IPv4 address
   224.0.0.252, as well as link-scope multicast IPv6 address
   FF02:0:0:0:0:0:1:3.

7.  References

7.1.  Normative References

[RFC1035] Mockapetris, P., "Domain Names - Implementation and
          Specification", RFC 1035, November 1987.

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
          April 1992.





Esibov, Aboba & Thaler       Standards Track                   [Page 22]





INTERNET-DRAFT                    LLMNR                     18 July 2004


[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 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.

[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
          2365, July 1998.

[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
          Architecture", RFC 2373, July 1998.

[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 2434, October
          1998.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
          (IPv6) Specification", RFC 2460, December 1998.

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

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

[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
          Timer", RFC 2988, November 2000.

7.2.  Informative References

[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
          Fixes", RFC 1536, October 1993.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
          March 1997.

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

[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
          RFC 2292, February 1998.

[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
          Socket Interface Extensions for IPv6", RFC 2553, March 1999.



Esibov, Aboba & Thaler       Standards Track                   [Page 23]





INTERNET-DRAFT                    LLMNR                     18 July 2004


[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
          2937, September 2000.

[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
          IPv6 (DHCPv6)", RFC 3315, July 2003.

[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
          Caching", IEEE/ACM Transactions on Networking, Volume 10,
          Number 5, pp. 589, October 2002.

[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
          unicast addresses to communicate with recursive DNS servers",
          Internet draft (work in progress), draft-ietf-ipv6-dns-
          discovery-07.txt, October 2002.

[IPV4Link]
          Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
          of IPv4 Link-Local Addresses", Internet draft (work in
          progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May
          2004.

[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
          Portable Operating System Interface (POSIX). Open Group
          Technical Standard: Base Specifications, Issue 6, December
          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin

[LLMNREnable]
          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
          in progress), draft-guttman-mdns-enable-02.txt, April 2002.

[NodeInfo]
          Crawford, M., "IPv6 Node Information Queries", Internet draft
          (work in progress), draft-ietf-ipn-gwg-icmp-name-
          lookups-09.txt, May 2002.

Acknowledgments

   This work builds upon original work done on multicast DNS by Bill
   Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
   grant #F30602-99-1-0523. The authors gratefully acknowledge their
   contribution to the current specification.  Constructive input has
   also been received from Mark Andrews, Stuart Cheshire, Randy Bush,
   Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik
   Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik
   Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill,
   Keith Moore and Markku Savela.





Esibov, Aboba & Thaler       Standards Track                   [Page 24]





INTERNET-DRAFT                    LLMNR                     18 July 2004


Authors' Addresses

   Levon Esibov
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: [e-mail]

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.





Esibov, Aboba & Thaler       Standards Track                   [Page 25]





INTERNET-DRAFT                    LLMNR                     18 July 2004


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.

Open Issues

   Open issues with this specification are tracked on the following web
   site:

   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html





























Esibov, Aboba & Thaler       Standards Track                   [Page 26]