+++ /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
--- /dev/null
+
+
+
+
+
+
+DNSEXT Working Group Levon Esibov
+INTERNET-DRAFT Bernard Aboba
+Category: Standards Track Dave Thaler
+<draft-ietf-dnsext-mdns-32.txt> Microsoft
+25 June 2004
+
+
+ Linklocal Multicast Name Resolution (LLMNR)
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3667.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on November 22, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ Today, with the rise of home networking, there are an increasing
+ number of ad-hoc networks operating without a Domain Name System
+ (DNS) server. The goal of Link-Local Multicast Name Resolution
+ (LLMNR) is to enable name resolution in scenarios in which
+ conventional DNS name resolution is not possible. LLMNR supports all
+ current and future DNS formats, types and classes, while operating on
+ a separate port from DNS, and with a distinct resolver cache. Since
+ LLMNR only operates on the local link, it cannot be considered a
+ substitute for DNS.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 1]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+Table of Contents
+
+1. Introduction .......................................... 3
+ 1.1 Requirements .................................... 4
+ 1.2 Terminology ..................................... 4
+2. Name resolution using LLMNR ........................... 4
+ 2.1 LLMNR packet format ............................. 6
+ 2.2 Sender behavior ................................. 8
+ 2.3 Responder behavior .............................. 8
+ 2.4 Unicast queries ................................. 11
+ 2.5 Off-link detection .............................. 11
+ 2.6 Responder responsibilities ...................... 12
+ 2.7 Retransmission and jitter ....................... 13
+ 2.8 DNS TTL ......................................... 13
+ 2.9 Use of the authority and additional sections .... 14
+3. Usage model ........................................... 14
+ 3.1 LLMNR configuration ............................. 15
+4. Conflict resolution ................................... 16
+ 4.1 Considerations for multiple interfaces .......... 18
+ 4.2 API issues ...................................... 19
+5. Security considerations ............................... 20
+ 5.1 Scope restriction ............................... 20
+ 5.2 Usage restriction ............................... 21
+ 5.3 Cache and port separation ....................... 22
+ 5.4 Authentication .................................. 22
+6. IANA considerations ................................... 22
+7. References ............................................ 22
+ 7.1 Normative References ............................ 22
+ 7.2 Informative References .......................... 23
+Acknowledgments .............................................. 24
+Authors' Addresses ........................................... 25
+Intellectual Property Statement .............................. 25
+Full Copyright Statement ..................................... 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 2]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+1. Introduction
+
+ This document discusses Link Local Multicast Name Resolution (LLMNR),
+ which utilizes the DNS packet format and supports all current and
+ future DNS formats, types and classes. LLMNR operates on a separate
+ port from the Domain Name System (DNS), with a distinct resolver
+ cache.
+
+ The goal of LLMNR is to enable name resolution in scenarios in which
+ conventional DNS name resolution is not possible. These include
+ scenarios in which hosts are not configured with the address of a DNS
+ server, where configured DNS servers do not reply to a query, or
+ where they respond with errors, as described in Section 2. Since
+ LLMNR only operates on the local link, it cannot be considered a
+ substitute for DNS.
+
+ Link-scope multicast addresses are used to prevent propagation of
+ LLMNR traffic across routers, potentially flooding the network.
+ LLMNR queries can also be sent to a unicast address, as described in
+ Section 2.4.
+
+ Propagation of LLMNR packets on the local link is considered
+ sufficient to enable name resolution in small networks. The
+ assumption is that if a network has a gateway, then the network is
+ able to provide DNS server configuration. Configuration issues are
+ discussed in Section 3.1.
+
+ In the future, it may be desirable to consider use of multicast name
+ resolution with multicast scopes beyond the link-scope. This could
+ occur if LLMNR deployment is successful, the need arises for
+ multicast name resolution beyond the link-scope, or multicast routing
+ becomes ubiquitous. For example, expanded support for multicast name
+ resolution might be required for mobile ad-hoc networking scenarios,
+ or where no DNS server is available that is authoritative for the
+ names of local hosts, and can support dynamic DNS, such as in
+ wireless hotspots.
+
+ Once we have experience in LLMNR deployment in terms of
+ administrative issues, usability and impact on the network, it will
+ be possible to reevaluate which multicast scopes are appropriate for
+ use with multicast name resolution.
+
+ Service discovery in general, as well as discovery of DNS servers
+ using LLMNR in particular, is outside of the scope of this document,
+ as is name resolution over non-multicast capable media.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 3]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+1.1. Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+1.2. Terminology
+
+ This document assumes familiarity with DNS terminology defined in
+ [RFC1035]. Other terminology used in this document includes:
+
+Positively Resolved
+ Responses with RCODE set to zero are referred to in this document
+ as "positively resolved".
+
+Routable Address
+ An address other than a Link-Local address. This includes globally
+ routable addresses, as well as private addresses.
+
+Reachable
+ An address is considered reachable over a link if either an ARP or
+ neighbor discovery cache entry exists for the address on the link.
+
+Responder
+ A host that listens to LLMNR queries, and responds to those for
+ which it is authoritative.
+
+Sender
+ A host that sends an LLMNR query.
+
+2. Name resolution using LLMNR
+
+ LLMNR is a peer-to-peer name resolution protocol that is not intended
+ as a replacement for DNS. LLMNR queries are sent to and received on
+ port 5355. IPv4 administratively scoped multicast usage is specified
+ in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-
+ scope multicast address a given responder listens to, and to which a
+ sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
+ address a given responder listens to, and to which a sender sends all
+ queries, is FF02:0:0:0:0:0:1:3.
+
+ Typically a host is configured as both an LLMNR sender and a
+ responder. A host MAY be configured as a sender, but not a
+ responder. However, a host configured as a responder MUST act as a
+ sender to verify the uniqueness of names as described in Section 4.
+ This document does not specify how names are chosen or configured.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 4]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ This may occur via any mechanism, including DHCPv4 [RFC2131] or
+ DHCPv6 [RFC3315].
+
+ LLMNR usage MAY be configured manually or automatically on a per
+ interface basis. By default, LLMNR responders SHOULD be enabled on
+ all interfaces, at all times. Enabling LLMNR for use in situations
+ where a DNS server has been configured will result in a change in
+ default behavior without a simultaneous update to configuration
+ information. Where this is considered undesirable, LLMNR SHOULD NOT
+ be enabled by default, so that hosts will neither listen on the link-
+ scope multicast address, nor will they send queries to that address.
+
+ An LLMNR sender may send a request for any name. However, by
+ default, LLMNR requests SHOULD be sent only when one of the following
+ conditions are met:
+
+ [1] No manual or automatic DNS configuration has been
+ performed. If an interface has been configured with DNS
+ server address(es), then LLMNR SHOULD NOT be used as the
+ primary name resolution mechanism on that interface, although
+ it MAY be used as a name resolution mechanism of last resort.
+
+ [2] DNS servers do not respond.
+
+ [3] DNS servers respond to a DNS query with RCODE=3
+ (Authoritative Name Error) or RCODE=0, and an empty
+ answer section.
+
+ A typical sequence of events for LLMNR usage is as follows:
+
+ [a] DNS servers are not configured or do not respond to a
+ DNS query, or respond with RCODE=3, or RCODE=0 and an
+ empty answer section.
+
+ [b] An LLMNR sender sends an LLMNR query to the link-scope
+ multicast address(es) defined in Section 2, unless a
+ unicast query is indicated. A sender SHOULD send LLMNR
+ queries for PTR RRs via unicast, as specified in Section 2.4.
+
+ [c] A responder responds to this query only if it is authoritative
+ for the domain name in the query. A responder responds to a
+ multicast query by sending a unicast UDP response to the sender.
+ Unicast queries are responded to as indicated in Section 2.4.
+
+ [d] Upon reception of the response, the sender processes it.
+
+ Further details of sender and responder behavior are provided in the
+ sections that follow.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 5]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+2.1. LLMNR packet format
+
+ LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
+ for both queries and responses. LLMNR implementations SHOULD send
+ UDP queries and responses only as large as are known to be
+ permissible without causing fragmentation. When in doubt a maximum
+ packet size of 512 octets SHOULD be used. LLMNR implementations MUST
+ accept UDP queries and responses as large as permitted by the link
+ MTU.
+
+2.1.1. LLMNR header format
+
+ LLMNR queries and responses utilize the DNS header format defined in
+ [RFC1035] with exceptions noted below:
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ID |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QDCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ANCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | NSCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ARCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ where:
+
+ID A 16 bit identifier assigned by the program that generates any kind
+ of query. This identifier is copied from the query to the response
+ and can be used by the sender to match responses to outstanding
+ queries. The ID field in a query SHOULD be set to a pseudo-random
+ value.
+
+QR A one bit field that specifies whether this message is an LLMNR
+ query (0), or an LLMNR response (1).
+
+OPCODE
+ A four bit field that specifies the kind of query in this message.
+ This value is set by the originator of a query and copied into the
+ response. This specification defines the behavior of standard
+ queries and responses (opcode value of zero). Future
+ specifications may define the use of other opcodes with LLMNR.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 6]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ LLMNR senders and responders MUST support standard queries (opcode
+ value of zero). LLMNR queries with unsupported OPCODE values MUST
+ be silently discarded by responders.
+
+TC TrunCation - specifies that this message was truncated due to
+ length greater than that permitted on the transmission channel.
+ The TC bit MUST NOT be set in an LLMNR query and if set is ignored
+ by an LLMNR responder. If the TC bit is set an LLMNR response,
+ then the sender MAY use the response if it contains all necessary
+ information, or the sender MAY discard the response and resend the
+ LLMNR query over TCP using the unicast address of the responder as
+ the destination address. See [RFC2181] and Section 2.4 of this
+ specification for further discussion of the TC bit.
+
+Z Reserved for future use. Implementations of this specification
+ MUST set these bits to zero in both queries and responses. If
+ these bits are set in a LLMNR query or response, implementations of
+ this specification MUST ignore them. Since reserved bits could
+ conceivably be used for different purposes than in DNS,
+ implementors are advised not to enable processing of these bits in
+ an LLMNR implementation starting from a DNS code base.
+
+RCODE
+ Response code -- this 4 bit field is set as part of LLMNR
+ responses. In an LLMNR query, the RCODE MUST be zero, and is
+ ignored by the responder. The response to a multicast LLMNR query
+ MUST have RCODE set to zero. A sender MUST silently discard an
+ LLMNR response with a non-zero RCODE sent in response to a
+ multicast query.
+
+ If an LLMNR responder is authoritative for the name in a multicast
+ query, but an error is encountered, the responder SHOULD send an
+ LLMNR response with an RCODE of zero, no RRs in the answer section,
+ and the TC bit set. This will cause the query to be resent using
+ TCP, and allow the inclusion of a non-zero RCODE in the response to
+ the TCP query. Responding with the TC bit set is preferrable to
+ not sending a response, since it enables errors to be diagnosed.
+
+ Since LLMNR responders only respond to LLMNR queries for names for
+ which they are authoritative, LLMNR responders MUST NOT respond
+ with an RCODE of 3; instead, they should not respond at all.
+
+ LLMNR implementations MUST support EDNS0 [RFC2671] and extended
+ RCODE values.
+
+QDCOUNT
+ An unsigned 16 bit integer specifying the number of entries in the
+ question section. A sender MUST place only one question into the
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 7]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ question section of an LLMNR query. LLMNR responders MUST silently
+ discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
+ MUST silently discard LLMNR responses with QDCOUNT not equal to
+ one.
+
+ANCOUNT
+ An unsigned 16 bit integer specifying the number of resource
+ records in the answer section. LLMNR responders MUST silently
+ discard LLMNR queries with ANCOUNT not equal to zero.
+
+NSCOUNT
+ An unsigned 16 bit integer specifying the number of name server
+ resource records in the authority records section. Authority
+ record section processing is described in Section 2.9.
+
+ARCOUNT
+ An unsigned 16 bit integer specifying the number of resource
+ records in the additional records section. Additional record
+ section processing is described in Section 2.9.
+
+2.2. Sender behavior
+
+ A sender may send an LLMNR query for any legal resource record type
+ (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.
+
+ As described in Section 2.4, a sender may also send a unicast query.
+ Sections 2 and 3 describe the circumstances in which LLMNR queries
+ may be sent.
+
+ The sender MUST anticipate receiving no replies to some LLMNR
+ queries, in the event that no responders are available within the
+ link-scope or in the event no positive non-null responses exist for
+ the transmitted query. If no positive response is received, a
+ resolver treats it as a response that no records of the specified
+ type and class exist for the specified name (it is treated the same
+ as a response with RCODE=0 and an empty answer section).
+
+ Since the responder may order the RRs in the response so as to
+ indicate preference, the sender SHOULD preserve ordering in the
+ response to the querying application.
+
+2.3. Responder behavior
+
+ An LLMNR response MUST be sent to the sender via unicast.
+
+ Upon configuring an IP address responders typically will synthesize
+ corresponding A, AAAA and PTR RRs so as to be able to respond to
+ LLMNR queries for these RRs. An SOA RR is synthesized only when a
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 8]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ responder has another RR as well; the SOA RR MUST NOT be the only RR
+ that a responder has. However, in general whether RRs are manually
+ or automatically created is an implementation decision.
+
+ For example, a host configured to have computer name "host1" and to
+ be a member of the "example.com" domain, and with IPv4 address
+ 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
+ authoritative for the following records:
+
+ host1. IN A 10.1.1.1
+ IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+ host1.example.com. IN A 10.1.1.1
+ IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+ 1.1.1.10.in-addr.arpa. IN PTR host1.
+ IN PTR host1.example.com.
+
+ 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
+ IN PTR host1.
+ IN PTR host1.example.com
+
+ An LLMNR responder might be further manually configured with the name
+ of a local mail server with an MX RR included in the "host1." and
+ "host1.example.com." records.
+
+ In responding to queries:
+
+[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
+ address(es) defined in Section 2, and on UDP and TCP port 5355 on
+ the unicast address(es) that could be set as the source address(es)
+ when the responder responds to the LLMNR query.
+
+[b] Responders MUST direct responses to the port from which the query
+ was sent. When queries are received via TCP this is an inherent
+ part of the transport protocol. For queries received by UDP the
+ responder MUST take note of the source port and use that as the
+ destination port in the response. Responses SHOULD always be sent
+ from the port to which they were directed.
+
+[c] Responders MUST respond to LLMNR queries for names and addresses
+ they are authoritative for. This applies to both forward and
+ reverse lookups.
+
+[d] Responders MUST NOT respond to LLMNR queries for names they are not
+ authoritative for.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 9]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+[e] Responders MUST NOT respond using cached data.
+
+[f] If a DNS server is running on a host that supports LLMNR, the DNS
+ server MUST respond to LLMNR queries only for the RRSets relating
+ to the host on which the server is running, but MUST NOT respond
+ for other records for which the server is authoritative. DNS
+ servers also MUST NOT send LLMNR queries in order to resolve DNS
+ queries.
+
+[g] If a responder is authoritative for a name, it MAY respond with
+ RCODE=0 and an empty answer section, if the type of query does not
+ match a RR that the responder has.
+
+ As an example, a host configured to respond to LLMNR queries for the
+ name "foo.example.com." is authoritative for the name
+ "foo.example.com.". On receiving an LLMNR query for an A RR with the
+ name "foo.example.com." the host authoritatively responds with A
+ RR(s) that contain IP address(es) in the RDATA of the resource
+ record. If the responder has a AAAA RR, but no A RR, and an A RR
+ query is received, the responder would respond with RCODE=0 and an
+ empty answer section.
+
+ In conventional DNS terminology a DNS server authoritative for a zone
+ is authoritative for all the domain names under the zone apex except
+ for the branches delegated into separate zones. Contrary to
+ conventional DNS terminology, an LLMNR responder is authoritative
+ only for the zone apex.
+
+ For example the host "foo.example.com." is not authoritative for the
+ name "child.foo.example.com." unless the host is configured with
+ multiple names, including "foo.example.com." and
+ "child.foo.example.com.". As a result, "foo.example.com." cannot
+ reply to an LLMNR query for "child.foo.example.com." with RCODE=3
+ (authoritative name error). The purpose of limiting the name
+ authority scope of a responder is to prevent complications that could
+ be caused by coexistence of two or more hosts with the names
+ representing child and parent (or grandparent) nodes in the DNS tree,
+ for example, "foo.example.com." and "child.foo.example.com.".
+
+ In this example (unless this limitation is introduced) an LLMNR query
+ for an A resource record for the name "child.foo.example.com." would
+ result in two authoritative responses: RCODE=3 (authoritative name
+ error) received from "foo.example.com.", and a requested A record -
+ from "child.foo.example.com.". To prevent this ambiguity, LLMNR
+ enabled hosts could perform a dynamic update of the parent (or
+ grandparent) zone with a delegation to a child zone. In this example
+ a host "child.foo.example.com." would send a dynamic update for the
+ NS and glue A record to "foo.example.com.", but this approach
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 10]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ significantly complicates implementation of LLMNR and would not be
+ acceptable for lightweight hosts.
+
+2.4. Unicast queries and responses
+
+ Unicast queries SHOULD be sent when:
+
+ [a] A sender repeats a query after it received a response
+ with the TC bit set to the previous LLMNR multicast query, or
+
+ [b] The sender queries for a PTR RR of a fully formed IP address
+ within the "in-addr.arpa" or "ip6.arpa" zones.
+
+ Unicast LLMNR queries MUST be done using TCP and the responses MUST
+ be sent using the same TCP connection as the query. Senders MUST
+ support sending TCP queries, and responders MUST support listening
+ for TCP queries. If the sender of a TCP query receives a response to
+ that query not using TCP, the response MUST be silently discarded.
+
+ Unicast UDP queries MUST be silently discarded.
+
+ If TCP connection setup cannot be completed in order to send a
+ unicast TCP query, this is treated as a response that no records of
+ the specified type and class exist for the specified name (it is
+ treated the same as a response with RCODE=0 and an empty answer
+ section).
+
+2.5. "Off link" detection
+
+ For IPv4, an "on link" address is defined as a link-local address
+ [IPv4Link] or an address whose prefix belongs to a subnet on the
+ local link. For IPv6 [RFC2460] an "on link" address is either a
+ link-local address, defined in [RFC2373], or an address whose prefix
+ belongs to a subnet on the local link.
+
+ A sender MUST select a source address for LLMNR queries that is "on
+ link". The destination address of an LLMNR query MUST be a link-
+ scope multicast address or an "on link" unicast address.
+
+ A responder MUST select a source address for responses that is "on
+ link". The destination address of an LLMNR response MUST be an "on
+ link" unicast address.
+
+ On receiving an LLMNR query, the responder MUST check whether it was
+ sent to a LLMNR multicast addresses defined in Section 2. If it was
+ sent to another multicast address, then the query MUST be silently
+ discarded.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 11]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ Section 2.4 discusses use of TCP for LLMNR queries and responses. In
+ composing an LLMNR query using TCP, the sender MUST set the Hop Limit
+ field in the IPv6 header and the TTL field in the IPv4 header of the
+ response to one (1). The responder SHOULD set the TTL or Hop Limit
+ settings on the TCP listen socket to one (1) so that SYN-ACK packets
+ will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
+ prevents an incoming connection from off-link since the sender will
+ not receive a SYN-ACK from the responder.
+
+ For UDP queries and responses the Hop Limit field in the IPv6 header,
+ and the TTL field in the IPV4 header MAY be set to any value.
+ However, it is RECOMMENDED that the value 255 be used for
+ compatibility with Apple Rendezvous.
+
+ Implementation note:
+
+ In the sockets API for IPv4 [POSIX], the IP_TTL and
+ IP_MULTICAST_TTL socket options are used to set the TTL of
+ outgoing unicast and multicast packets. The IP_RECVTTL socket
+ option is available on some platforms to retrieve the IPv4 TTL of
+ received packets with recvmsg(). [RFC2292] specifies similar
+ options for setting and retrieving the IPv6 Hop Limit.
+
+2.6. Responder responsibilities
+
+ It is the responsibility of the responder to ensure that RRs returned
+ in LLMNR responses MUST only include values that are valid on the
+ local interface, such as IPv4 or IPv6 addresses valid on the local
+ link or names defended using the mechanism described in Section 4.
+ In particular:
+
+ [a] If a link-scope IPv6 address is returned in a AAAA RR,
+ that address MUST be valid on the local link over which
+ LLMNR is used.
+
+ [b] If an IPv4 address is returned, it MUST be reachable
+ through the link over which LLMNR is used.
+
+ [c] If a name is returned (for example in a CNAME, MX
+ or SRV RR), the name MUST be resolvable on the local
+ link over which LLMNR is used.
+
+ Routable addresses MUST be included first in the response, if
+ available. This encourages use of routable address(es) for
+ establishment of new connections.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 12]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+2.7. Retransmission and jitter
+
+ An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
+ when to retransmit an LLMNR query and how long to collect responses
+ to an LLMNR query.
+
+ If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
+ then a sender MAY repeat the transmission of the query in order to
+ assure that it was received by a host capable of responding to it.
+ Retransmission of UDP queries SHOULD NOT be attempted more than 3
+ times. Where LLMNR queries are sent using TCP, retransmission is
+ handled by the transport layer.
+
+ Because an LLMNR sender cannot know in advance if a query sent using
+ multicast will receive no response, one response, or more than one
+ response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
+ collect all possible responses, rather than considering the multicast
+ query answered after the first response is received. A unicast query
+ sender considers the query answered after the first response is
+ received, so that it only waits for LLMNR_TIMEOUT if no response has
+ been received.
+
+ An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
+ for each transmission. It is suggested that the computation of
+ LLMNR_TIMEOUT be based on the response times for earlier LLMNR
+ queries sent on the same interface.
+
+ For example, the algorithms described in RFC 2988 [RFC2988]
+ (including exponential backoff) compute an RTO, which is used as the
+ value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial
+ RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
+ RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the
+ maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
+
+ Recommended values are an initial RTO of 1 second, a minimum RTO of
+ 200ms, and a maximum RTO of 5 seconds. In order to avoid
+ synchronization, the transmission of each LLMNR query and response
+ SHOULD delayed by a time randomly selected from the interval 0 to 100
+ ms. This delay MAY be avoided by responders responding with RRs
+ which they have previously determined to be UNIQUE (see Section 4 for
+ details).
+
+2.8. DNS TTL
+
+ The responder should use a pre-configured TTL value in the records
+ returned an LLMNR response. A default value of 30 seconds is
+ RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
+ networks), the TTL value may need to be reduced.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 13]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ Due to the TTL minimalization necessary when caching an RRset, all
+ TTLs in an RRset MUST be set to the same value.
+
+2.9. Use of the authority and additional sections
+
+ Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
+ concept of delegation. In LLMNR, the NS resource record type may be
+ stored and queried for like any other type, but it has no special
+ delegation semantics as it does in the DNS. Responders MAY have NS
+ records associated with the names for which they are authoritative,
+ but they SHOULD NOT include these NS records in the authority
+ sections of responses.
+
+ Responders SHOULD insert an SOA record into the authority section of
+ a negative response, to facilitate negative caching as specified in
+ [RFC2308]. The owner name of this SOA record MUST be equal to the
+ query name.
+
+ Responders SHOULD NOT perform DNS additional section processing,
+ except as required for EDNS0 and DNSSEC.
+
+ Senders MUST NOT cache RRs from the authority or additional section
+ of a response as answers, though they may be used for other purposes
+ such as negative caching.
+
+3. Usage model
+
+ Since LLMNR is a secondary name resolution mechanism, its usage is in
+ part determined by the behavior of DNS implementations. This
+ document does not specify any changes to DNS resolver behavior, such
+ as searchlist processing or retransmission/failover policy. However,
+ robust DNS resolver implementations are more likely to avoid
+ unnecessary LLMNR queries.
+
+ As noted in [DNSPerf], even when DNS servers are configured, a
+ significant fraction of DNS queries do not receive a response, or
+ result in negative responses due to missing inverse mappings or NS
+ records that point to nonexistent or inappropriate hosts. This has
+ the potential to result in a large number of unnecessary LLMNR
+ queries.
+
+ [RFC1536] describes common DNS implementation errors and fixes. If
+ the proposed fixes are implemented, unnecessary LLMNR queries will be
+ reduced substantially, and so implementation of [RFC1536] is
+ recommended.
+
+ For example, [RFC1536] Section 1 describes issues with retransmission
+ and recommends implementation of a retransmission policy based on
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 14]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ round trip estimates, with exponential backoff. [RFC1536] Section 4
+ describes issues with failover, and recommends that resolvers try
+ another server when they don't receive a response to a query. These
+ policies are likely to avoid unnecessary LLMNR queries.
+
+ [RFC1536] Section 3 describes zero answer bugs, which if addressed
+ will also reduce unnecessary LLMNR queries.
+
+ [RFC1536] Section 6 describes name error bugs and recommended
+ searchlist processing that will reduce unnecessary RCODE=3
+ (authoritative name) errors, thereby also reducing unnecessary LLMNR
+ queries.
+
+3.1. LLMNR configuration
+
+ Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
+ possible for a dual stack host to be configured with the address of a
+ DNS server over IPv4, while remaining unconfigured with a DNS server
+ suitable for use over IPv6.
+
+ In these situations, a dual stack host will send AAAA queries to the
+ configured DNS server over IPv4. However, an IPv6-only host
+ unconfigured with a DNS server suitable for use over IPv6 will be
+ unable to resolve names using DNS. Automatic IPv6 DNS configuration
+ mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
+ deployed, and not all DNS servers support IPv6. Therefore lack of
+ IPv6 DNS configuration may be a common problem in the short term, and
+ LLMNR may prove useful in enabling linklocal name resolution over
+ IPv6.
+
+ Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
+ IPv6-only hosts may not be configured with a DNS server. Where there
+ is no DNS server authoritative for the name of a host or the
+ authoritative DNS server does not support dynamic client update over
+ IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
+ be able to do DNS dynamic update, and other hosts will not be able to
+ resolve its name.
+
+ For example, if the configured DNS server responds to AAAA RR queries
+ sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
+ then it will not be possible to resolve the names of IPv6-only hosts.
+ In this situation, LLMNR over IPv6 can be used for local name
+ resolution.
+
+ Similarly, if a DHCPv4 server is available providing DNS server
+ configuration, and DNS server(s) exist which are authoritative for
+ the A RRs of local hosts and support either dynamic client update
+ over IPv4 or DHCPv4-based dynamic update, then the names of local
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 15]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
+ DNS server is authoritative for the names of local hosts, or the
+ authoritative DNS server(s) do not support dynamic update, then LLMNR
+ enables linklocal name resolution over IPv4.
+
+ Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
+ configure LLMNR on an interface. The LLMNR Enable Option, described
+ in [LLMNREnable], can be used to explicitly enable or disable use of
+ LLMNR on an interface. The LLMNR Enable Option does not determine
+ whether or in which order DNS itself is used for name resolution.
+ The order in which various name resolution mechanisms should be used
+ can be specified using the Name Service Search Option (NSSO) for DHCP
+ [RFC2937], using the LLMNR Enable Option code carried in the NSSO
+ data.
+
+ It is possible that DNS configuration mechanisms will go in and out
+ of service. In these circumstances, it is possible for hosts within
+ an administrative domain to be inconsistent in their DNS
+ configuration.
+
+ For example, where DHCP is used for configuring DNS servers, one or
+ more DHCP servers can fail. As a result, hosts configured prior to
+ the outage will be configured with a DNS server, while hosts
+ configured after the outage will not. Alternatively, it is possible
+ for the DNS configuration mechanism to continue functioning while
+ configured DNS servers fail.
+
+ Unless unconfigured hosts periodically retry configuration, an outage
+ in the DNS configuration mechanism will result in hosts continuing to
+ use LLMNR even once the outage is repaired. Since LLMNR only enables
+ linklocal name resolution, this represents an unnecessary degradation
+ in capabilities. As a result, it is recommended that hosts without a
+ configured DNS server periodically attempt to obtain DNS
+ configuration. For example, where DHCP is used for DNS
+ configuration, [RFC2131] recommends a maximum retry interval of 64
+ seconds. In the absence of other guidance, a default retry interval
+ of one (1) minute is RECOMMENDED.
+
+4. Conflict resolution
+
+ The sender MUST anticipate receiving multiple replies to the same
+ LLMNR query, in the event that several LLMNR enabled computers
+ receive the query and respond with valid answers. When this occurs,
+ the responses may first be concatenated, and then treated in the same
+ manner that multiple RRs received from the same DNS server would; the
+ sender perceives no inherent conflict in the receipt of multiple
+ responses.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 16]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ There are some scenarios when multiple responders MAY respond to the
+ same query. There are other scenarios when only one responder MAY
+ respond to a query. Resource records for which the latter queries
+ are submitted are referred as UNIQUE throughout this document. The
+ uniqueness of a resource record depends on a nature of the name in
+ the query and type of the query. For example it is expected that:
+
+ - multiple hosts may respond to a query for an SRV type record
+ - multiple hosts may respond to a query for an A or AAAA type
+ record for a cluster name (assigned to multiple hosts in
+ the cluster)
+ - only a single host may respond to a query for an A or AAAA
+ type record for a name.
+
+ Every responder that responds to an LLMNR query AND includes a UNIQUE
+ record in the response:
+
+ [1] MUST verify that there is no other host within the
+ scope of the LLMNR query propagation that can return
+ a resource record for the same name, type and class.
+
+ [2] MUST NOT include a UNIQUE resource record in the
+ response without having verified its uniqueness.
+
+ Where a host is configured to issue LLMNR queries on more than one
+ interface, each interface should have its own independent LLMNR
+ cache. For each UNIQUE resource record in a given interface's
+ configuration, the host MUST verify resource record uniqueness on
+ that interface. To accomplish this, the host MUST send an LLMNR
+ query for each UNIQUE resource record.
+
+ By default, a host SHOULD be configured to behave as though all RRs
+ are UNIQUE. Uniqueness verification is carried out when the host:
+
+ - starts up or is rebooted
+ - wakes from sleep (if the network interface was inactive during sleep)
+ - is configured to respond to the LLMNR queries on an interface
+ enabled for transmission and reception of IP traffic
+ - is configured to respond to the LLMNR queries using additional
+ UNIQUE resource records
+ - detects that an interface is connected and is usable
+ (e.g. an IEEE 802 hardware link-state change indicating
+ that a cable was attached or completion of authentication
+ (and if needed, association) with a wireless base station
+ or adhoc network
+
+ When a host that has a UNIQUE record receives an LLMNR query for that
+ record, the host MUST respond. After the client receives a response,
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 17]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ it MUST check whether the response arrived on an interface different
+ from the one on which the query was sent. If the response arrives on
+ a different interface, the client can use the UNIQUE resource record
+ in response to LLMNR queries. If not, then it MUST NOT use the
+ UNIQUE resource record in response to LLMNR queries.
+
+ The name conflict detection mechanism doesn't prevent name conflicts
+ when previously partitioned segments are connected by a bridge. In
+ order to minimize the chance of conflicts in such a situation, it is
+ recommended that steps be taken to ensure name uniqueness. For
+ example, the name could be chosen randomly from a large pool of
+ potential names, or the name could be assigned via a process designed
+ to guarantee uniqueness.
+
+ When name conflicts are detected, they SHOULD be logged. To detect
+ duplicate use of a name, an administrator can use a name resolution
+ utility which employs LLMNR and lists both responses and responders.
+ This would allow an administrator to diagnose behavior and
+ potentially to intervene and reconfigure LLMNR responders who should
+ not be configured to respond to the same name.
+
+4.1. Considerations for Multiple Interfaces
+
+ A multi-homed host may elect to configure LLMNR on only one of its
+ active interfaces. In many situations this will be adequate.
+ However, should a host need to configure LLMNR on more than one of
+ its active interfaces, there are some additional precautions it MUST
+ take. Implementers who are not planning to support LLMNR on multiple
+ interfaces simultaneously may skip this section.
+
+ A multi-homed host checks the uniqueness of UNIQUE records as
+ described in Section 4. The situation is illustrated in figure 1.
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [myhost]
+
+ Figure 1. Link-scope name conflict
+
+ In this situation, the multi-homed myhost will probe for, and defend,
+ its host name on both interfaces. A conflict will be detected on one
+ interface, but not the other. The multi-homed myhost will not be
+ able to respond with a host RR for "myhost" on the interface on the
+ right (see Figure 1). The multi-homed host may, however, be
+ configured to use the "myhost" name on the interface on the left.
+
+ Since names are only unique per-link, hosts on different links could
+ be using the same name. If an LLMNR client sends requests over
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 18]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ multiple interfaces, and receives replies from more than one, the
+ result returned to the client is defined by the implementation. The
+ situation is illustrated in figure 2.
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [A]
+
+
+ Figure 2. Off-segment name conflict
+
+ If host myhost is configured to use LLMNR on both interfaces, it will
+ send LLMNR queries on both interfaces. When host myhost sends a
+ query for the host RR for name "A" it will receive a response from
+ hosts on both interfaces.
+
+ Host myhost cannot distinguish between the situation shown in Figure
+ 2, and that shown in Figure 3 where no conflict exists.
+
+ [A]
+ | |
+ ----- -----
+ | |
+ [myhost]
+
+ Figure 3. Multiple paths to same host
+
+ This illustrates that the proposed name conflict resolution mechanism
+ does not support detection or resolution of conflicts between hosts
+ on different links. This problem can also occur with unicast DNS
+ when a multi-homed host is connected to two different networks with
+ separated name spaces. It is not the intent of this document to
+ address the issue of uniqueness of names within DNS.
+
+4.2. 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
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 19]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 25 June 2004
+
+
+ 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 by nature a peer-to-peer name resolution protocol. It is
+ therefore inherently more vulnerable than DNS, since existing DNS
+ security mechanisms are difficult to apply to LLMNR. While tools
+ exist to alllow an attacker to spoof a response to a DNS query,
+ spoofing a response to an LLMNR query is easier since the query is
+ sent to a link-scope multicast address, where every host on the
+ logical link will be made aware of it.
+
+ In order to address the security vulnerabilities, the following
+ mechanisms are contemplated:
+
+ [1] Scope restrictions.
+ [2] Usage restrictions.
+ [3] Cache and port separation.
+ [4] Authentication.
+
+ 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 25 June 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 25 June 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 25 June 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 25 June 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 25 June 2004
+
+
+Authors' Addresses
+
+ Levon Esibov
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: levone@microsoft.com
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: +1 425 706 6605
+ EMail: bernarda@microsoft.com
+
+ Dave Thaler
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: +1 425 703 8835
+ EMail: dthaler@microsoft.com
+
+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 25 June 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). 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.
+
+Open Issues
+
+ Open issues with this specification are tracked on the following web
+ site:
+
+ http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
+
+Expiration Date
+
+ This memo is filed as <draft-ietf-dnsext-mdns-32.txt>, and expires
+ December 22, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 26]
+
projects / thirdparty / bind9.git / commitdiff
