idnits 2.17.1 draft-ietf-dnsext-mdns-45.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1353. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 339 has weird spacing: '... record type...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 October 2005) is 6770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 684 -- Looks like a reference, but probably isn't: '2' on line 693 == Missing Reference: 'A' is mentioned on line 982, but not defined ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) -- No information found for draft-guttman-mdns-enable - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2292 (Obsoleted by RFC 3542) -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Bernard Aboba 3 INTERNET-DRAFT Dave Thaler 4 Category: Standards Track Levon Esibov 5 Microsoft Corporation 6 6 October 2005 8 Linklocal Multicast Name Resolution (LLMNR) 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 15, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society 2005. 39 Abstract 41 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable 42 name resolution in scenarios in which conventional DNS name 43 resolution is not possible. LLMNR supports all current and future 44 DNS formats, types and classes, while operating on a separate port 45 from DNS, and with a distinct resolver cache. Since LLMNR only 46 operates on the local link, it cannot be considered a substitute for 47 DNS. 49 Table of Contents 51 1. Introduction .......................................... 3 52 1.1 Requirements .................................... 4 53 1.2 Terminology ..................................... 4 54 2. Name Resolution Using LLMNR ........................... 4 55 2.1 LLMNR Packet Format ............................. 5 56 2.2 Sender Behavior ................................. 8 57 2.3 Responder Behavior .............................. 8 58 2.4 Unicast Queries and Responses ................... 11 59 2.5 Off-link Detection .............................. 11 60 2.6 Responder Responsibilities ...................... 12 61 2.7 Retransmission and Jitter ....................... 13 62 2.8 DNS TTL ......................................... 14 63 2.9 Use of the Authority and Additional Sections .... 14 64 3. Usage model ........................................... 15 65 3.1 LLMNR Configuration ............................. 16 66 4. Conflict Resolution ................................... 18 67 4.1 Uniqueness Verification ......................... 18 68 4.2 Conflict Detection and Defense .................. 19 69 4.3 Considerations for Multiple Interfaces .......... 20 70 4.4 API issues ...................................... 22 71 5. Security Considerations ............................... 22 72 5.1 Denial of Service ............................... 22 73 5.2 Spoofing ...............,........................ 23 74 5.3 Authentication .................................. 24 75 5.4 Cache and Port Separation ....................... 24 76 6. IANA considerations ................................... 25 77 7. Constants ............................................. 25 78 8. References ............................................ 26 79 8.1 Normative References ............................ 26 80 8.2 Informative References .......................... 26 81 Acknowledgments .............................................. 28 82 Authors' Addresses ........................................... 28 83 Intellectual Property Statement .............................. 29 84 Disclaimer of Validity ....................................... 29 85 Copyright Statement .......................................... 29 86 1. Introduction 88 This document discusses Link Local Multicast Name Resolution (LLMNR), 89 which is based on the DNS packet format and supports all current and 90 future DNS formats, types and classes. LLMNR operates on a separate 91 port from the Domain Name System (DNS), with a distinct resolver 92 cache. 94 Since LLMNR only operates on the local link, it cannot be considered 95 a substitute for DNS. Link-scope multicast addresses are used to 96 prevent propagation of LLMNR traffic across routers, potentially 97 flooding the network. LLMNR queries can also be sent to a unicast 98 address, as described in Section 2.4. 100 Propagation of LLMNR packets on the local link is considered 101 sufficient to enable name resolution in small networks. In such 102 networks, if a network has a gateway, then typically the network is 103 able to provide DNS server configuration. Configuration issues are 104 discussed in Section 3.1. 106 In the future, it may be desirable to consider use of multicast name 107 resolution with multicast scopes beyond the link-scope. This could 108 occur if LLMNR deployment is successful, the need arises for 109 multicast name resolution beyond the link-scope, or multicast routing 110 becomes ubiquitous. For example, expanded support for multicast name 111 resolution might be required for mobile ad-hoc networks. 113 Once we have experience in LLMNR deployment in terms of 114 administrative issues, usability and impact on the network, it will 115 be possible to reevaluate which multicast scopes are appropriate for 116 use with multicast name resolution. IPv4 administratively scoped 117 multicast usage is specified in "Administratively Scoped IP 118 Multicast" [RFC2365]. 120 Service discovery in general, as well as discovery of DNS servers 121 using LLMNR in particular, is outside of the scope of this document, 122 as is name resolution over non-multicast capable media. 124 1.1. Requirements 126 In this document, several words are used to signify the requirements 127 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" in this document are to be interpreted as described in 130 [RFC2119]. 132 1.2. Terminology 134 This document assumes familiarity with DNS terminology defined in 135 [RFC1035]. Other terminology used in this document includes: 137 Routable Address 138 An address other than a Link-Local address. This includes globally 139 routable addresses, as well as private addresses. 141 Reachable 142 An LLMNR responder considers one of its addresses reachable over a 143 link if it will respond to an ARP or Neighbor Discovery query for 144 that address received on that link. 146 Responder 147 A host that listens to LLMNR queries, and responds to those for 148 which it is authoritative. 150 Sender 151 A host that sends an LLMNR query. 153 UNIQUE 154 There are some scenarios when multiple responders may respond to 155 the same query. There are other scenarios when only one responder 156 may respond to a query. Names for which only a single responder is 157 anticipated are referred to as UNIQUE. Name uniqueness is 158 configured on the responder, and therefore uniqueness verification 159 is the responder's responsibility. 161 2. Name Resolution Using LLMNR 163 LLMNR queries are sent to and received on port 5355. The IPv4 link- 164 scope multicast address a given responder listens to, and to which a 165 sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast 166 address a given responder listens to, and to which a sender sends all 167 queries, is FF02:0:0:0:0:0:1:3. 169 Typically a host is configured as both an LLMNR sender and a 170 responder. A host MAY be configured as a sender, but not a 171 responder. However, a host configured as a responder MUST act as a 172 sender, if only to verify the uniqueness of names as described in 173 Section 4. This document does not specify how names are chosen or 174 configured. This may occur via any mechanism, including DHCPv4 175 [RFC2131] or DHCPv6 [RFC3315]. 177 A typical sequence of events for LLMNR usage is as follows: 179 [a] An LLMNR sender sends an LLMNR query to the link-scope 180 multicast address(es), unless a unicast query is indicated, 181 as specified in Section 2.4. 183 [b] A responder responds to this query only if it is authoritative 184 for the name in the query. A responder responds to a 185 multicast query by sending a unicast UDP response to the sender. 186 Unicast queries are responded to as indicated in Section 2.4. 188 [c] Upon reception of the response, the sender processes it. 190 The sections that follow provide further details on sender and 191 responder behavior. 193 2.1. LLMNR Packet Format 195 LLMNR is based on the DNS packet format defined in [RFC1035] Section 196 4 for both queries and responses. LLMNR implementations SHOULD send 197 UDP queries and responses only as large as are known to be 198 permissible without causing fragmentation. When in doubt a maximum 199 packet size of 512 octets SHOULD be used. LLMNR implementations MUST 200 accept UDP queries and responses as large as the smaller of the link 201 MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 202 octets for the header, VLAN tag and CRC). 204 2.1.1. LLMNR Header Format 206 LLMNR queries and responses utilize the DNS header format defined in 207 [RFC1035] with exceptions noted below: 209 1 1 1 1 1 1 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 211 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 212 | ID | 213 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 214 |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | 215 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 216 | QDCOUNT | 217 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 218 | ANCOUNT | 219 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 220 | NSCOUNT | 221 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 222 | ARCOUNT | 223 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 225 where: 227 ID A 16 bit identifier assigned by the program that generates any kind 228 of query. This identifier is copied from the query to the response 229 and can be used by the sender to match responses to outstanding 230 queries. The ID field in a query SHOULD be set to a pseudo-random 231 value. For advice on generation of pseudo-random values, please 232 consult [RFC1750]. 234 QR Query/Response. A one bit field, which if set indicates that the 235 message is an LLMNR response; if clear then the message is an LLMNR 236 query. 238 OPCODE 239 A four bit field that specifies the kind of query in this message. 240 This value is set by the originator of a query and copied into the 241 response. This specification defines the behavior of standard 242 queries and responses (opcode value of zero). Future 243 specifications may define the use of other opcodes with LLMNR. 244 LLMNR senders and responders MUST support standard queries (opcode 245 value of zero). LLMNR queries with unsupported OPCODE values MUST 246 be silently discarded by responders. 248 C Conflict. When set within a request, the 'C'onflict bit indicates 249 that a sender has received multiple LLMNR responses to this query. 250 In an LLMNR response, if the name is considered UNIQUE, then the 251 'C' bit is clear, otherwise it is set. LLMNR senders do not 252 retransmit queries with the 'C' bit set. Responders MUST NOT 253 respond to LLMNR queries with the 'C' bit set, but may start the 254 uniqueness verification process, as described in Section 4.2. 256 TC TrunCation - specifies that this message was truncated due to 257 length greater than that permitted on the transmission channel. 258 The TC bit MUST NOT be set in an LLMNR query and if set is ignored 259 by an LLMNR responder. If the TC bit is set in an LLMNR response, 260 then the sender SHOULD resend the LLMNR query over TCP using the 261 unicast address of the responder as the destination address. If 262 the sender receives a response to the TCP query, then it SHOULD 263 discard the UDP response with the TC bit set. See [RFC2181] and 264 Section 2.4 of this specification for further discussion of the TC 265 bit. 267 T Tentative. The 'T'entative bit is set in a response if the 268 responder is authoritative for the name, but has not yet verified 269 the uniqueness of the name. A responder MUST ignore the 'T' bit in 270 a query, if set. A response with the 'T' bit set is silently 271 discarded by the sender, except if it is a uniqueness query, in 272 which case a conflict has been detected and a responder MUST 273 resolve the conflict as described in Section 4.1. 275 Z Reserved for future use. Implementations of this specification 276 MUST set these bits to zero in both queries and responses. If 277 these bits are set in a LLMNR query or response, implementations of 278 this specification MUST ignore them. Since reserved bits could 279 conceivably be used for different purposes than in DNS, 280 implementors are advised not to enable processing of these bits in 281 an LLMNR implementation starting from a DNS code base. 283 RCODE 284 Response code -- this 4 bit field is set as part of LLMNR 285 responses. In an LLMNR query, the sender MUST set RCODE to zero; 286 the responder ignores the RCODE and assumes it to be zero. The 287 response to a multicast LLMNR query MUST have RCODE set to zero. A 288 sender MUST silently discard an LLMNR response with a non-zero 289 RCODE sent in response to a multicast query. 291 If an LLMNR responder is authoritative for the name in a multicast 292 query, but an error is encountered, the responder SHOULD send an 293 LLMNR response with an RCODE of zero, no RRs in the answer section, 294 and the TC bit set. This will cause the query to be resent using 295 TCP, and allow the inclusion of a non-zero RCODE in the response to 296 the TCP query. Responding with the TC bit set is preferable to not 297 sending a response, since it enables errors to be diagnosed. This 298 may be required, for example, when an LLMNR query includes a TSIG 299 RR in the additional section, and the responder encounters a 300 problem that requires returning a non-zero RCODE. TSIG error 301 conditions defined in [RFC2845] include a TSIG RR in an 302 unacceptable position (RCODE=1) or a TSIG RR which does not 303 validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)). 305 Since LLMNR responders only respond to LLMNR queries for names for 306 which they are authoritative, LLMNR responders MUST NOT respond 307 with an RCODE of 3; instead, they should not respond at all. 309 LLMNR implementations MUST support EDNS0 [RFC2671] and extended 310 RCODE values. 312 QDCOUNT 313 An unsigned 16 bit integer specifying the number of entries in the 314 question section. A sender MUST place only one question into the 315 question section of an LLMNR query. LLMNR responders MUST silently 316 discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders 317 MUST silently discard LLMNR responses with QDCOUNT not equal to 318 one. 320 ANCOUNT 321 An unsigned 16 bit integer specifying the number of resource 322 records in the answer section. LLMNR responders MUST silently 323 discard LLMNR queries with ANCOUNT not equal to zero. 325 NSCOUNT 326 An unsigned 16 bit integer specifying the number of name server 327 resource records in the authority records section. Authority 328 record section processing is described in Section 2.9. LLMNR 329 responders MUST silently discard LLMNR queries with NSCOUNT not 330 equal to zero. 332 ARCOUNT 333 An unsigned 16 bit integer specifying the number of resource 334 records in the additional records section. Additional record 335 section processing is described in Section 2.9. 337 2.2. Sender Behavior 339 A sender MAY send an LLMNR query for any legal resource record type 340 (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. 341 As described in Section 2.4, a sender MAY also send a unicast query. 343 The sender MUST anticipate receiving no replies to some LLMNR 344 queries, in the event that no responders are available within the 345 link-scope. If no response is received, a resolver treats it as a 346 response that the name does not exist (RCODE=3 is returned). A 347 sender can handle duplicate responses by discarding responses with a 348 source IP address and ID field that duplicate a response already 349 received. 351 When multiple valid LLMNR responses are received with the 'C' bit 352 set, they SHOULD be concatenated and treated in the same manner that 353 multiple RRs received from the same DNS server would be. However, 354 responses with the 'C' bit set SHOULD NOT be concatenated with 355 responses with the 'C' bit clear; instead, only the responses with 356 the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are 357 received along with error response(s), then the error responses are 358 silently discarded. 360 Since the responder may order the RRs in the response so as to 361 indicate preference, the sender SHOULD preserve ordering in the 362 response to the querying application. 364 2.3. Responder Behavior 366 An LLMNR response MUST be sent to the sender via unicast. 368 Upon configuring an IP address, responders typically will synthesize 369 corresponding A, AAAA and PTR RRs so as to be able to respond to 370 LLMNR queries for these RRs. An SOA RR is synthesized only when a 371 responder has another RR in addition to the SOA RR; the SOA RR MUST 372 NOT be the only RR that a responder has. However, in general whether 373 RRs are manually or automatically created is an implementation 374 decision. 376 For example, a host configured to have computer name "host1" and to 377 be a member of the "example.com" domain, and with IPv4 address 378 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be 379 authoritative for the following records: 381 host1. IN A 192.0.2.1 382 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 384 host1.example.com. IN A 192.0.2.1 385 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 387 1.2.0.192.in-addr.arpa. IN PTR host1. 388 IN PTR host1.example.com. 390 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. 391 ip6.arpa IN PTR host1. (line split for formatting reasons) 392 IN PTR host1.example.com. 394 An LLMNR responder might be further manually configured with the name 395 of a local mail server with an MX RR included in the "host1." and 396 "host1.example.com." records. 398 In responding to queries: 400 [a] Responders MUST listen on UDP port 5355 on the link-scope multicast 401 address(es) defined in Section 2, and on TCP port 5355 on the 402 unicast address(es) that could be set as the source address(es) 403 when the responder responds to the LLMNR query. 405 [b] Responders MUST direct responses to the port from which the query 406 was sent. When queries are received via TCP this is an inherent 407 part of the transport protocol. For queries received by UDP the 408 responder MUST take note of the source port and use that as the 409 destination port in the response. Responses MUST always be sent 410 from the port to which they were directed. 412 [c] Responders MUST respond to LLMNR queries for names and addresses 413 they are authoritative for. This applies to both forward and 414 reverse lookups, with the exception of queries with the 'C' bit 415 set, which do not elicit a response. 417 [d] Responders MUST NOT respond to LLMNR queries for names they are not 418 authoritative for. 420 [e] Responders MUST NOT respond using data from the LLMNR or DNS 421 resolver cache. 423 [f] If a DNS server is running on a host that supports LLMNR, the DNS 424 server MUST respond to LLMNR queries only for the RRSets relating 425 to the host on which the server is running, but MUST NOT respond 426 for other records for which the server is authoritative. DNS 427 servers also MUST NOT send LLMNR queries in order to resolve DNS 428 queries. 430 [g] If a responder is authoritative for a name, it MUST respond with 431 RCODE=0 and an empty answer section, if the type of query does not 432 match a RR that the responder has. 434 As an example, a host configured to respond to LLMNR queries for the 435 name "foo.example.com." is authoritative for the name 436 "foo.example.com.". On receiving an LLMNR query for an A RR with the 437 name "foo.example.com." the host authoritatively responds with A 438 RR(s) that contain IP address(es) in the RDATA of the resource 439 record. If the responder has a AAAA RR, but no A RR, and an A RR 440 query is received, the responder would respond with RCODE=0 and an 441 empty answer section. 443 In conventional DNS terminology a DNS server authoritative for a zone 444 is authoritative for all the domain names under the zone apex except 445 for the branches delegated into separate zones. Contrary to 446 conventional DNS terminology, an LLMNR responder is authoritative 447 only for the zone apex. 449 For example the host "foo.example.com." is not authoritative for the 450 name "child.foo.example.com." unless the host is configured with 451 multiple names, including "foo.example.com." and 452 "child.foo.example.com.". As a result, "foo.example.com." cannot 453 reply to an LLMNR query for "child.foo.example.com." with RCODE=3 454 (authoritative name error). The purpose of limiting the name 455 authority scope of a responder is to prevent complications that could 456 be caused by coexistence of two or more hosts with the names 457 representing child and parent (or grandparent) nodes in the DNS tree, 458 for example, "foo.example.com." and "child.foo.example.com.". 460 Without the restriction on authority an LLMNR query for an A resource 461 record for the name "child.foo.example.com." would result in two 462 authoritative responses: RCODE=3 (authoritative name error) received 463 from "foo.example.com.", and a requested A record - from 464 "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled 465 hosts could perform a dynamic update of the parent (or grandparent) 466 zone with a delegation to a child zone; for example a host 467 "child.foo.example.com." could send a dynamic update for the NS and 468 glue A record to "foo.example.com.". However, this approach 469 significantly complicates implementation of LLMNR and would not be 470 acceptable for lightweight hosts. 472 2.4. Unicast Queries and Responses 474 Unicast queries SHOULD be sent when: 476 [a] A sender repeats a query after it received a response 477 with the TC bit set to the previous LLMNR multicast query, or 479 [b] The sender queries for a PTR RR of a fully formed IP address 480 within the "in-addr.arpa" or "ip6.arpa" zones. 482 Unicast LLMNR queries MUST be done using TCP and the responses MUST 483 be sent using the same TCP connection as the query. Senders MUST 484 support sending TCP queries, and responders MUST support listening 485 for TCP queries. If the sender of a TCP query receives a response to 486 that query not using TCP, the response MUST be silently discarded. 488 Unicast UDP queries MUST be silently discarded. 490 A unicast PTR RR query for an off-link address will not elicit a 491 response, but instead an ICMP TTL or Hop Limit exceeded message will 492 be received. An implementation receiving an ICMP message in response 493 to a TCP connection setup attempt can return immediately, treating 494 this as a response that no such name exists (RCODE=3 is returned). 495 An implementation that cannot process ICMP messages MAY send 496 multicast UDP queries for PTR RRs. Since TCP implementations will 497 not retransmit prior to RTOmin, a considerable period will elapse 498 before TCP retransmits multiple times, resulting in a long timeout 499 for TCP PTR RR queries sent to an off-link destination. 501 2.5. "Off link" Detection 503 A sender MUST select a source address for LLMNR queries that is 504 assigned on the interface on which the query is sent. The 505 destination address of an LLMNR query MUST be a link-scope multicast 506 address or a unicast address. 508 A responder MUST select a source address for responses that is 509 assigned on the interface on which the query was received. The 510 destination address of an LLMNR response MUST be a unicast address. 512 On receiving an LLMNR query, the responder MUST check whether it was 513 sent to a LLMNR multicast addresses defined in Section 2. If it was 514 sent to another multicast address, then the query MUST be silently 515 discarded. 517 Section 2.4 discusses use of TCP for LLMNR queries and responses. In 518 composing an LLMNR query using TCP, the sender MUST set the Hop Limit 519 field in the IPv6 header and the TTL field in the IPv4 header of the 520 response to one (1). The responder SHOULD set the TTL or Hop Limit 521 settings on the TCP listen socket to one (1) so that SYN-ACK packets 522 will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This 523 prevents an incoming connection from off-link since the sender will 524 not receive a SYN-ACK from the responder. 526 For UDP queries and responses, the Hop Limit field in the IPv6 header 527 and the TTL field in the IPV4 header MAY be set to any value. 528 However, it is RECOMMENDED that the value 255 be used for 529 compatibility with early implementations of [RFC3927]. 531 Implementation note: 533 In the sockets API for IPv4 [POSIX], the IP_TTL and 534 IP_MULTICAST_TTL socket options are used to set the TTL of 535 outgoing unicast and multicast packets. The IP_RECVTTL socket 536 option is available on some platforms to retrieve the IPv4 TTL of 537 received packets with recvmsg(). [RFC2292] specifies similar 538 options for setting and retrieving the IPv6 Hop Limit. 540 2.6. Responder Responsibilities 542 It is the responsibility of the responder to ensure that RRs returned 543 in LLMNR responses MUST only include values that are valid on the 544 local interface, such as IPv4 or IPv6 addresses valid on the local 545 link or names defended using the mechanism described in Section 4. 546 IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local 547 addresses are defined in [RFC2373]. In particular: 549 [a] If a link-scope IPv6 address is returned in a AAAA RR, 550 that address MUST be valid on the local link over which 551 LLMNR is used. 553 [b] If an IPv4 address is returned, it MUST be reachable 554 through the link over which LLMNR is used. 556 [c] If a name is returned (for example in a CNAME, MX 557 or SRV RR), the name MUST be resolvable on the local 558 link over which LLMNR is used. 560 Where multiple addresses represent valid responses to a query, the 561 order in which the addresses are returned is as follows: 563 [d] If the source address of the query is a link-scope address, 564 then the responder SHOULD include a link-scope address first 565 in the response, if available. 567 [e] If the source address of the query is a routable address, 568 then the responder MUST include a routable address first 569 in the response, if available. 571 2.7. Retransmission and Jitter 573 An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine 574 when to retransmit an LLMNR query. An LLMNR sender SHOULD either 575 estimate the LLMNR_TIMEOUT for each interface, or set a reasonably 576 high initial timeout. Suggested constants are described in Section 577 7. 579 If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, 580 then a sender SHOULD repeat the transmission of the query in order to 581 assure that it was received by a host capable of responding to it. 582 An LLMNR query SHOULD NOT be sent more than three times. 584 Where LLMNR queries are sent using TCP, retransmission is handled by 585 the transport layer. Queries with the 'C' bit set MUST be sent using 586 multicast UDP and MUST NOT be retransmitted. 588 An LLMNR sender cannot know in advance if a query sent using 589 multicast will receive no response, one response, or more than one 590 response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response 591 has been received, or if it is necessary to collect all potential 592 responses, such as if a uniqueness verification query is being made. 593 Otherwise an LLMNR sender SHOULD consider a multicast query answered 594 after the first response is received, if that response has the 'C' 595 bit clear. 597 However, if the first response has the 'C' bit set, then the sender 598 SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect 599 all possible responses. When multiple valid answers are received, 600 they may first be concatenated, and then treated in the same manner 601 that multiple RRs received from the same DNS server would. A unicast 602 query sender considers the query answered after the first response is 603 received. 605 Since it is possible for a response with the 'C' bit clear to be 606 followed by a response with the 'C' bit set, an LLMNR sender SHOULD 607 be prepared to process additional responses for the purposes of 608 conflict detection, even after it has considered a query answered. 610 In order to avoid synchronization, the transmission of each LLMNR 611 query and response SHOULD delayed by a time randomly selected from 612 the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by 613 responders responding with names which they have previously 614 determined to be UNIQUE (see Section 4 for details). 616 2.8. DNS TTL 618 The responder should insert a pre-configured TTL value in the records 619 returned in an LLMNR response. A default value of 30 seconds is 620 RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc 621 networks), the TTL value may need to be reduced. 623 Due to the TTL minimalization necessary when caching an RRset, all 624 TTLs in an RRset MUST be set to the same value. 626 2.9. Use of the Authority and Additional Sections 628 Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a 629 concept of delegation. In LLMNR, the NS resource record type may be 630 stored and queried for like any other type, but it has no special 631 delegation semantics as it does in the DNS. Responders MAY have NS 632 records associated with the names for which they are authoritative, 633 but they SHOULD NOT include these NS records in the authority 634 sections of responses. 636 Responders SHOULD insert an SOA record into the authority section of 637 a negative response, to facilitate negative caching as specified in 638 [RFC2308]. The TTL of this record is set from the minimum of the 639 MINIMUM field of the SOA record and the TTL of the SOA itself, and 640 indicates how long a resolver may cache the negative answer. The 641 owner name of the SOA record (MNAME) MUST be set to the query name. 642 The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored 643 by senders. Negative responses without SOA records SHOULD NOT be 644 cached. 646 In LLMNR, the additional section is primarily intended for use by 647 EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, 648 senders MAY only include pseudo RR-types in the additional section of 649 a query; unless the 'C' bit is set, responders MUST ignore the 650 additional section of queries containing other RR types. 652 In queries where the 'C' bit is set, the sender SHOULD include the 653 conflicting RRs in the additional section. Since conflict 654 notifications are advisory, responders SHOULD log information from 655 the additional section, but otherwise MUST ignore the additional 656 section. 658 Senders MUST NOT cache RRs from the authority or additional section 659 of a response as answers, though they may be used for other purposes 660 such as negative caching. 662 3. Usage Model 664 LLMNR is a peer-to-peer name resolution protocol that is not intended 665 as a replacement for DNS; rather, it enables name resolution in 666 scenarios in which conventional DNS name resolution is not possible. 667 This includes situations in which hosts are not configured with the 668 address of a DNS server; where the DNS server is unavailable or 669 unreachable; where there is no DNS server authoritative for the name 670 of a host, or where the authoritative DNS server does not have the 671 desired RRs. 673 By default, an LLMNR sender SHOULD send LLMNR queries only for 674 single-label names. In order to reduce unnecessary DNS queries, stub 675 resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS 676 queries for single-label names. An LLMNR sender SHOULD NOT be 677 enabled to send a query for any name, except where security 678 mechanisms (described in Section 5.3) can be utilized. 680 Regardless of whether security mechanisms can be utilized, LLMNR 681 queries SHOULD NOT be sent unless one of the following conditions are 682 met: 684 [1] No manual or automatic DNS configuration has been performed. 685 If DNS server address(es) have been configured, a 686 host SHOULD attempt to reach DNS servers over all protocols 687 on which DNS server address(es) are configured, prior to sending 688 LLMNR queries. For dual stack hosts configured with DNS server 689 address(es) for one protocol but not another, this implies that 690 DNS queries SHOULD be sent over the protocol configured with 691 a DNS server, prior to sending LLMNR queries. 693 [2] All attempts to resolve the name via DNS on all interfaces 694 have failed after exhausting the searchlist. This can occur 695 because DNS servers did not respond, or because they 696 responded to DNS queries with RCODE=3 (Authoritative Name 697 Error) or RCODE=0, and an empty answer section. Where a 698 single resolver call generates DNS queries for A and AAAA RRs, 699 an implementation MAY choose not to send LLMNR queries if any 700 of the DNS queries is successful. An LLMNR query SHOULD only 701 be sent for the originally requested name; a searchlist 702 is not used to form additional LLMNR queries. 704 Since LLMNR is a secondary name resolution mechanism, its usage is in 705 part determined by the behavior of DNS implementations. In general, 706 robust DNS resolver implementations are more likely to avoid 707 unnecessary LLMNR queries. 709 As noted in [DNSPerf], even when DNS servers are configured, a 710 significant fraction of DNS queries do not receive a response, or 711 result in negative responses due to missing inverse mappings or NS 712 records that point to nonexistent or inappropriate hosts. This has 713 the potential to result in a large number of unnecessary LLMNR 714 queries. 716 [RFC1536] describes common DNS implementation errors and fixes. If 717 the proposed fixes are implemented, unnecessary LLMNR queries will be 718 reduced substantially, and so implementation of [RFC1536] is 719 recommended. 721 For example, [RFC1536] Section 1 describes issues with retransmission 722 and recommends implementation of a retransmission policy based on 723 round trip estimates, with exponential back-off. [RFC1536] Section 4 724 describes issues with failover, and recommends that resolvers try 725 another server when they don't receive a response to a query. These 726 policies are likely to avoid unnecessary LLMNR queries. 728 [RFC1536] Section 3 describes zero answer bugs, which if addressed 729 will also reduce unnecessary LLMNR queries. 731 [RFC1536] Section 6 describes name error bugs and recommended 732 searchlist processing that will reduce unnecessary RCODE=3 733 (authoritative name) errors, thereby also reducing unnecessary LLMNR 734 queries. 736 If error responses are received from both DNS and LLMNR, then the 737 lowest RCODE value should be returned. For example, if either DNS or 738 LLMNR receives a response with RCODE=0, then this should returned to 739 the caller. 741 3.1. LLMNR Configuration 743 LLMNR usage MAY be configured manually or automatically on a per 744 interface basis. By default, LLMNR responders SHOULD be enabled on 745 all interfaces, at all times. Enabling LLMNR for use in situations 746 where a DNS server has been configured will result in a change in 747 default behavior without a simultaneous update to configuration 748 information. Where this is considered undesirable, LLMNR SHOULD NOT 749 be enabled by default, so that hosts will neither listen on the link- 750 scope multicast address, nor will they send queries to that address. 752 Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is 753 possible for a dual stack host to be configured with the address of a 754 DNS server over IPv4, while remaining unconfigured with a DNS server 755 suitable for use over IPv6. 757 In these situations, a dual stack host will send AAAA queries to the 758 configured DNS server over IPv4. However, an IPv6-only host 759 unconfigured with a DNS server suitable for use over IPv6 will be 760 unable to resolve names using DNS. Automatic IPv6 DNS configuration 761 mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely 762 deployed, and not all DNS servers support IPv6. Therefore lack of 763 IPv6 DNS configuration may be a common problem in the short term, and 764 LLMNR may prove useful in enabling link-local name resolution over 765 IPv6. 767 Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], 768 IPv6-only hosts may not be configured with a DNS server. Where there 769 is no DNS server authoritative for the name of a host or the 770 authoritative DNS server does not support dynamic client update over 771 IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not 772 be able to do DNS dynamic update, and other hosts will not be able to 773 resolve its name. 775 For example, if the configured DNS server responds to a AAAA RR query 776 sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or 777 RCODE=0 and an empty answer section, then a AAAA RR query sent using 778 LLMNR over IPv6 may be successful in resolving the name of an 779 IPv6-only host on the local link. 781 Similarly, if a DHCPv4 server is available providing DNS server 782 configuration, and DNS server(s) exist which are authoritative for 783 the A RRs of local hosts and support either dynamic client update 784 over IPv4 or DHCPv4-based dynamic update, then the names of local 785 IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no 786 DNS server is authoritative for the names of local hosts, or the 787 authoritative DNS server(s) do not support dynamic update, then LLMNR 788 enables linklocal name resolution over IPv4. 790 Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to 791 configure LLMNR on an interface. The LLMNR Enable Option, described 792 in [LLMNREnable], can be used to explicitly enable or disable use of 793 LLMNR on an interface. The LLMNR Enable Option does not determine 794 whether or in which order DNS itself is used for name resolution. 795 The order in which various name resolution mechanisms should be used 796 can be specified using the Name Service Search Option (NSSO) for DHCP 797 [RFC2937], using the LLMNR Enable Option code carried in the NSSO 798 data. 800 It is possible that DNS configuration mechanisms will go in and out 801 of service. In these circumstances, it is possible for hosts within 802 an administrative domain to be inconsistent in their DNS 803 configuration. 805 For example, where DHCP is used for configuring DNS servers, one or 806 more DHCP servers can fail. As a result, hosts configured prior to 807 the outage will be configured with a DNS server, while hosts 808 configured after the outage will not. Alternatively, it is possible 809 for the DNS configuration mechanism to continue functioning while 810 configured DNS servers fail. 812 An outage in the DNS configuration mechanism may result in hosts 813 continuing to use LLMNR even once the outage is repaired. Since 814 LLMNR only enables linklocal name resolution, this represents a 815 degradation in capabilities. As a result, hosts without a configured 816 DNS server may wish to periodically attempt to obtain DNS 817 configuration if permitted by the configuration mechanism in use. In 818 the absence of other guidance, a default retry interval of one (1) 819 minute is RECOMMENDED. 821 4. Conflict Resolution 823 By default, a responder SHOULD be configured to behave as though its 824 name is UNIQUE on each interface on which LLMNR is enabled. However, 825 it is also possible to configure multiple responders to be 826 authoritative for the same name. For example, multiple responders 827 MAY respond to a query for an A or AAAA type record for a cluster 828 name (assigned to multiple hosts in the cluster). 830 To detect duplicate use of a name, an administrator can use a name 831 resolution utility which employs LLMNR and lists both responses and 832 responders. This would allow an administrator to diagnose behavior 833 and potentially to intervene and reconfigure LLMNR responders who 834 should not be configured to respond to the same name. 836 4.1. Uniqueness Verification 838 Prior to sending an LLMNR response with the 'T' bit clear, a 839 responder configured with a UNIQUE name MUST verify that there is no 840 other host within the scope of LLMNR query propagation that is 841 authoritative for the same name on that interface. 843 Once a responder has verified that its name is UNIQUE, if it receives 844 an LLMNR query for that name, with the 'C' bit clear, it MUST 845 respond, with the 'T' bit clear. Prior to verifying that its name is 846 UNIQUE, a responder MUST set the 'T' bit in responses. 848 Uniqueness verification is carried out when the host: 850 - starts up or is rebooted 851 - wakes from sleep (if the network interface was inactive 852 during sleep) 853 - is configured to respond to LLMNR queries on an interface 854 enabled for transmission and reception of IP traffic 855 - is configured to respond to LLMNR queries using additional 856 UNIQUE resource records 857 - verifies the acquisition of a new IP address and configuration 858 on an interface 860 To verify uniqueness, a responder MUST send an LLMNR query with the 861 'C' bit clear, over all protocols on which it responds to LLMNR 862 queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify 863 uniqueness of a name by sending a query for the name with type='ANY'. 865 If no response is received, the sender retransmits the query, as 866 specified in Section 2.7. If a response is received, the sender MUST 867 check if the source address matches the address of any of its 868 interfaces; if so, then the response is not considered a conflict, 869 since it originates from the sender. To avoid triggering conflict 870 detection, a responder that detects that it is connected to the same 871 link on multiple interfaces SHOULD set the 'C' bit in responses. 873 If a response is received with the 'T' bit clear, the responder MUST 874 NOT use the name in response to LLMNR queries received over any 875 protocol (IPv4 or IPv6). If a response is received with the 'T' bit 876 set, the responder MUST check if the source IP address in the 877 response, interpreted as an unsigned integer, is less than the source 878 IP address in the query. If so, the responder MUST NOT use the name 879 in response to LLMNR queries received over any protocol (IPv4 or 880 IPv6). For the purpose of uniqueness verification, the contents of 881 the answer section in a response is irrelevant. 883 Periodically carrying out uniqueness verification in an attempt to 884 detect name conflicts is not necessary, wastes network bandwidth, and 885 may actually be detrimental. For example, if network links are 886 joined only briefly, and are separated again before any new 887 communication is initiated, temporary conflicts are benign and no 888 forced reconfiguration is required. LLMNR responders SHOULD NOT 889 periodically attempt uniqueness verification. 891 4.2. Conflict Detection and Defense 893 Hosts on disjoint network links may configure the same name for use 894 with LLMNR. If these separate network links are later joined or 895 bridged together, then there may be multiple hosts which are now on 896 the same link, trying to use the same name. 898 In order to enable ongoing detection of name conflicts, when an LLMNR 899 sender receives multiple LLMNR responses to a query, it MUST check if 900 the 'C' bit is clear in any of the responses. If so, the sender 901 SHOULD send another query for the same name, type and class, this 902 time with the 'C' bit set, with the potentially conflicting resource 903 records included in the additional section. 905 Queries with the 'C' bit set are considered advisory and responders 906 MUST verify the existence of a conflict before acting on it. A 907 responder receiving a query with the 'C' bit set MUST NOT respond. 909 If the query is for a UNIQUE name, then the responder MUST send its 910 own query for the same name, type and class, with the 'C' bit clear. 911 If a response is received, the sender MUST check if the source 912 address matches the address of any of its interfaces; if so, then the 913 response is not considered a conflict, since it originates from the 914 sender. To avoid triggering conflict detection, a responder that 915 detects that it is connected to the same link on multiple interfaces 916 SHOULD set the 'C' bit in responses. 918 An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD 919 log them. Upon detecting a conflict, an LLMNR responder MUST 920 immediately stop using the conflicting name in response to LLMNR 921 queries received over any supported protocol, if the source IP 922 address in the response, interpreted as an unsigned integer, is less 923 than the source IP address in the uniqueness verification query. 925 After stopping the use of a name, the responder MAY elect to 926 configure a new name. However, since name reconfiguration may be 927 disruptive, this is not required, and a responder may have been 928 configured to respond to multiple names so that alternative names may 929 already be available. A host that has stopped the use of a name may 930 attempt uniqueness verification again after the expiration of the TTL 931 of the conflicting response. 933 4.3. Considerations for Multiple Interfaces 935 A multi-homed host may elect to configure LLMNR on only one of its 936 active interfaces. In many situations this will be adequate. 937 However, should a host need to configure LLMNR on more than one of 938 its active interfaces, there are some additional precautions it MUST 939 take. Implementers who are not planning to support LLMNR on multiple 940 interfaces simultaneously may skip this section. 942 Where a host is configured to issue LLMNR queries on more than one 943 interface, each interface maintains its own independent LLMNR 944 resolver cache, containing the responses to LLMNR queries. 946 A multi-homed host checks the uniqueness of UNIQUE records as 947 described in Section 4. The situation is illustrated in figure 1. 949 ---------- ---------- 950 | | | | 951 [A] [myhost] [myhost] 953 Figure 1. Link-scope name conflict 955 In this situation, the multi-homed myhost will probe for, and defend, 956 its host name on both interfaces. A conflict will be detected on one 957 interface, but not the other. The multi-homed myhost will not be 958 able to respond with a host RR for "myhost" on the interface on the 959 right (see Figure 1). The multi-homed host may, however, be 960 configured to use the "myhost" name on the interface on the left. 962 Since names are only unique per-link, hosts on different links could 963 be using the same name. If an LLMNR client sends requests over 964 multiple interfaces, and receives replies from more than one, the 965 result returned to the client is defined by the implementation. The 966 situation is illustrated in figure 2. 968 ---------- ---------- 969 | | | | 970 [A] [myhost] [A] 972 Figure 2. Off-segment name conflict 974 If host myhost is configured to use LLMNR on both interfaces, it will 975 send LLMNR queries on both interfaces. When host myhost sends a 976 query for the host RR for name "A" it will receive a response from 977 hosts on both interfaces. 979 Host myhost cannot distinguish between the situation shown in Figure 980 2, and that shown in Figure 3 where no conflict exists. 982 [A] 983 | | 984 ----- ----- 985 | | 986 [myhost] 988 Figure 3. Multiple paths to same host 990 This illustrates that the proposed name conflict resolution mechanism 991 does not support detection or resolution of conflicts between hosts 992 on different links. This problem can also occur with DNS when a 993 multi-homed host is connected to two different networks with 994 separated name spaces. It is not the intent of this document to 995 address the issue of uniqueness of names within DNS. 997 4.4. API Issues 999 [RFC2553] provides an API which can partially solve the name 1000 ambiguity problem for applications written to use this API, since the 1001 sockaddr_in6 structure exposes the scope within which each scoped 1002 address exists, and this structure can be used for both IPv4 (using 1003 v4-mapped IPv6 addresses) and IPv6 addresses. 1005 Following the example in Figure 2, an application on 'myhost' issues 1006 the request getaddrinfo("A", ...) with ai_family=AF_INET6 and 1007 ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both 1008 interfaces and the resolver library will return a list containing 1009 multiple addrinfo structures, each with an associated sockaddr_in6 1010 structure. This list will thus contain the IPv4 and IPv6 addresses 1011 of both hosts responding to the name 'A'. Link-local addresses will 1012 have a sin6_scope_id value that disambiguates which interface is used 1013 to reach the address. Of course, to the application, Figures 2 and 3 1014 are still indistinguishable, but this API allows the application to 1015 communicate successfully with any address in the list. 1017 5. Security Considerations 1019 LLMNR is a peer-to-peer name resolution protocol designed for use on 1020 the local link. While LLMNR limits the vulnerability of responders 1021 to off-link senders, it is possible for an off-link responder to 1022 reach a sender. 1024 In scenarios such as public "hotspots" attackers can be present on 1025 the same link. These threats are most serious in wireless networks 1026 such as 802.11, since attackers on a wired network will require 1027 physical access to the network, while wireless attackers may mount 1028 attacks from a distance. Link-layer security such as [IEEE-802.11i] 1029 can be of assistance against these threats if it is available. 1031 This section details security measures available to mitigate threats 1032 from on and off-link attackers. 1034 5.1. Denial of Service 1036 Attackers may take advantage of LLMNR conflict detection by 1037 allocating the same name, denying service to other LLMNR responders 1038 and possibly allowing an attacker to receive packets destined for 1039 other hosts. By logging conflicts, LLMNR responders can provide 1040 forensic evidence of these attacks. 1042 An attacker may spoof LLMNR queries from a victim's address in order 1043 to mount a denial of service attack. Responders setting the IPv6 Hop 1044 Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP 1045 response may be able to reach the victim across the Internet. 1047 While LLMNR responders only respond to queries for which they are 1048 authoritative and LLMNR does not provide wildcard query support, an 1049 LLMNR response may be larger than the query, and an attacker can 1050 generate multiple responses to a query for a name used by multiple 1051 responders. A sender may protect itself against unsolicited 1052 responses by silently discarding them as rapidly as possible. 1054 5.2. Spoofing 1056 LLMNR is designed to prevent reception of queries sent by an off-link 1057 attacker. LLMNR requires that responders receiving UDP queries check 1058 that they are sent to a link-scope multicast address. However, it is 1059 possible that some routers may not properly implement link-scope 1060 multicast, or that link-scope multicast addresses may leak into the 1061 multicast routing system. To prevent successful setup of TCP 1062 connections by an off-link sender, responders receiving a TCP SYN 1063 reply with a TCP SYN-ACK with TTL set to one (1). 1065 While it is difficult for an off-link attacker to send an LLMNR query 1066 to a responder, it is possible for an off-link attacker to spoof a 1067 response to a query (such as an A or AAAA query for a popular 1068 Internet host), and by using a TTL or Hop Limit field larger than one 1069 (1), for the forged response to reach the LLMNR sender. Since the 1070 forged response will only be accepted if it contains a matching ID 1071 field, choosing a pseudo-random ID field within queries provides some 1072 protection against off-link responders. 1074 Since LLMNR queries can be sent when DNS server(s) do not respond, an 1075 attacker can execute a denial of service attack on the DNS server(s) 1076 and then poison the LLMNR cache by responding to an LLMNR query with 1077 incorrect information. As noted in "Threat Analysis of the Domain 1078 Name System (DNS)" [RFC3833] these threats also exist with DNS, since 1079 DNS response spoofing tools are available that can allow an attacker 1080 to respond to a query more quickly than a distant DNS server. 1081 However, while switched networks or link layer security may make it 1082 difficult for an on-link attacker to snoop unicast DNS queries, 1083 multicast LLMNR queries are propagated to all hosts on the link, 1084 making it possible for an on-link attacker to spoof LLMNR responses 1085 without having to guess the value of the ID field in the query. 1087 Since LLMNR queries are sent and responded to on the local-link, an 1088 attacker will need to respond more quickly to provide its own 1089 response prior to arrival of the response from a legitimate 1090 responder. If an LLMNR query is sent for an off-link host, spoofing 1091 a response in a timely way is not difficult, since a legitimate 1092 response will never be received. 1094 This vulnerability can be reduced by limiting use of LLMNR to 1095 resolution of single-label names as described in Section 3, or by 1096 implementation of authentication (see Section 5.3). 1098 5.3. Authentication 1100 LLMNR is a peer-to-peer name resolution protocol, and as a result, 1101 it is often deployed in situations where no trust model can be 1102 assumed. Where a pre-arranged security configuration is possible, 1103 the following security mechanisms may be used: 1105 [a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) 1106 [RFC2931] security mechanisms. "DNS Name Service based on Secure 1107 Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes 1108 the use of TSIG to secure LLMNR, based on group keys. While group 1109 keys can be used to demonstrate membership in a group, they do not 1110 protect against forgery by an attacker that is a member of the 1111 group. 1113 [b] IPsec ESP with a null-transform MAY be used to authenticate unicast 1114 LLMNR queries and responses or LLMNR responses to multicast 1115 queries. In a small network without a certificate authority, this 1116 can be most easily accomplished through configuration of a group 1117 pre-shared key for trusted hosts. As with TSIG, this does not 1118 protect against forgery by an attacker with access to the group 1119 pre-shared key. 1121 [c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to 1122 support DNSSEC, LLMNR implementations MAY be configured with trust 1123 anchors, or they MAY make use of keys obtained from DNS queries. 1124 Since LLMNR does not support "delegated trust" (CD or AD bits), 1125 LLMNR implementations cannot make use of DNSSEC unless they are 1126 DNSSEC-aware and support validation. Unlike approaches [a] or [b], 1127 DNSSEC permits a responder to demonstrate ownership of a name, not 1128 just membership within a trusted group. As a result, it enables 1129 protection against forgery. 1131 5.4. Cache and Port Separation 1133 In order to prevent responses to LLMNR queries from polluting the DNS 1134 cache, LLMNR implementations MUST use a distinct, isolated cache for 1135 LLMNR on each interface. The use of separate caches is most 1136 effective when LLMNR is used as a name resolution mechanism of last 1137 resort, since this minimizes the opportunities for poisoning the 1138 LLMNR cache, and decreases reliance on it. 1140 LLMNR operates on a separate port from DNS, reducing the likelihood 1141 that a DNS server will unintentionally respond to an LLMNR query. 1143 If LLMNR is given higher priority than DNS among the enabled name 1144 resolution mechanisms, a denial of service attack on the DNS server 1145 would not be necessary in order to poison the LLMNR cache, since 1146 LLMNR queries would be sent even when the DNS server is available. 1147 In addition, the LLMNR cache, once poisoned, would take precedence 1148 over the DNS cache, eliminating the benefits of cache separation. As 1149 a result, LLMNR SHOULD NOT be used as a primary name resolution 1150 mechanism. 1152 6. IANA Considerations 1154 LLMNR requires allocation of port 5355 for both TCP and UDP. 1156 LLMNR requires allocation of link-scope multicast IPv4 address 1157 224.0.0.252, as well as link-scope multicast IPv6 address 1158 FF02:0:0:0:0:0:1:3. 1160 This specification creates two new name spaces: the LLMNR namespace 1161 and the reserved bits in the LLMNR header. The reserved bits in the 1162 LLMNR header are allocated by IETF Consensus, in accordance with BCP 1163 26 [RFC2434]. 1165 In order to to avoid creating any new administrative procedures, 1166 administration of the LLMNR namespace will piggyback on the 1167 administration of the DNS namespace. 1169 The rights to use a fully qualified domain name (FQDN) within LLMNR 1170 are obtained coincident with acquiring the rights to use that name 1171 within DNS. Those wishing to use a FQDN within LLMNR should first 1172 acquire the rights to use the corresponding FQDN within DNS. Using a 1173 FQDN within LLMNR without ownership of the corresponding name in DNS 1174 creates the possibility of conflict and therefore is discouraged. 1176 LLMNR responders may self-allocate a name within the single-label 1177 name space, first defined in [RFC1001]. Since single-label names are 1178 not unique, no registration process is required. 1180 7. Constants 1182 The following timing constants are used in this protocol; they are 1183 not intended to be user configurable. 1185 JITTER_INTERVAL 100 ms 1186 LLMNR_TIMEOUT 1 second (if set statically on all interfaces) 1187 100 ms (IEEE 802 media, including IEEE 802.11) 1189 8. References 1191 8.1. Normative References 1193 [RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS 1194 Service on a TCP/UDP Transport: Concepts and Methods", RFC 1195 1001, March 1987. 1197 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1198 Specification", RFC 1035, November 1987. 1200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1201 Requirement Levels", BCP 14, RFC 2119, March 1997. 1203 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1204 Specification", RFC 2181, July 1997. 1206 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1207 RFC 2308, March 1998. 1209 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 1210 Architecture", RFC 2373, July 1998. 1212 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1213 Considerations Section in RFCs", BCP 26, RFC 2434, October 1214 1998. 1216 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 1217 August 1999. 1219 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 1220 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 1221 2845, May 2000. 1223 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 1224 (SIG(0)s)", RFC 2931, September 2000. 1226 8.2. Informative References 1228 [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of 1229 Caching", IEEE/ACM Transactions on Networking, Volume 10, 1230 Number 5, pp. 589, October 2002. 1232 [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local 1233 unicast addresses to communicate with recursive DNS servers", 1234 Internet draft (work in progress), draft-ietf-ipv6-dns- 1235 discovery-07.txt, October 2002. 1237 [IEEE-802.11i] 1238 Institute of Electrical and Electronics Engineers, "Supplement 1239 to Standard for Telecommunications and Information Exchange 1240 Between Systems - LAN/MAN Specific Requirements - Part 11: 1241 Wireless LAN Medium Access Control (MAC) and Physical Layer 1242 (PHY) Specifications: Specification for Enhanced Security", 1243 IEEE 802.11i, July 2004. 1245 [LLMNREnable] 1246 Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work 1247 in progress), draft-guttman-mdns-enable-02.txt, April 2002. 1249 [LLMNRSec] 1250 Jeong, J., Park, J. and H. Kim, "DNS Name Service based on 1251 Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT 1252 2004, Phoenix Park, Korea, February 9-11, 2004. 1254 [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- 1255 Portable Operating System Interface (POSIX). Open Group 1256 Technical Standard: Base Specifications, Issue 6, December 1257 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin 1259 [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested 1260 Fixes", RFC 1536, October 1993. 1262 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1263 Recommendations for Security", RFC 1750, December 1994. 1265 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1266 March 1997. 1268 [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", 1269 RFC 2292, February 1998. 1271 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 1272 2365, July 1998. 1274 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 1275 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 1277 [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC 1278 2937, September 2000. 1280 [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for 1281 IPv6 (DHCPv6)", RFC 3315, July 2003. 1283 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 1284 System (DNS)", RFC 3833, August 2004. 1286 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 1287 of Link-Local IPv4 Addresses", RFC 3927, October 2004. 1289 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, 1290 "DNS Security Introduction and Requirement", RFC 4033, March 1291 2005. 1293 Acknowledgments 1295 This work builds upon original work done on multicast DNS by Bill 1296 Manning and Bill Woodcock. Bill Manning's work was funded under 1297 DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge 1298 their contribution to the current specification. Constructive input 1299 has also been received from Mark Andrews, Rob Austein, Randy Bush, 1300 Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur 1301 Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, 1302 Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, 1303 Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike 1304 St. Johns, Sander Van-Valkenburg, and Brian Zill. 1306 Authors' Addresses 1308 Bernard Aboba 1309 Microsoft Corporation 1310 One Microsoft Way 1311 Redmond, WA 98052 1313 Phone: +1 425 706 6605 1314 EMail: bernarda@microsoft.com 1316 Dave Thaler 1317 Microsoft Corporation 1318 One Microsoft Way 1319 Redmond, WA 98052 1321 Phone: +1 425 703 8835 1322 EMail: dthaler@microsoft.com 1324 Levon Esibov 1325 Microsoft Corporation 1326 One Microsoft Way 1327 Redmond, WA 98052 1329 EMail: levone@microsoft.com 1331 Intellectual Property Statement 1333 The IETF takes no position regarding the validity or scope of any 1334 Intellectual Property Rights or other rights that might be claimed to 1335 pertain to the implementation or use of the technology described in 1336 this document or the extent to which any license under such rights 1337 might or might not be available; nor does it represent that it has 1338 made any independent effort to identify any such rights. Information 1339 on the procedures with respect to rights in RFC documents can be 1340 found in BCP 78 and BCP 79. 1342 Copies of IPR disclosures made to the IETF Secretariat and any 1343 assurances of licenses to be made available, or the result of an 1344 attempt made to obtain a general license or permission for the use of 1345 such proprietary rights by implementers or users of this 1346 specification can be obtained from the IETF on-line IPR repository at 1347 http://www.ietf.org/ipr. 1349 The IETF invites any interested party to bring to its attention any 1350 copyrights, patents or patent applications, or other proprietary 1351 rights that may cover technology that may be required to implement 1352 this standard. Please address the information to the IETF at ietf- 1353 ipr@ietf.org. 1355 Disclaimer of Validity 1357 This document and the information contained herein are provided on an 1358 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1359 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1360 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1361 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1362 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1363 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1365 Copyright Statement 1367 Copyright (C) The Internet Society (2005). This document is subject 1368 to the rights, licenses and restrictions contained in BCP 78, and 1369 except as set forth therein, the authors retain all their rights. 1371 Acknowledgment 1373 Funding for the RFC Editor function is currently provided by the 1374 Internet Society. 1376 Open Issues 1378 Open issues with this specification are tracked on the following web 1379 site: 1381 http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html