draft-ietf-dnsext-mdns-43.txt

bind 源码 最新实现 linux/unix/windows平台

   separated name spaces.  It is not the intent of this document to
   address the issue of uniqueness of names within DNS.

4.4.  API Issues

   [RFC2553] provides an API which can partially solve the name
   ambiguity problem for applications written to use this API, since the
   sockaddr_in6 structure exposes the scope within which each scoped
   address exists, and this structure can be used for both IPv4 (using
   v4-mapped IPv6 addresses) and IPv6 addresses.

   Following the example in Figure 2, an application on 'myhost' issues
   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
   interfaces and the resolver library will return a list containing
   multiple addrinfo structures, each with an associated sockaddr_in6
   structure.  This list will thus contain the IPv4 and IPv6 addresses
   of both hosts responding to the name 'A'.  Link-local addresses will
   have a sin6_scope_id value that disambiguates which interface is used
   to reach the address.  Of course, to the application, Figures 2 and 3
   are still indistinguishable, but this API allows the application to
   communicate successfully with any address in the list.

5.  Security Considerations

   LLMNR is a peer-to-peer name resolution protocol designed for use on
   the local link.  While LLMNR limits the vulnerability of responders
   to off-link senders, it is possible for an off-link responder to
   reach a sender.

   In scenarios such as public "hotspots" 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 network, while wireless attackers may mount



Aboba, Thaler & Esibov       Standards Track                   [Page 22]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   attacks from a distance.  Link-layer security such as [IEEE-802.11i]
   can be of assistance against these threats if it is available.

   This section details security measures available to mitigate threats
   from on and off-link attackers.

5.1.  Denial of Service

   Attackers may take advantage of LLMNR conflict detection by
   allocating the same name, denying service to other LLMNR responders
   and possibly allowing an attacker to receive packets destined for
   other hosts.  By logging conflicts, LLMNR responders can provide
   forensic evidence of these attacks.

   An attacker may spoof LLMNR queries from a victim's address in order
   to mount a denial of service attack.  Responders setting the IPv6 Hop
   Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
   response may be able to reach the victim across the Internet.

   While LLMNR responders only respond to queries for which they are
   authoritative and LLMNR does not provide wildcard query support, an
   LLMNR response may be larger than the query, and an attacker can
   generate multiple responses to a query for a name used by multiple
   responders.  A sender may protect itself against unsolicited
   responses by silently discarding them as rapidly as possible.

5.2.  Spoofing

   LLMNR is designed to prevent reception of queries sent by an off-link
   attacker.  LLMNR requires that responders receiving UDP queries check
   that they are sent to a link-scope multicast address.  However, 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.  To prevent successful setup of TCP
   connections by an off-link sender, responders receiving a TCP SYN
   reply with a TCP SYN-ACK with TTL set to one (1).

   While it is difficult for an off-link attacker to send an LLMNR query
   to a responder,  it is possible for an off-link attacker to spoof a
   response to a 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.  Since the
   forged response will only be accepted if it contains a matching ID
   field, choosing a pseudo-random ID field within queries provides some
   protection against off-link responders.

   Since LLMNR queries can be sent when DNS server(s) do not respond, an
   attacker can execute a denial of service attack on the DNS server(s)



Aboba, Thaler & Esibov       Standards Track                   [Page 23]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   and then poison the LLMNR cache by responding to an LLMNR query with
   incorrect information.  As noted in "Threat Analysis of the Domain
   Name System (DNS)" [RFC3833] these threats also exist with DNS, since
   DNS response spoofing tools are available that can allow an attacker
   to respond to a query more quickly than a distant DNS server.
   However, while switched networks or link layer security may make it
   difficult for an on-link attacker to snoop unicast DNS queries,
   multicast LLMNR queries are propagated to all hosts on the link,
   making it possible for an on-link attacker to spoof LLMNR responses
   without having to guess the value of the ID field in the query.

   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.

   Limiting the situations in which LLMNR queries are sent, as described
   in Section 2, is the best protection against these attacks.  If LLMNR
   is given higher priority than DNS among the enabled name resolution
   mechanisms, 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, eliminating the benefits of cache separation.  As a result,
   LLMNR is only used as a name resolution mechanism of last resort.

5.3.  Authentication

   LLMNR is a peer-to-peer name resolution protocol, and as a result,
   it is often deployed in situations where no trust model can be
   assumed.  This makes it difficult to apply existing DNS security
   mechanisms to LLMNR.

   LLMNR does not support "delegated trust" (CD or AD bits).  As a
   result, unless LLMNR senders are DNSSEC aware, it is not feasible to
   use DNSSEC [RFC4033] with LLMNR.

   If authentication is desired, and a pre-arranged security
   configuration is possible, then the following security mechanisms may
   be used:

[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
     [RFC2931] security mechanisms. "DNS Name Service based on Secure
     Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
     the use of TSIG to secure LLMNR responses, based on group keys.




Aboba, Thaler & Esibov       Standards Track                   [Page 24]





INTERNET-DRAFT                    LLMNR                   29 August 2005


[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
     LLMNR queries and responses or LLMNR responses to multicast
     queries.  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.

   Where these mechanisms cannot be supported, responses to LLMNR
   queries may be unauthenticated.

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

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

   The following timing constants are used in this protocol; they are
   not intended to be user configurable.

      JITTER_INTERVAL      100 ms
      LLMNR_TIMEOUT        1 second (if set statically on all interfaces)
                           100 ms (IEEE 802 media, including IEEE 802.11)

8.  References

8.1.  Normative References

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



Aboba, Thaler & Esibov       Standards Track                   [Page 25]





INTERNET-DRAFT                    LLMNR                   29 August 2005


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

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

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
          August 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.

8.2.  Informative References

[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
          (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
          June 2005.

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

[IEEE-802.11i]
          Institute of Electrical and Electronics Engineers, "Supplement
          to Standard for Telecommunications and Information Exchange
          Between Systems - LAN/MAN Specific Requirements - Part 11:
          Wireless LAN Medium Access Control (MAC) and Physical Layer
          (PHY) Specifications: Specification for Enhanced Security",
          IEEE 802.11i, July 2004.



Aboba, Thaler & Esibov       Standards Track                   [Page 26]





INTERNET-DRAFT                    LLMNR                   29 August 2005


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

[LLMNRSec]
          Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
          Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
          2004, Phoenix Park, Korea, February 9-11, 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

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

[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
          Recommendations for Security", RFC 1750, December 1994.

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

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

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

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

[RFC2937] Smith, C., "The Name Servi