+++ /dev/null
-DNSEXT Working Group Levon Esibov\r
-INTERNET-DRAFT Bernard Aboba\r
-Category: Standards Track Dave Thaler\r
-<draft-ietf-dnsext-mdns-30.txt> Microsoft\r
-17 March 2004\r
-\r
-\r
-\r
- Linklocal Multicast Name Resolution (LLMNR)\r
-\r
-\r
-This document is an Internet-Draft and is in full conformance with all\r
-provisions of Section 10 of RFC 2026.\r
-\r
-\r
-Internet-Drafts are working documents of the Internet Engineering Task\r
-Force (IETF), its areas, and its working groups. Note that other groups\r
-may also distribute working documents as Internet-Drafts.\r
-\r
-\r
-Internet-Drafts are draft documents valid for a maximum of six months\r
-and may be updated, replaced, or obsoleted by other documents at any\r
-time. It is inappropriate to use Internet-Drafts as reference material\r
-or to cite them other than as "work in progress."\r
-\r
-\r
-The list of current Internet-Drafts can be accessed at\r
-http://www.ietf.org/ietf/1id-abstracts.txt\r
-\r
-\r
-The list of Internet-Draft Shadow Directories can be accessed at\r
-http://www.ietf.org/shadow.html.\r
-\r
-\r
-Copyright Notice\r
-\r
-\r
-Copyright (C) The Internet Society (2004). All Rights Reserved.\r
-\r
-\r
-Abstract\r
-\r
-\r
-Today, with the rise of home networking, there are an increasing number\r
-of ad-hoc networks operating without a Domain Name System (DNS) server.\r
-In order to allow name resolution in such environments, Link-Local\r
-Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all\r
-current and future DNS formats, types and classes, while operating on a\r
-separate port from DNS, and with a distinct resolver cache.\r
-\r
-\r
-The goal of LLMNR is to enable name resolution in scenarios in which\r
-conventional DNS name resolution is not possible. Since LLMNR only\r
-operates on the local link, it cannot be considered a substitute for\r
-DNS.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 1]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-Table of Contents\r
-\r
-\r
-1. Introduction .......................................... 3\r
- 1.1 Requirements .................................... 3\r
- 1.2 Terminology ..................................... 4\r
-2. Name resolution using LLMNR ........................... 4\r
- 2.1 LLMNR packet format ............................. 5\r
- 2.2 Sender behavior ................................. 8\r
- 2.3 Responder behavior .............................. 8\r
- 2.4 Unicast queries ................................. 10\r
- 2.5 Off-link detection .............................. 11\r
- 2.6 Responder responsibilities ...................... 12\r
- 2.7 Retransmission and jitter ....................... 12\r
- 2.8 DNS TTL ......................................... 13\r
- 2.9 Use of the authority and additional sections .... 13\r
-3. Usage model ........................................... 14\r
- 3.1 LLMNR configuration ............................. 15\r
-4. Conflict resolution ................................... 16\r
- 4.1 Considerations for multiple interfaces .......... 18\r
- 4.2 API issues ...................................... 19\r
-5. Security considerations ............................... 19\r
- 5.1 Scope restriction ............................... 20\r
- 5.2 Usage restriction ............................... 21\r
- 5.3 Cache and port separation ....................... 21\r
- 5.4 Authentication .................................. 22\r
-6. IANA considerations ................................... 22\r
-7. References ............................................ 22\r
- 7.1 Normative References ............................ 22\r
- 7.2 Informative References .......................... 23\r
-Acknowledgments .............................................. 24\r
-Authors' Addresses ........................................... 25\r
-Intellectual Property Statement .............................. 25\r
-Full Copyright Statement ..................................... 26\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 2]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-1. Introduction\r
-\r
-\r
-This document discusses Link Local Multicast Name Resolution (LLMNR),\r
-which utilizes the DNS packet format and supports all current and future\r
-DNS formats, types and classes. LLMNR operates on a separate port from\r
-the Domain Name System (DNS), with a distinct resolver cache.\r
-\r
-\r
-The goal of LLMNR is to enable name resolution in scenarios in which\r
-conventional DNS name resolution is not possible. These include\r
-scenarios in which hosts are not configured with the address of a DNS\r
-server, where configured DNS servers do not reply to a query, or where\r
-they respond with errors, as described in Section 2. Since LLMNR only\r
-operates on the local link, it cannot be considered a substitute for\r
-DNS.\r
-\r
-\r
-Link-scope multicast addresses are used to prevent propagation of LLMNR\r
-traffic across routers, potentially flooding the network. LLMNR queries\r
-can also be sent to a unicast address, as described in Section 2.4.\r
-\r
-\r
-Propagation of LLMNR packets on the local link is considered sufficient\r
-to enable name resolution in small networks. The assumption is that if\r
-a network has a gateway, then the network is able to provide DNS server\r
-configuration. Configuration issues are discussed in Section 3.1.\r
-\r
-\r
-In the future, it may be desirable to consider use of multicast name\r
-resolution with multicast scopes beyond the link-scope. This could\r
-occur if LLMNR deployment is successful, the need for multicast name\r
-resolution beyond the link-scope, or multicast routing becomes\r
-ubiquitous. For example, expanded support for multicast name resolution\r
-might be required for mobile ad-hoc networking scenarios, or where no\r
-DNS server is available that is authoritative for the names of local\r
-hosts, and can support dynamic DNS, such as in wireless hotspots.\r
-\r
-\r
-Once we have experience in LLMNR deployment in terms of administrative\r
-issues, usability and impact on the network, it will be possible to\r
-reevaluate which multicast scopes are appropriate for use with multicast\r
-name resolution.\r
-\r
-\r
-Service discovery in general, as well as discovery of DNS servers using\r
-LLMNR in particular, is outside of the scope of this document, as is\r
-name resolution over non-multicast capable media.\r
-\r
-\r
-1.1. Requirements\r
-\r
-\r
-In this document, several words are used to signify the requirements of\r
-the specification. These words are often capitalized. The key words\r
-"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD\r
-NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 3]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-interpreted as described in [RFC2119].\r
-\r
-\r
-1.2. Terminology\r
-\r
-\r
-This document assumes familiarity with DNS terminology defined in\r
-[RFC1035]. Other terminology used in this document includes:\r
-\r
-\r
-Positively Resolved\r
- Responses with RCODE set to zero are referred to in this document\r
- as "positively resolved".\r
-\r
-\r
-Routable Address\r
- An address other than a Link-Local address. This includes globally\r
- routable addresses, as well as private addresses.\r
-\r
-\r
-Reachable\r
- An address is considered reachable over a link if either an ARP or\r
- neighbor discovery cache entry exists for the address on the link.\r
-\r
-\r
-Responder\r
- A host that listens to LLMNR queries, and responds to those for\r
- which it is authoritative.\r
-\r
-\r
-Sender\r
- A host that sends an LLMNR query.\r
-\r
-\r
-2. Name resolution using LLMNR\r
-\r
-\r
-LLMNR is a peer-to-peer name resolution protocol that is not intended as\r
-a replacement for DNS. LLMNR queries are sent to and received on port\r
-TBD. IPv4 administratively scoped multicast usage is specified in\r
-"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope\r
-multicast address a given responder listens to, and to which a sender\r
-sends queries, is TBD. The IPv6 link-scope multicast address a given\r
-responder listens to, and to which a sender sends all queries, is TBD.\r
-\r
-\r
-Typically a host is configured as both an LLMNR sender and a responder.\r
-A host MAY be configured as a sender, but not a responder. However, a\r
-host configured as a responder MUST act as a sender to verify the\r
-uniqueness of names as described in Section 4. This document does not\r
-specify how names are chosen or configured. This may occur via any\r
-mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].\r
-\r
-\r
-LLMNR usage MAY be configured manually or automatically on a per\r
-interface basis. By default, LLMNR responders SHOULD be enabled on all\r
-interfaces, at all times. Enabling LLMNR for use in situations where a\r
-DNS server has been configured will result in a change in default\r
-behavior without a simultaneous update to configuration information.\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 4]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-Where this is considered undesirable, LLMNR SHOULD NOT be enabled by\r
-default, so that hosts will neither listen on the link-scope multicast\r
-address, nor will they send queries to that address.\r
-\r
-\r
-An LLMNR sender may send a request for any name. However, by default,\r
-LLMNR requests SHOULD be sent only when one of the following conditions\r
-are met:\r
-\r
-\r
-[1] No manual or automatic DNS configuration has been performed. If an\r
- interface has been configured with DNS server address(es), then\r
- LLMNR SHOULD NOT be used as the primary name resolution mechanism\r
- on that interface, although it MAY be used as a name resolution\r
- mechanism of last resort.\r
-\r
-\r
-[2] DNS servers do not respond.\r
-\r
-\r
-[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name\r
- Error) or RCODE=0, and an empty answer section.\r
-\r
-\r
-A typical sequence of events for LLMNR usage is as follows:\r
-\r
-\r
-[a] DNS servers are not configured or do not respond to a DNS query, or\r
- respond with RCODE=3, or RCODE=0 and an empty answer section.\r
-\r
-\r
-[b] An LLMNR sender sends an LLMNR query to the link-scope multicast\r
- address(es) defined in Section 2, unless a unicast query is\r
- indicated. A sender SHOULD send LLMNR queries for PTR RRs via\r
- unicast, as specified in Section 2.4.\r
-\r
-\r
-[c] A responder responds to this query only if it is authoritative for\r
- the domain name in the query. A responder responds to a multicast\r
- query by sending a unicast UDP response to the sender. Unicast\r
- queries are responded to as indicated in Section 2.4.\r
-\r
-\r
-[d] Upon reception of the response, the sender processes it.\r
-\r
-\r
-Further details of sender and responder behavior are provided in the\r
-sections that follow.\r
-\r
-\r
-2.1. LLMNR packet format\r
-\r
-\r
-LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for\r
-both queries and responses. LLMNR implementations SHOULD send UDP\r
-queries and responses only as large as are known to be permissible\r
-without causing fragmentation. When in doubt a maximum packet size of\r
-512 octets SHOULD be used. LLMNR implementations MUST accept UDP\r
-queries and responses as large as permitted by the link MTU.\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 5]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-2.1.1. LLMNR header format\r
-\r
-\r
-LLMNR queries and responses utilize the DNS header format defined in\r
-[RFC1035] with exceptions noted below:\r
-\r
-\r
- 1 1 1 1 1 1\r
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5\r
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
-| ID |\r
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
-|QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |\r
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
-| QDCOUNT |\r
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
-| ANCOUNT |\r
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
-| NSCOUNT |\r
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
-| ARCOUNT |\r
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+\r
-\r
-\r
-where:\r
-\r
-\r
-ID A 16 bit identifier assigned by the program that generates any kind\r
- of query. This identifier is copied from the query to the response\r
- and can be used by the sender to match responses to outstanding\r
- queries. The ID field in a query SHOULD be set to a pseudo-random\r
- value.\r
-\r
-\r
-QR A one bit field that specifies whether this message is an LLMNR\r
- query (0), or an LLMNR response (1).\r
-\r
-\r
-OPCODE\r
- A four bit field that specifies the kind of query in this message.\r
- This value is set by the originator of a query and copied into the\r
- response. This specification defines the behavior of standard\r
- queries and responses (opcode value of zero). Future\r
- specifications may define the use of other opcodes with LLMNR.\r
- LLMNR senders and responders MUST support standard queries (opcode\r
- value of zero). LLMNR queries with unsupported OPCODE values MUST\r
- be silently discarded by responders.\r
-\r
-\r
-TC TrunCation - specifies that this message was truncated due to\r
- length greater than that permitted on the transmission channel.\r
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored\r
- by an LLMNR responder. If the TC bit is set an LLMNR response,\r
- then the sender MAY use the response if it contains all necessary\r
- information, or the sender MAY discard the response and resend the\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 6]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
- LLMNR query over TCP using the unicast address of the responder as\r
- the destination address. See [RFC2181] and Section 2.4 of this\r
- specification for further discussion of the TC bit.\r
-\r
-\r
-Z Reserved for future use. Implementations of this specification\r
- MUST set these bits to zero in both queries and responses. If\r
- these bits are set in a LLMNR query or response, implementations of\r
- this specification MUST ignore them. Since reserved bits could\r
- conceivably be used for different purposes than in DNS,\r
- implementors are advised not to enable processing of these bits in\r
- an LLMNR implementation starting from a DNS code base.\r
-\r
-\r
-RCODE\r
- Response code -- this 4 bit field is set as part of LLMNR\r
- responses. In an LLMNR query, the RCODE MUST be zero, and is\r
- ignored by the responder. The response to a multicast LLMNR query\r
- MUST have RCODE set to zero. A sender MUST silently discard an\r
- LLMNR response with a non-zero RCODE sent in response to a\r
- multicast query.\r
-\r
-\r
- If an LLMNR responder is authoritative for the name in a multicast\r
- query, but an error is encountered, the responder SHOULD send an\r
- LLMNR response with an RCODE of zero, no RRs in the answer section,\r
- and the TC bit set. This will cause the query to be resent using\r
- TCP, and allow the inclusion of a non-zero RCODE in the response to\r
- the TCP query. Responding with the TC bit set is preferrable to\r
- not sending a response, since it enables errors to be diagnosed.\r
-\r
-\r
- Since LLMNR responders only respond to LLMNR queries for names for\r
- which they are authoritative, LLMNR responders MUST NOT respond\r
- with an RCODE of 3; instead, they should not respond at all.\r
-\r
-\r
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended\r
- RCODE values.\r
-\r
-\r
-QDCOUNT\r
- An unsigned 16 bit integer specifying the number of entries in the\r
- question section. A sender MUST place only one question into the\r
- question section of an LLMNR query. LLMNR responders MUST silently\r
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders\r
- MUST silently discard LLMNR responses with QDCOUNT not equal to\r
- one.\r
-\r
-\r
-ANCOUNT\r
- An unsigned 16 bit integer specifying the number of resource\r
- records in the answer section. LLMNR responders MUST silently\r
- discard LLMNR queries with ANCOUNT not equal to zero.\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 7]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-NSCOUNT\r
- An unsigned 16 bit integer specifying the number of name server\r
- resource records in the authority records section. Authority\r
- record section processing is described in Section 2.9.\r
-\r
-\r
-ARCOUNT\r
- An unsigned 16 bit integer specifying the number of resource\r
- records in the additional records section. Additional record\r
- section processing is described in Section 2.9.\r
-\r
-\r
-2.2. Sender behavior\r
-\r
-\r
-A sender may send an LLMNR query for any legal resource record type\r
-(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.\r
-\r
-\r
-As described in Section 2.4, a sender may also send a unicast query.\r
-Sections 2 and 3 describe the circumstances in which LLMNR queries may\r
-be sent.\r
-\r
-\r
-The sender MUST anticipate receiving no replies to some LLMNR queries,\r
-in the event that no responders are available within the link-scope or\r
-in the event no positive non-null responses exist for the transmitted\r
-query. If no positive response is received, a resolver treats it as a\r
-response that no records of the specified type and class exist for the\r
-specified name (it is treated the same as a response with RCODE=0 and an\r
-empty answer section).\r
-\r
-\r
-Since the responder may order the RRs in the response so as to indicate\r
-preference, the sender SHOULD preserve ordering in the response to the\r
-querying application.\r
-\r
-\r
-2.3. Responder behavior\r
-\r
-\r
-An LLMNR response MUST be sent to the sender via unicast.\r
-\r
-\r
-Upon configuring an IP address responders typically will synthesize\r
-corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR\r
-queries for these RRs. An SOA RR is synthesized only when a responder\r
-has another RR as well; the SOA RR MUST NOT be the only RR that a\r
-responder has. However, in general whether RRs are manually or\r
-automatically created is an implementation decision.\r
-\r
-\r
-For example, a host configured to have computer name "host1" and to be a\r
-member of the "example.com" domain, and with IPv4 address 10.1.1.1 and\r
-IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the\r
-following records:\r
-\r
-\r
-host1. IN A 10.1.1.1\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 8]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6\r
-\r
-\r
-host1.example.com. IN A 10.1.1.1\r
-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6\r
-\r
-\r
-1.1.1.10.in-addr.arpa. IN PTR host1.\r
-IN PTR host1.example.com.\r
-\r
-\r
-6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa\r
-IN PTR host1.\r
-IN PTR host1.example.com\r
-\r
-\r
-An LLMNR responder might be further manually configured with the name of\r
-a local mail server with an MX RR included in the "host1." and\r
-"host1.example.com." records.\r
-\r
-\r
-In responding to queries:\r
-\r
-\r
-[a] Responders MUST listen on UDP port TBD on the link-scope multicast\r
- address(es) defined in Section 2, and on UDP and TCP port TBD on\r
- the unicast address(es) that could be set as the source address(es)\r
- when the responder responds to the LLMNR query.\r
-\r
-\r
-[b] Responders MUST direct responses to the port from which the query\r
- was sent. When queries are received via TCP this is an inherent\r
- part of the transport protocol. For queries received by UDP the\r
- responder MUST take note of the source port and use that as the\r
- destination port in the response. Responses SHOULD always be sent\r
- from the port to which they were directed.\r
-\r
-\r
-[c] Responders MUST respond to LLMNR queries for names and addresses\r
- they are authoritative for. This applies to both forward and\r
- reverse lookups.\r
-\r
-\r
-[d] Responders MUST NOT respond to LLMNR queries for names they are not\r
- authoritative for.\r
-\r
-\r
-[e] Responders MUST NOT respond using cached data.\r
-\r
-\r
-[f] If a DNS server is running on a host that supports LLMNR, the DNS\r
- server MUST respond to LLMNR queries only for the RRSets relating\r
- to the host on which the server is running, but MUST NOT respond\r
- for other records for which the server is authoritative. DNS\r
- servers also MUST NOT send LLMNR queries in order to resolve DNS\r
- queries.\r
-\r
-\r
-[g] If a responder is authoritative for a name, it MAY respond with\r
- RCODE=0 and an empty answer section, if the type of query does not\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 9]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
- match a RR that the responder has.\r
-\r
-\r
-As an example, a host configured to respond to LLMNR queries for the\r
-name "foo.example.com." is authoritative for the name\r
-"foo.example.com.". On receiving an LLMNR query for an A RR with the\r
-name "foo.example.com." the host authoritatively responds with A RR(s)\r
-that contain IP address(es) in the RDATA of the resource record. If the\r
-responder has a AAAA RR, but no A RR, and an A RR query is received, the\r
-responder would respond with RCODE=0 and an empty answer section.\r
-\r
-\r
-In conventional DNS terminology a DNS server authoritative for a zone is\r
-authoritative for all the domain names under the zone apex except for\r
-the branches delegated into separate zones. Contrary to conventional\r
-DNS terminology, an LLMNR responder is authoritative only for the zone\r
-apex.\r
-\r
-\r
-For example the host "foo.example.com." is not authoritative for the\r
-name "child.foo.example.com." unless the host is configured with\r
-multiple names, including "foo.example.com." and\r
-"child.foo.example.com.". As a result, "foo.example.com." cannot reply\r
-to an LLMNR query for "child.foo.example.com." with RCODE=3\r
-(authoritative name error). The purpose of limiting the name authority\r
-scope of a responder is to prevent complications that could be caused by\r
-coexistence of two or more hosts with the names representing child and\r
-parent (or grandparent) nodes in the DNS tree, for example,\r
-"foo.example.com." and "child.foo.example.com.".\r
-\r
-\r
-In this example (unless this limitation is introduced) an LLMNR query\r
-for an A resource record for the name "child.foo.example.com." would\r
-result in two authoritative responses: RCODE=3 (authoritative name\r
-error) received from "foo.example.com.", and a requested A record - from\r
-"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled\r
-hosts could perform a dynamic update of the parent (or grandparent) zone\r
-with a delegation to a child zone. In this example a host\r
-"child.foo.example.com." would send a dynamic update for the NS and glue\r
-A record to "foo.example.com.", but this approach significantly\r
-complicates implementation of LLMNR and would not be acceptable for\r
-lightweight hosts.\r
-\r
-\r
-2.4. Unicast queries and responses\r
-\r
-\r
-Unicast queries SHOULD be sent when:\r
-\r
-\r
-[a] A sender repeats a query after it received a response with the TC\r
- bit set to the previous LLMNR multicast query, or\r
-\r
-\r
-[b] The sender queries for a PTR RR of a fully formed IP address within\r
- the "in-addr.arpa" or "ip6.arpa" zones.\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 10]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-A responder receiving a unicast query MUST send the response with a\r
-source address set to the destination address field of the IP header of\r
-the query causing the response.\r
-\r
-\r
-Unicast LLMNR queries MUST be sent using TCP. Senders MUST support\r
-sending TCP queries, and responders MUST support listening for TCP\r
-queries.\r
-\r
-\r
-Responses to TCP unicast LLMNR queries MUST be sent using TCP, using\r
-the same connection as the query. If the sender of a TCP query receives\r
-a response to that query not using TCP, the response MUST be silently\r
-discarded.\r
-\r
-\r
-Unicast UDP queries MUST be silently discarded.\r
-\r
-\r
-If TCP connection setup cannot be completed in order to send a unicast\r
-TCP query, this is treated as a response that no records of the\r
-specified type and class exist for the specified name (it is treated the\r
-same as a response with RCODE=0 and an empty answer section).\r
-\r
-\r
-2.5. "Off link" detection\r
-\r
-\r
-For IPv4, an "on link" address is defined as a link-local address\r
-[IPv4Link] or an address whose prefix belongs to a subnet on the local\r
-link. For IPv6 [RFC2460] an "on link" address is either a link-local\r
-address, defined in [RFC2373], or an address whose prefix belongs to a\r
-subnet on the local link.\r
-\r
-\r
-A sender MUST select a source address for LLMNR queries that is "on\r
-link". The destination address of an LLMNR query MUST be a link-scope\r
-multicast address or an "on link" unicast address.\r
-\r
-\r
-A responder MUST select a source address for responses that is "on\r
-link". The destination address of an LLMNR response MUST be an "on link"\r
-unicast address.\r
-\r
-\r
-On receiving an LLMNR query, the responder MUST check whether it was\r
-sent to a LLMNR multicast addresses defined in Section 2. If it was\r
-sent to another multicast address, then the query MUST be silently\r
-discarded.\r
-\r
-\r
-Section 2.4 discusses use of TCP for LLMNR queries and responses. In\r
-composing an LLMNR query using TCP, the sender MUST set the Hop Limit\r
-field in the IPv6 header and the TTL field in the IPv4 header of the\r
-response to one (1). The responder SHOULD set the TTL or Hop Limit\r
-settings on the TCP listen socket to one (1) so that SYN-ACK packets\r
-will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents\r
-an incoming connection from off-link since the sender will not receive a\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 11]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-SYN-ACK from the responder.\r
-\r
-\r
-For UDP queries and responses the Hop Limit field in the IPv6 header,\r
-and the TTL field in the IPV4 header MAY be set to any value. However,\r
-it is RECOMMENDED that the value 255 be used for compatibility with\r
-Apple Rendezvous.\r
-\r
-\r
-Implementation note:\r
-\r
-\r
- In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL\r
- socket options are used to set the TTL of outgoing unicast and\r
- multicast packets. The IP_RECVTTL socket option is available on some\r
- platforms to retrieve the IPv4 TTL of received packets with\r
- recvmsg(). [RFC2292] specifies similar options for setting and\r
- retrieving the IPv6 Hop Limit.\r
-\r
-\r
-2.6. Responder responsibilities\r
-\r
-\r
-It is the responsibility of the responder to ensure that RRs returned in\r
-LLMNR responses MUST only include values that are valid on the local\r
-interface, such as IPv4 or IPv6 addresses valid on the local link or\r
-names defended using the mechanism described in Section 4. In\r
-particular:\r
-\r
-\r
-[a] If a link-scope IPv6 address is returned in a AAAA RR, that address\r
- MUST be valid on the local link over which LLMNR is used.\r
-\r
-\r
-[b] If an IPv4 address is returned, it MUST be reachable through the\r
- link over which LLMNR is used.\r
-\r
-\r
-[c] If a name is returned (for example in a CNAME, MX or SRV RR), the\r
- name MUST be resolvable on the local link over which LLMNR is used.\r
-\r
-\r
-Routable addresses MUST be included first in the response, if available.\r
-This encourages use of routable address(es) for establishment of new\r
-connections.\r
-\r
-\r
-2.7. Retransmission and jitter\r
-\r
-\r
-An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine\r
-when to retransmit an LLMNR query and how long to collect responses to\r
-an LLMNR query.\r
-\r
-\r
-If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,\r
-then a sender MAY repeat the transmission of the query in order to\r
-assure that it was received by a host capable of responding to it.\r
-Retransmission of UDP queries SHOULD NOT be attempted more than 3 times.\r
-Where LLMNR queries are sent using TCP, retransmission is handled by the\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 12]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-transport layer.\r
-\r
-\r
-Because an LLMNR sender cannot know in advance if a query sent using\r
-multicast will receive no response, one response, or more than one\r
-response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect\r
-all possible responses, rather than considering the multicast query\r
-answered after the first response is received. A unicast query sender\r
-considers the query answered after the first response is received, so\r
-that it only waits for LLMNR_TIMEOUT if no response has been received.\r
-\r
-\r
-An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT\r
-for each transmission. It is suggested that the computation of\r
-LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries\r
-sent on the same interface.\r
-\r
-\r
-For example, the algorithms described in RFC 2988 [RFC2988] (including\r
-exponential backoff) compute an RTO, which is used as the value of\r
-LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO\r
-(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO\r
-(discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum\r
-RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).\r
-\r
-\r
-Recommended values are an initial RTO of 1 second, a minimum RTO of\r
-200ms, and a maximum RTO of 5 seconds. In order to avoid\r
-synchronization, the transmission of each LLMNR query and response\r
-SHOULD delayed by a time randomly selected from the interval 0 to 100\r
-ms. This delay MAY be avoided by responders responding with RRs which\r
-they have previously determined to be UNIQUE (see Section 4 for\r
-details).\r
-\r
-\r
-2.8. DNS TTL\r
-\r
-\r
-The responder should use a pre-configured TTL value in the records\r
-returned an LLMNR response. A default value of 30 seconds is\r
-RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc\r
-networks), the TTL value may need to be reduced.\r
-\r
-\r
-Due to the TTL minimalization necessary when caching an RRset, all TTLs\r
-in an RRset MUST be set to the same value.\r
-\r
-\r
-2.9. Use of the authority and additional sections\r
-\r
-\r
-Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a\r
-concept of delegation. In LLMNR, the NS resource record type may be\r
-stored and queried for like any other type, but it has no special\r
-delegation semantics as it does in the DNS. Responders MAY have NS\r
-records associated with the names for which they are authoritative, but\r
-they SHOULD NOT include these NS records in the authority sections of\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 13]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-responses.\r
-\r
-\r
-Responders SHOULD insert an SOA record into the authority section of a\r
-negative response, to facilitate negative caching as specified in\r
-[RFC2308]. The owner name of this SOA record MUST be equal to the query\r
-name.\r
-\r
-\r
-Responders SHOULD NOT perform DNS additional section processing, except\r
-as required for EDNS0 and DNSSEC.\r
-\r
-\r
-Senders MUST NOT cache RRs from the authority or additional section of a\r
-response as answers, though they may be used for other purposes such as\r
-negative caching.\r
-\r
-\r
-3. Usage model\r
-\r
-\r
-Since LLMNR is a secondary name resolution mechanism, its usage is in\r
-part determined by the behavior of DNS implementations. This document\r
-does not specify any changes to DNS resolver behavior, such as\r
-searchlist processing or retransmission/failover policy. However,\r
-robust DNS resolver implementations are more likely to avoid unnecessary\r
-LLMNR queries.\r
-\r
-\r
-As noted in [DNSPerf], even when DNS servers are configured, a\r
-significant fraction of DNS queries do not receive a response, or result\r
-in negative responses due to missing inverse mappings or NS records that\r
-point to nonexistent or inappropriate hosts. This has the potential to\r
-result in a large number of unnecessary LLMNR queries.\r
-\r
-\r
-[RFC1536] describes common DNS implementation errors and fixes. If the\r
-proposed fixes are implemented, unnecessary LLMNR queries will be\r
-reduced substantially, and so implementation of [RFC1536] is\r
-recommended.\r
-\r
-\r
-For example, [RFC1536] Section 1 describes issues with retransmission\r
-and recommends implementation of a retransmission policy based on round\r
-trip estimates, with exponential backoff. [RFC1536] Section 4 describes\r
-issues with failover, and recommends that resolvers try another server\r
-when they don't receive a response to a query. These policies are\r
-likely to avoid unnecessary LLMNR queries.\r
-\r
-\r
-[RFC1536] Section 3 describes zero answer bugs, which if addressed will\r
-also reduce unnecessary LLMNR queries.\r
-\r
-\r
-[RFC1536] Section 6 describes name error bugs and recommended searchlist\r
-processing that will reduce unnecessary RCODE=3 (authoritative name)\r
-errors, thereby also reducing unnecessary LLMNR queries.\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 14]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-3.1. LLMNR configuration\r
-\r
-\r
-Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is\r
-possible for a dual stack host to be configured with the address of a\r
-DNS server over IPv4, while remaining unconfigured with a DNS server\r
-suitable for use over IPv6.\r
-\r
-\r
-In these situations, a dual stack host will send AAAA queries to the\r
-configured DNS server over IPv4. However, an IPv6-only host\r
-unconfigured with a DNS server suitable for use over IPv6 will be unable\r
-to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms\r
-(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not\r
-all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration\r
-may be a common problem in the short term, and LLMNR may prove useful in\r
-enabling linklocal name resolution over IPv6.\r
-\r
-\r
-Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],\r
-IPv6-only hosts may not be configured with a DNS server. Where there is\r
-no DNS server authoritative for the name of a host or the authoritative\r
-DNS server does not support dynamic client update over IPv6 or\r
-DHCPv6-based dynamic update, then an IPv6-only host will not be able to\r
-do DNS dynamic update, and other hosts will not be able to resolve its\r
-name.\r
-\r
-\r
-For example, if the configured DNS server responds to AAAA RR queries\r
-sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then\r
-it will not be possible to resolve the names of IPv6-only hosts. In\r
-this situation, LLMNR over IPv6 can be used for local name resolution.\r
-\r
-\r
-Similarly, if a DHCPv4 server is available providing DNS server\r
-configuration, and DNS server(s) exist which are authoritative for the A\r
-RRs of local hosts and support either dynamic client update over IPv4 or\r
-DHCPv4-based dynamic update, then the names of local IPv4 hosts can be\r
-resolved over IPv4 without LLMNR. However, if no DNS server is\r
-authoritative for the names of local hosts, or the authoritative DNS\r
-server(s) do not support dynamic update, then LLMNR enables linklocal\r
-name resolution over IPv4.\r
-\r
-\r
-Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to\r
-configure LLMNR on an interface. The LLMNR Enable Option, described in\r
-[LLMNREnable], can be used to explicitly enable or disable use of LLMNR\r
-on an interface. The LLMNR Enable Option does not determine whether or\r
-in which order DNS itself is used for name resolution. The order in\r
-which various name resolution mechanisms should be used can be specified\r
-using the Name Service Search Option (NSSO) for DHCP [RFC2937], using\r
-the LLMNR Enable Option code carried in the NSSO data.\r
-\r
-\r
-It is possible that DNS configuration mechanisms will go in and out of\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 15]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-service. In these circumstances, it is possible for hosts within an\r
-administrative domain to be inconsistent in their DNS configuration.\r
-\r
-\r
-For example, where DHCP is used for configuring DNS servers, one or more\r
-DHCP servers can fail. As a result, hosts configured prior to the\r
-outage will be configured with a DNS server, while hosts configured\r
-after the outage will not. Alternatively, it is possible for the DNS\r
-configuration mechanism to continue functioning while configured DNS\r
-servers fail.\r
-\r
-\r
-Unless unconfigured hosts periodically retry configuration, an outage in\r
-the DNS configuration mechanism will result in hosts continuing to use\r
-LLMNR even once the outage is repaired. Since LLMNR only enables\r
-linklocal name resolution, this represents an unnecessary degradation in\r
-capabilities. As a result, it is recommended that hosts without a\r
-configured DNS server periodically attempt to obtain DNS configuration.\r
-For example, where DHCP is used for DNS configuration, [RFC2131]\r
-recommends a maximum retry interval of 64 seconds. In the absence of\r
-other guidance, a default retry interval of one (1) minute is\r
-RECOMMENDED.\r
-\r
-\r
-4. Conflict resolution\r
-\r
-\r
-The sender MUST anticipate receiving multiple replies to the same LLMNR\r
-query, in the event that several LLMNR enabled computers receive the\r
-query and respond with valid answers. When this occurs, the responses\r
-may first be concatenated, and then treated in the same manner that\r
-multiple RRs received from the same DNS server would; the sender\r
-perceives no inherent conflict in the receipt of multiple responses.\r
-\r
-\r
-There are some scenarios when multiple responders MAY respond to the\r
-same query. There are other scenarios when only one responder MAY\r
-respond to a query. Resource records for which the latter queries are\r
-submitted are referred as UNIQUE throughout this document. The\r
-uniqueness of a resource record depends on a nature of the name in the\r
-query and type of the query. For example it is expected that:\r
-\r
-\r
- - multiple hosts may respond to a query for an SRV type record\r
- - multiple hosts may respond to a query for an A or AAAA type\r
- record for a cluster name (assigned to multiple hosts in\r
- the cluster)\r
- - only a single host may respond to a query for an A or AAAA\r
- type record for a name.\r
-\r
-\r
-Every responder that responds to an LLMNR query AND includes a UNIQUE\r
-record in the response:\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 16]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-[1] MUST verify that there is no other host within the scope of the\r
- LLMNR query propagation that can return a resource record for the\r
- same name, type and class.\r
-\r
-\r
-[2] MUST NOT include a UNIQUE resource record in the response without\r
- having verified its uniqueness.\r
-\r
-\r
-Where a host is configured to issue LLMNR queries on more than one\r
-interface, each interface should have its own independent LLMNR cache.\r
-For each UNIQUE resource record in a given interface's configuration,\r
-the host MUST verify resource record uniqueness on that interface. To\r
-accomplish this, the host MUST send an LLMNR query for each UNIQUE\r
-resource record.\r
-\r
-\r
-By default, a host SHOULD be configured to behave as though all RRs are\r
-UNIQUE. Uniqueness verification is carried out when the host:\r
-\r
-\r
- - starts up or is rebooted\r
- - wakes from sleep (if the network interface was inactive during sleep)\r
- - is configured to respond to the LLMNR queries on an interface\r
- enabled for transmission and reception of IP traffic\r
- - is configured to respond to the LLMNR queries using additional\r
- UNIQUE resource records\r
- - detects that an interface is connected and is usable\r
- (e.g. an IEEE 802 hardware link-state change indicating\r
- that a cable was attached or completion of authentication\r
- (and if needed, association) with a wireless base station\r
- or adhoc network\r
-\r
-\r
-When a host that has a UNIQUE record receives an LLMNR query for that\r
-record, the host MUST respond. After the client receives a response, it\r
-MUST check whether the response arrived on an interface different from\r
-the one on which the query was sent. If the response arrives on a\r
-different interface, the client can use the UNIQUE resource record in\r
-response to LLMNR queries. If not, then it MUST NOT use the UNIQUE\r
-resource record in response to LLMNR queries.\r
-\r
-\r
-The name conflict detection mechanism doesn't prevent name conflicts\r
-when previously partitioned segments are connected by a bridge. In order\r
-to minimize the chance of conflicts in such a situation, it is\r
-recommended that steps be taken to ensure name uniqueness. For example,\r
-the name could be chosen randomly from a large pool of potential names,\r
-or the name could be assigned via a process designed to guarantee\r
-uniqueness.\r
-\r
-\r
-When name conflicts are detected, they SHOULD be logged. To detect\r
-duplicate use of a name, an administrator can use a name resolution\r
-utility which employs LLMNR and lists both responses and responders.\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 17]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-This would allow an administrator to diagnose behavior and potentially\r
-to intervene and reconfigure LLMNR responders who should not be\r
-configured to respond to the same name.\r
-\r
-\r
-4.1. Considerations for Multiple Interfaces\r
-\r
-\r
-A multi-homed host may elect to configure LLMNR on only one of its\r
-active interfaces. In many situations this will be adequate. However,\r
-should a host need to configure LLMNR on more than one of its active\r
-interfaces, there are some additional precautions it MUST take.\r
-Implementers who are not planning to support LLMNR on multiple\r
-interfaces simultaneously may skip this section.\r
-\r
-\r
-A multi-homed host checks the uniqueness of UNIQUE records as described\r
-in Section 4. The situation is illustrated in figure 1.\r
-\r
-\r
- ---------- ----------\r
- | | | |\r
- [A] [myhost] [myhost]\r
-\r
-\r
- Figure 1. Link-scope name conflict\r
-\r
-\r
-In this situation, the multi-homed myhost will probe for, and defend,\r
-its host name on both interfaces. A conflict will be detected on one\r
-interface, but not the other. The multi-homed myhost will not be able\r
-to respond with a host RR for "myhost" on the interface on the right\r
-(see Figure 1). The multi-homed host may, however, be configured to use\r
-the "myhost" name on the interface on the left.\r
-\r
-\r
-Since names are only unique per-link, hosts on different links could be\r
-using the same name. If an LLMNR client sends requests over multiple\r
-interfaces, and receives replies from more than one, the result returned\r
-to the client is defined by the implementation. The situation is\r
-illustrated in figure 2.\r
-\r
-\r
- ---------- ----------\r
- | | | |\r
- [A] [myhost] [A]\r
-\r
-\r
-\r
- Figure 2. Off-segment name conflict\r
-\r
-\r
-If host myhost is configured to use LLMNR on both interfaces, it will\r
-send LLMNR queries on both interfaces. When host myhost sends a query\r
-for the host RR for name "A" it will receive a response from hosts on\r
-both interfaces.\r
-\r
-\r
-Host myhost cannot distinguish between the situation shown in Figure 2,\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 18]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-and that shown in Figure 3 where no conflict exists.\r
-\r
-\r
- [A]\r
- | |\r
- ----- -----\r
- | |\r
- [myhost]\r
-\r
-\r
- Figure 3. Multiple paths to same host\r
-\r
-\r
-This illustrates that the proposed name conflict resolution mechanism\r
-does not support detection or resolution of conflicts between hosts on\r
-different links. This problem can also occur with unicast DNS when a\r
-multi-homed host is connected to two different networks with separated\r
-name spaces. It is not the intent of this document to address the issue\r
-of uniqueness of names within DNS.\r
-\r
-\r
-4.2. API issues\r
-\r
-\r
-[RFC2553] provides an API which can partially solve the name ambiguity\r
-problem for applications written to use this API, since the sockaddr_in6\r
-structure exposes the scope within which each scoped address exists, and\r
-this structure can be used for both IPv4 (using v4-mapped IPv6\r
-addresses) and IPv6 addresses.\r
-\r
-\r
-Following the example in Figure 2, an application on 'myhost' issues the\r
-request getaddrinfo("A", ...) with ai_family=AF_INET6 and\r
-ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both\r
-interfaces and the resolver library will return a list containing\r
-multiple addrinfo structures, each with an associated sockaddr_in6\r
-structure. This list will thus contain the IPv4 and IPv6 addresses of\r
-both hosts responding to the name 'A'. Link-local addresses will have a\r
-sin6_scope_id value that disambiguates which interface is used to reach\r
-the address. Of course, to the application, Figures 2 and 3 are still\r
-indistinguishable, but this API allows the application to communicate\r
-successfully with any address in the list.\r
-\r
-\r
-5. Security Considerations\r
-\r
-\r
-LLMNR is by nature a peer-to-peer name resolution protocol. It is\r
-therefore inherently more vulnerable than DNS, since existing DNS\r
-security mechanisms are difficult to apply to LLMNR. While tools exist\r
-to alllow an attacker to spoof a response to a DNS query, spoofing a\r
-response to an LLMNR query is easier since the query is sent to a link-\r
-scope multicast address, where every host on the logical link will be\r
-made aware of it.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 19]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-In order to address the security vulnerabilities, the following\r
-mechanisms are contemplated:\r
-\r
-\r
-[1] Scope restrictions.\r
-\r
-\r
-[2] Usage restrictions.\r
-\r
-\r
-[3] Cache and port separation.\r
-\r
-\r
-[4] Authentication.\r
-\r
-\r
-These techniques are described in the following sections.\r
-\r
-\r
-5.1. Scope restriction\r
-\r
-\r
-With LLMNR it is possible that hosts will allocate conflicting names for\r
-a period of time, or that attackers will attempt to deny service to\r
-other hosts by allocating the same name. Such attacks also allow hosts\r
-to receive packets destined for other hosts.\r
-\r
-\r
-Since LLMNR is typically deployed in situations where no trust model can\r
-be assumed, it is likely that LLMNR queries and responses will be\r
-unauthenticated. In the absence of authentication, LLMNR reduces the\r
-exposure to such threats by utilizing UDP queries sent to a link-scope\r
-multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)\r
-fields to one (1) on TCP queries and responses.\r
-\r
-\r
-Using a TTL of one (1) to set up a TCP connection in order to send a\r
-unicast LLMNR query reduces the likelihood of both denial of service\r
-attacks and spoofed responses. Checking that an LLMNR query is sent to\r
-a link-scope multicast address should prevent spoofing of multicast\r
-queries by off-link attackers.\r
-\r
-\r
-While this limits the ability of off-link attackers to spoof LLMNR\r
-queries and responses, it does not eliminate it. For example, it is\r
-possible for an attacker to spoof a response to a frequent query (such\r
-as an A or AAAA query for a popular Internet host), and by using a TTL\r
-or Hop Limit field larger than one (1), for the forged response to reach\r
-the LLMNR sender.\r
-\r
-\r
-When LLMNR queries are sent to a link-scope multicast address, it is\r
-possible that some routers may not properly implement link-scope\r
-multicast, or that link-scope multicast addresses may leak into the\r
-multicast routing system.\r
-\r
-\r
-Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one\r
-in an LLMNR UDP response may enable denial of service attacks across the\r
-Internet. However, since LLMNR responders only respond to queries for\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 20]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-which they are authoritative, and LLMNR does not provide wildcard query\r
-support, it is believed that this threat is minimal.\r
-\r
-\r
-There also are scenarios such as public "hotspots" where attackers can\r
-be present on the same link. These threats are most serious in wireless\r
-networks such as 802.11, since attackers on a wired network will require\r
-physical access to the home network, while wireless attackers may reside\r
-outside the home. Link-layer security can be of assistance against\r
-these threats if it is available.\r
-\r
-\r
-5.2. Usage restriction\r
-\r
-\r
-As noted in Sections 2 and 3, LLMNR is intended for usage in a limited\r
-set of scenarios.\r
-\r
-\r
-If an LLMNR query is sent whenever a DNS server does not respond in a\r
-timely way, then an attacker can poison the LLMNR cache by responding to\r
-the query with incorrect information. To some extent, these\r
-vulnerabilities exist today, since DNS response spoofing tools are\r
-available that can allow an attacker to respond to a query more quickly\r
-than a distant DNS server.\r
-\r
-\r
-Since LLMNR queries are sent and responded to on the local-link, an\r
-attacker will need to respond more quickly to provide its own response\r
-prior to arrival of the response from a legitimate responder. If an\r
-LLMNR query is sent for an off-link host, spoofing a response in a\r
-timely way is not difficult, since a legitimate response will never be\r
-received.\r
-\r
-\r
-The vulnerability is more serious if LLMNR is given higher priority than\r
-DNS among the enabled name resolution mechanisms. In such a\r
-configuration, a denial of service attack on the DNS server would not be\r
-necessary in order to poison the LLMNR cache, since LLMNR queries would\r
-be sent even when the DNS server is available. In addition, the LLMNR\r
-cache, once poisoned, would take precedence over the DNS cache,\r
-eliminating the benefits of cache separation. As a result, LLMNR is only\r
-used as a name resolution mechanism of last resort.\r
-\r
-\r
-5.3. Cache and port separation\r
-\r
-\r
-In order to prevent responses to LLMNR queries from polluting the DNS\r
-cache, LLMNR implementations MUST use a distinct, isolated cache for\r
-LLMNR on each interface. The use of separate caches is most effective\r
-when LLMNR is used as a name resolution mechanism of last resort, since\r
-this minimizes the opportunities for poisoning the LLMNR cache, and\r
-decreases reliance on it.\r
-\r
-\r
-LLMNR operates on a separate port from DNS, reducing the likelihood that\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 21]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-a DNS server will unintentionally respond to an LLMNR query.\r
-\r
-\r
-5.4. Authentication\r
-\r
-\r
-LLMNR implementations may not support DNSSEC or TSIG, and as a result,\r
-responses to LLMNR queries may be unauthenticated. If authentication is\r
-desired, and a pre-arranged security configuration is possible, then\r
-IPsec ESP with a null-transform MAY be used to authenticate LLMNR\r
-responses. In a small network without a certificate authority, this can\r
-be most easily accomplished through configuration of a group pre-shared\r
-key for trusted hosts.\r
-\r
-\r
-6. IANA Considerations\r
-\r
-\r
-This specification creates one new name space: the reserved bits in the\r
-LLMNR header. These are allocated by IETF Consensus, in accordance with\r
-BCP 26 [RFC2434].\r
-\r
-\r
-LLMNR requires allocation of a port TBD for both TCP and UDP.\r
-Assignment of the same port for both transports is requested.\r
-\r
-\r
-LLMNR requires allocation of a link-scope multicast IPv4 address TBD.\r
-LLMNR also requires allocation of a link-scope multicast IPv6 address\r
-TBD.\r
-\r
-\r
-7. References\r
-\r
-\r
-7.1. Normative References\r
-\r
-\r
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and\r
- Specification", RFC 1035, November 1987.\r
-\r
-\r
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,\r
- April 1992.\r
-\r
-\r
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
- Requirement Levels", BCP 14, RFC 2119, March 1997.\r
-\r
-\r
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS\r
- Specification", RFC 2181, July 1997.\r
-\r
-\r
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",\r
- RFC 2308, March 1998.\r
-\r
-\r
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC\r
- 2365, July 1998.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 22]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing\r
- Architecture", RFC 2373, July 1998.\r
-\r
-\r
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA\r
- Considerations Section in RFCs", BCP 26, RFC 2434, October\r
- 1998.\r
-\r
-\r
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6\r
- (IPv6) Specification", RFC 2460, December 1998.\r
-\r
-\r
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC\r
- 2535, March 1999.\r
-\r
-\r
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,\r
- August 1999.\r
-\r
-\r
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission\r
- Timer", RFC 2988, November 2000.\r
-\r
-\r
-7.2. Informative References\r
-\r
-\r
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested\r
- Fixes", RFC 1536, October 1993.\r
-\r
-\r
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,\r
- March 1997.\r
-\r
-\r
-[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic\r
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,\r
- April 1997.\r
-\r
-\r
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",\r
- RFC 2292, February 1998.\r
-\r
-\r
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic\r
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.\r
-\r
-\r
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC\r
- 2937, September 2000.\r
-\r
-\r
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for\r
- IPv6 (DHCPv6)", RFC 3315, July 2003.\r
-\r
-\r
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of\r
- Caching", IEEE/ACM Transactions on Networking, Volume 10,\r
- Number 5, pp. 589, October 2002.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 23]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local\r
- unicast addresses to communicate with recursive DNS servers",\r
- Internet draft (work in progress), draft-ietf-ipv6-dns-\r
- discovery-07.txt, October 2002.\r
-\r
-\r
-[IPV4Link]\r
- Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration\r
- of IPv4 Link-Local Addresses", Internet draft (work in\r
- progress), draft-ietf-zeroconf-ipv4-linklocal-14.txt, April\r
- 2004.\r
-\r
-\r
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --\r
- Portable Operating System Interface (POSIX). Open Group\r
- Technical Standard: Base Specifications, Issue 6, December\r
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin\r
-\r
-\r
-[LLMNREnable]\r
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work\r
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.\r
-\r
-\r
-[NodeInfo]\r
- Crawford, M., "IPv6 Node Information Queries", Internet draft\r
- (work in progress), draft-ietf-ipn-gwg-icmp-name-\r
- lookups-09.txt, May 2002.\r
-\r
-\r
-Acknowledgments\r
-\r
-\r
-This work builds upon original work done on multicast DNS by Bill\r
-Manning and Bill Woodcock. Bill Manning's work was funded under DARPA\r
-grant #F30602-99-1-0523. The authors gratefully acknowledge their\r
-contribution to the current specification. Constructive input has also\r
-been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert\r
-Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron\r
-Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-\r
-Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku\r
-Savela.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 24]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-Authors' Addresses\r
-\r
-\r
-Levon Esibov\r
-Microsoft Corporation\r
-One Microsoft Way\r
-Redmond, WA 98052\r
-\r
-\r
-EMail: levone@microsoft.com\r
-\r
-\r
-Bernard Aboba\r
-Microsoft Corporation\r
-One Microsoft Way\r
-Redmond, WA 98052\r
-\r
-\r
-Phone: +1 425 706 6605\r
-EMail: bernarda@microsoft.com\r
-\r
-\r
-Dave Thaler\r
-Microsoft Corporation\r
-One Microsoft Way\r
-Redmond, WA 98052\r
-\r
-\r
-Phone: +1 425 703 8835\r
-EMail: dthaler@microsoft.com\r
-\r
-\r
-Intellectual Property Statement\r
-\r
-\r
-The IETF takes no position regarding the validity or scope of any\r
-intellectual property or other rights that might be claimed to pertain\r
-to the implementation or use of the technology described in this\r
-document or the extent to which any license under such rights might or\r
-might not be available; neither does it represent that it has made any\r
-effort to identify any such rights. Information on the IETF's\r
-procedures with respect to rights in standards-track and standards-\r
-related documentation can be found in BCP-11. Copies of claims of\r
-rights made available for publication and any assurances of licenses to\r
-be made available, or the result of an attempt made to obtain a general\r
-license or permission for the use of such proprietary rights by\r
-implementors or users of this specification can be obtained from the\r
-IETF Secretariat.\r
-\r
-\r
-The IETF invites any interested party to bring to its attention any\r
-copyrights, patents or patent applications, or other proprietary rights\r
-which may cover technology that may be required to practice this\r
-standard. Please address the information to the IETF Executive\r
-Director.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 25]\r
-\r
-\r
-\r
-\r
-\r
-\r
-INTERNET-DRAFT LLMNR 17 March 2004\r
-\r
-\r
-\r
-Full Copyright Statement\r
-\r
-\r
-Copyright (C) The Internet Society (2004). All Rights Reserved.\r
-This document and translations of it may be copied and furnished to\r
-others, and derivative works that comment on or otherwise explain it or\r
-assist in its implementation may be prepared, copied, published and\r
-distributed, in whole or in part, without restriction of any kind,\r
-provided that the above copyright notice and this paragraph are included\r
-on all such copies and derivative works. However, this document itself\r
-may not be modified in any way, such as by removing the copyright notice\r
-or references to the Internet Society or other Internet organizations,\r
-except as needed for the purpose of developing Internet standards in\r
-which case the procedures for copyrights defined in the Internet\r
-Standards process must be followed, or as required to translate it into\r
-languages other than English. The limited permissions granted above are\r
-perpetual and will not be revoked by the Internet Society or its\r
-successors or assigns. This document and the information contained\r
-herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE\r
-INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR\r
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE\r
-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-\r
-Open Issues\r
-\r
-\r
-Open issues with this specification are tracked on the following web\r
-site:\r
-\r
-\r
-http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html\r
-\r
-\r
-Expiration Date\r
-\r
-\r
-This memo is filed as <draft-ietf-dnsext-mdns-30.txt>, and expires\r
-October 4, 2004.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Esibov, Aboba & Thaler Standards Track [Page 26]
\ No newline at end of file
projects / thirdparty / bind9.git / commitdiff
