idnits 2.17.1 draft-ietf-dnsext-mdns-47.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 1345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1335. ** 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: ---------------------------------------------------------------------------- No issues found here. 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 1 instance 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 1 instance 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (13 August 2006) is 6458 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 686 -- Looks like a reference, but probably isn't: '2' on line 695 == Missing Reference: 'A' is mentioned on line 978, but not defined == Unused Reference: 'RFC2434' is defined on line 1194, but no explicit reference was found in the text ** 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 13 August 2006 8 Link-local 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 January 15, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society 2006. 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 .................................... 3 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 RR 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 ............................................ 25 79 8.1 Normative References ............................ 25 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 query, 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 responses 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 responder is authoritative for a name, it MUST respond with 424 RCODE=0 and an empty answer section, if the type of query does not 425 match a RR that the responder has. 427 As an example, a host configured to respond to LLMNR queries for the 428 name "foo.example.com." is authoritative for the name 429 "foo.example.com.". On receiving an LLMNR query for an A RR with the 430 name "foo.example.com." the host authoritatively responds with A 431 RR(s) that contain IP address(es) in the RDATA of the resource 432 record. If the responder has a AAAA RR, but no A RR, and an A RR 433 query is received, the responder would respond with RCODE=0 and an 434 empty answer section. 436 In conventional DNS terminology a DNS server authoritative for a zone 437 is authoritative for all the domain names under the zone apex except 438 for the branches delegated into separate zones. Contrary to 439 conventional DNS terminology, an LLMNR responder is authoritative 440 only for the zone apex. 442 For example the host "foo.example.com." is not authoritative for the 443 name "child.foo.example.com." unless the host is configured with 444 multiple names, including "foo.example.com." and 445 "child.foo.example.com.". As a result, "foo.example.com." cannot 446 respond to an LLMNR query for "child.foo.example.com." with RCODE=3 447 (authoritative name error). The purpose of limiting the name 448 authority scope of a responder is to prevent complications that could 449 be caused by coexistence of two or more hosts with the names 450 representing child and parent (or grandparent) nodes in the DNS tree, 451 for example, "foo.example.com." and "child.foo.example.com.". 453 Without the restriction on authority an LLMNR query for an A resource 454 record for the name "child.foo.example.com." would result in two 455 authoritative responses: RCODE=3 (authoritative name error) received 456 from "foo.example.com.", and a requested A record - from 457 "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled 458 hosts could perform a dynamic update of the parent (or grandparent) 459 zone with a delegation to a child zone; for example a host 460 "child.foo.example.com." could send a dynamic update for the NS and 461 glue A record to "foo.example.com.". However, this approach 462 significantly complicates implementation of LLMNR and would not be 463 acceptable for lightweight hosts. 465 2.4. Unicast Queries and Responses 467 Unicast queries SHOULD be sent when: 469 [a] A sender repeats a query after it received a response 470 with the TC bit set to the previous LLMNR multicast query, or 472 [b] The sender queries for a PTR RR of a fully formed IP address 473 within the "in-addr.arpa" or "ip6.arpa" zones. 475 Unicast LLMNR queries MUST be done using TCP and the responses MUST 476 be sent using the same TCP connection as the query. Senders MUST 477 support sending TCP queries, and responders MUST support listening 478 for TCP queries. If the sender of a TCP query receives a response to 479 that query not using TCP, the response MUST be silently discarded. 481 Unicast UDP queries MUST be silently discarded. 483 A unicast PTR RR query for an off-link address will not elicit a 484 response, but instead an ICMP TTL or Hop Limit exceeded message will 485 be received. An implementation receiving an ICMP message in response 486 to a TCP connection setup attempt can return immediately, treating 487 this as a response that no such name exists (RCODE=3 is returned). 488 An implementation that cannot process ICMP messages MAY send 489 multicast UDP queries for PTR RRs. Since TCP implementations will 490 not retransmit prior to RTOmin, a considerable period will elapse 491 before TCP retransmits multiple times, resulting in a long timeout 492 for TCP PTR RR queries sent to an off-link destination. 494 2.5. "Off link" Detection 496 A sender MUST select a source address for LLMNR queries that is 497 assigned on the interface on which the query is sent. The 498 destination address of an LLMNR query MUST be a link-scope multicast 499 address or a unicast address. 501 A responder MUST select a source address for responses that is 502 assigned on the interface on which the query was received. The 503 destination address of an LLMNR response MUST be a unicast address. 505 On receiving an LLMNR query, the responder MUST check whether it was 506 sent to a LLMNR multicast addresses defined in Section 2. If it was 507 sent to another multicast address, then the query MUST be silently 508 discarded. 510 Section 2.4 discusses use of TCP for LLMNR queries and responses. In 511 composing an LLMNR query using TCP, the sender MUST set the Hop Limit 512 field in the IPv6 header and the TTL field in the IPv4 header of the 513 response to one (1). The responder SHOULD set the TTL or Hop Limit 514 settings on the TCP listen socket to one (1) so that SYN-ACK packets 515 will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This 516 prevents an incoming connection from off-link since the sender will 517 not receive a SYN-ACK from the responder. 519 For UDP queries and responses, the Hop Limit field in the IPv6 header 520 and the TTL field in the IPV4 header MAY be set to any value. 521 However, it is RECOMMENDED that the value 255 be used for 522 compatibility with early implementations of [RFC3927]. 524 Implementation note: 526 In the sockets API for IPv4 [POSIX], the IP_TTL and 527 IP_MULTICAST_TTL socket options are used to set the TTL of 528 outgoing unicast and multicast packets. The IP_RECVTTL socket 529 option is available on some platforms to retrieve the IPv4 TTL of 530 received packets with recvmsg(). [RFC2292] specifies similar 531 options for setting and retrieving the IPv6 Hop Limit. 533 2.6. Responder Responsibilities 535 It is the responsibility of the responder to ensure that RRs returned 536 in LLMNR responses MUST only include values that are valid on the 537 local interface, such as IPv4 or IPv6 addresses valid on the local 538 link or names defended using the mechanism described in Section 4. 539 IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local 540 addresses are defined in [RFC2373]. In particular: 542 [a] If a link-scope IPv6 address is returned in a AAAA RR, 543 that address MUST be valid on the local link over which 544 LLMNR is used. 546 [b] If an IPv4 address is returned, it MUST be reachable 547 through the link over which LLMNR is used. 549 [c] If a name is returned (for example in a CNAME, MX 550 or SRV RR), the name MUST be resolvable on the local 551 link over which LLMNR is used. 553 Where multiple addresses represent valid responses to a query, the 554 order in which the addresses are returned is as follows: 556 [d] If the source address of the query is a link-scope address, 557 then the responder SHOULD include a link-scope address first 558 in the response, if available. 560 [e] If the source address of the query is a routable address, 561 then the responder MUST include a routable address first 562 in the response, if available. 564 2.7. Retransmission and Jitter 566 An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine 567 when to retransmit an LLMNR query. An LLMNR sender SHOULD either 568 estimate the LLMNR_TIMEOUT for each interface, or set a reasonably 569 high initial timeout. Suggested constants are described in Section 570 7. 572 If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, 573 then a sender SHOULD repeat the transmission of the query in order to 574 assure that it was received by a host capable of responding to it. 575 An LLMNR query SHOULD NOT be sent more than three times. 577 Where LLMNR queries are sent using TCP, retransmission is handled by 578 the transport layer. Queries with the 'C' bit set MUST be sent using 579 multicast UDP and MUST NOT be retransmitted. 581 An LLMNR sender cannot know in advance if a query sent using 582 multicast will receive no response, one response, or more than one 583 response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response 584 has been received, or if it is necessary to collect all potential 585 responses, such as if a uniqueness verification query is being made. 586 Otherwise an LLMNR sender SHOULD consider a multicast query answered 587 after the first response is received, if that response has the 'C' 588 bit clear. 590 However, if the first response has the 'C' bit set, then the sender 591 SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect 592 all possible responses. When multiple valid answers are received, 593 they may first be concatenated, and then treated in the same manner 594 that multiple RRs received from the same DNS server would. A unicast 595 query sender considers the query answered after the first response is 596 received. 598 Since it is possible for a response with the 'C' bit clear to be 599 followed by a response with the 'C' bit set, an LLMNR sender SHOULD 600 be prepared to process additional responses for the purposes of 601 conflict detection, even after it has considered a query answered. 603 In order to avoid synchronization, the transmission of each LLMNR 604 query and response SHOULD delayed by a time randomly selected from 605 the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by 606 responders responding with names which they have previously 607 determined to be UNIQUE (see Section 4 for details). 609 2.8. RR TTL 611 The responder should insert a pre-configured TTL value in the records 612 returned in an LLMNR response. A default value of 30 seconds is 613 RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc 614 networks), the TTL value may need to be reduced. 616 Due to the TTL minimalization necessary when caching an RRset, all 617 TTLs in an RRset MUST be set to the same value. 619 2.9. Use of the Authority and Additional Sections 621 Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a 622 concept of delegation. In LLMNR, the NS resource record type may be 623 stored and queried for like any other type, but it has no special 624 delegation semantics as it does in the DNS. Responders MAY have NS 625 records associated with the names for which they are authoritative, 626 but they SHOULD NOT include these NS records in the authority 627 sections of responses. 629 Responders SHOULD insert an SOA record into the authority section of 630 a negative response, to facilitate negative caching as specified in 631 [RFC2308]. The TTL of this record is set from the minimum of the 632 MINIMUM field of the SOA record and the TTL of the SOA itself, and 633 indicates how long a resolver may cache the negative answer. The 634 owner name of the SOA record (MNAME) MUST be set to the query name. 635 The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored 636 by senders. Negative responses without SOA records SHOULD NOT be 637 cached. 639 In LLMNR, the additional section is primarily intended for use by 640 EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, 641 senders MAY only include pseudo RR-types in the additional section of 642 a query; unless the 'C' bit is set, responders MUST ignore the 643 additional section of queries containing other RR types. 645 In queries where the 'C' bit is set, the sender SHOULD include the 646 conflicting RRs in the additional section. Since conflict 647 notifications are advisory, responders SHOULD log information from 648 the additional section, but otherwise MUST ignore the additional 649 section. 651 Senders MUST NOT cache RRs from the authority or additional section 652 of a response as answers, though they may be used for other purposes 653 such as negative caching. 655 3. Usage Model 657 By default, an LLMNR sender SHOULD send LLMNR queries only for 658 single-label names. Stub resolvers supporting both DNS and LLMNR 659 SHOULD avoid sending DNS queries for single-label names, in order to 660 reduce unnecessary DNS queries. An LLMNR sender SHOULD NOT be 661 enabled to send a query for any name, except where security 662 mechanisms (described in Section 5.3) can be utilized. An LLMNR 663 query SHOULD only be sent for the originally requested name; a 664 searchlist is not used to form additional LLMNR queries. 666 LLMNR is a peer-to-peer name resolution protocol that is not intended 667 as a replacement for DNS; rather, it enables name resolution in 668 scenarios in which conventional DNS name resolution is not possible. 669 Where LLMNR security is not enabled as described in Section 5.3, if 670 LLMNR is given higher priority than DNS among the enabled name 671 resolution mechanisms, this would allow the LLMNR cache, once 672 poisoned, to take precedence over the DNS cache. As a result, use of 673 LLMNR as a primary name resolution mechanism is NOT RECOMMENDED. 675 Instead, it is recommended that LLMNR be utilized as a secondary name 676 resolution mechanism, for use in situations where hosts are not 677 configured with the address of a DNS server; where the DNS server is 678 unavailable or unreachable; where there is no DNS server 679 authoritative for the name of a host, or where the authoritative DNS 680 server does not have the desired RRs. 682 When LLMNR is configured as a secondary name resolution mechanism, 683 LLMNR queries SHOULD only be sent when all of the following 684 conditions are met: 686 [1] No manual or automatic DNS configuration has been performed. 687 If DNS server address(es) have been configured, a 688 host SHOULD attempt to reach DNS servers over all protocols 689 on which DNS server address(es) are configured, prior to sending 690 LLMNR queries. For dual stack hosts configured with DNS server 691 address(es) for one protocol but not another, this implies that 692 DNS queries SHOULD be sent over the protocol configured with 693 a DNS server, prior to sending LLMNR queries. 695 [2] All attempts to resolve the name via DNS on all interfaces 696 have failed after exhausting the searchlist. This can occur 697 because DNS servers did not respond, or because they 698 responded to DNS queries with RCODE=3 (Authoritative Name 699 Error) or RCODE=0, and an empty answer section. Where a 700 single resolver call generates DNS queries for A and AAAA RRs, 701 an implementation MAY choose not to send LLMNR queries if any 702 of the DNS queries is successful. 704 Where LLMNR is used as a secondary name resolution mechanism, its 705 usage is in part determined by the behavior of DNS resolver 706 implementations; robust resolver implementations are more likely to 707 avoid unnecessary LLMNR queries. 709 [RFC1536] describes common DNS implementation errors and fixes. If 710 the proposed fixes are implemented, unnecessary LLMNR queries will be 711 reduced substantially, and so implementation of [RFC1536] is 712 recommended. 714 For example, [RFC1536] Section 1 describes issues with retransmission 715 and recommends implementation of a retransmission policy based on 716 round trip estimates, with exponential back-off. [RFC1536] Section 4 717 describes issues with failover, and recommends that resolvers try 718 another server when they don't receive a response to a query. These 719 policies are likely to avoid unnecessary LLMNR queries. 721 [RFC1536] Section 3 describes zero answer bugs, which if addressed 722 will also reduce unnecessary LLMNR queries. 724 [RFC1536] Section 6 describes name error bugs and recommended 725 searchlist processing that will reduce unnecessary RCODE=3 726 (authoritative name) errors, thereby also reducing unnecessary LLMNR 727 queries. 729 As noted in [DNSPerf] significant fraction of DNS queries do not 730 receive a response, or result in negative responses due to missing 731 inverse mappings or NS records that point to nonexistent or 732 inappropriate hosts. Therefore a reduction in missing records can 733 prevent many unnecessary LLMNR queries. 735 3.1. LLMNR Configuration 737 LLMNR usage MAY be configured manually or automatically on a per 738 interface basis. By default, LLMNR responders SHOULD be enabled on 739 all interfaces, at all times. Where this is considered undesirable, 740 LLMNR SHOULD be disabled, so that hosts will neither listen on the 741 link-scope multicast address, nor will they send queries to that 742 address. 744 Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to 745 configure LLMNR on an interface. The LLMNR Enable Option, described 746 in [LLMNREnable], can be used to explicitly enable or disable use of 747 LLMNR on an interface. The LLMNR Enable Option does not determine 748 whether or in which order DNS itself is used for name resolution. 749 The order in which various name resolution mechanisms should be used 750 can be specified using the Name Service Search Option (NSSO) for DHCP 751 [RFC2937], using the LLMNR Enable Option code carried in the NSSO 752 data. 754 In situations where LLMNR is configured as a secondary name 755 resolution protocol on a dual-stack host, behavior will be governed 756 by both IPv4 and IPv6 configuration mechanisms. Since IPv4 and IPv6 757 utilize distinct configuration mechanisms, it is possible for a dual 758 stack host to be configured with the address of a DNS server over 759 IPv4, while remaining unconfigured with a DNS server suitable for use 760 over IPv6. 762 In these situations, a dual stack host will send AAAA queries to the 763 configured DNS server over IPv4. However, an IPv6-only host 764 unconfigured with a DNS server suitable for use over IPv6 will be 765 unable to resolve names using DNS. Automatic IPv6 DNS configuration 766 mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely 767 deployed, and not all DNS servers support IPv6. Therefore lack of 768 IPv6 DNS configuration may be a common problem in the short term, and 769 LLMNR may prove useful in enabling link-local name resolution over 770 IPv6. 772 Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], 773 IPv6-only hosts may not be configured with a DNS server. Where there 774 is no DNS server authoritative for the name of a host or the 775 authoritative DNS server does not support dynamic client update over 776 IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not 777 be able to do DNS dynamic update, and other hosts will not be able to 778 resolve its name. 780 For example, if the configured DNS server responds to a AAAA RR query 781 sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or 782 RCODE=0 and an empty answer section, then a AAAA RR query sent using 783 LLMNR over IPv6 may be successful in resolving the name of an 784 IPv6-only host on the local link. 786 Similarly, if a DHCPv4 server is available providing DNS server 787 configuration, and DNS server(s) exist which are authoritative for 788 the A RRs of local hosts and support either dynamic client update 789 over IPv4 or DHCPv4-based dynamic update, then the names of local 790 IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no 791 DNS server is authoritative for the names of local hosts, or the 792 authoritative DNS server(s) do not support dynamic update, then LLMNR 793 enables link-local name resolution over IPv4. 795 It is possible that DNS configuration mechanisms will go in and out 796 of service. In these circumstances, it is possible for hosts within 797 an administrative domain to be inconsistent in their DNS 798 configuration. 800 For example, where DHCP is used for configuring DNS servers, one or 801 more DHCP servers can fail. As a result, hosts configured prior to 802 the outage will be configured with a DNS server, while hosts 803 configured after the outage will not. Alternatively, it is possible 804 for the DNS configuration mechanism to continue functioning while 805 configured DNS servers fail. 807 An outage in the DNS configuration mechanism may result in hosts 808 continuing to use LLMNR even once the outage is repaired. Since 809 LLMNR only enables link-local name resolution, this represents a 810 degradation in capabilities. As a result, hosts without a configured 811 DNS server may wish to periodically attempt to obtain DNS 812 configuration if permitted by the configuration mechanism in use. In 813 the absence of other guidance, a default retry interval of one (1) 814 minute is RECOMMENDED. 816 4. Conflict Resolution 818 By default, a responder SHOULD be configured to behave as though its 819 name is UNIQUE on each interface on which LLMNR is enabled. However, 820 it is also possible to configure multiple responders to be 821 authoritative for the same name. For example, multiple responders 822 MAY respond to a query for an A or AAAA type record for a cluster 823 name (assigned to multiple hosts in the cluster). 825 To detect duplicate use of a name, an administrator can use a name 826 resolution utility which employs LLMNR and lists both responses and 827 responders. This would allow an administrator to diagnose behavior 828 and potentially to intervene and reconfigure LLMNR responders who 829 should not be configured to respond to the same name. 831 4.1. Uniqueness Verification 833 Prior to sending an LLMNR response with the 'T' bit clear, a 834 responder configured with a UNIQUE name MUST verify that there is no 835 other host within the scope of LLMNR query propagation that is 836 authoritative for the same name on that interface. 838 Once a responder has verified that its name is UNIQUE, if it receives 839 an LLMNR query for that name, with the 'C' bit clear, it MUST 840 respond, with the 'T' bit clear. Prior to verifying that its name is 841 UNIQUE, a responder MUST set the 'T' bit in responses. 843 Uniqueness verification is carried out when the host: 845 - starts up or is rebooted 846 - wakes from sleep (if the network interface was inactive 847 during sleep) 849 - is configured to respond to LLMNR queries on an interface 850 enabled for transmission and reception of IP traffic 851 - is configured to respond to LLMNR queries using additional 852 UNIQUE resource records 853 - verifies the acquisition of a new IP address and configuration 854 on an interface 856 To verify uniqueness, a responder MUST send an LLMNR query with the 857 'C' bit clear, over all protocols on which it responds to LLMNR 858 queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify 859 uniqueness of a name by sending a query for the name with type='ANY'. 861 If no response is received, the sender retransmits the query, as 862 specified in Section 2.7. If a response is received, the sender MUST 863 check if the source address matches the address of any of its 864 interfaces; if so, then the response is not considered a conflict, 865 since it originates from the sender. To avoid triggering conflict 866 detection, a responder that detects that it is connected to the same 867 link on multiple interfaces SHOULD set the 'C' bit in responses. 869 If a response is received with the 'T' bit clear, the responder MUST 870 NOT use the name in response to LLMNR queries received over any 871 protocol (IPv4 or IPv6). If a response is received with the 'T' bit 872 set, the responder MUST check if the source IP address in the 873 response is lexicographically smaller than the source IP address in 874 the query. If so, the responder MUST NOT use the name in response to 875 LLMNR queries received over any protocol (IPv4 or IPv6). For the 876 purpose of uniqueness verification, the contents of the answer 877 section in a response is irrelevant. 879 Periodically carrying out uniqueness verification in an attempt to 880 detect name conflicts is not necessary, wastes network bandwidth, and 881 may actually be detrimental. For example, if network links are 882 joined only briefly, and are separated again before any new 883 communication is initiated, temporary conflicts are benign and no 884 forced reconfiguration is required. LLMNR responders SHOULD NOT 885 periodically attempt uniqueness verification. 887 4.2. Conflict Detection and Defense 889 Hosts on disjoint network links may configure the same name for use 890 with LLMNR. If these separate network links are later joined or 891 bridged together, then there may be multiple hosts which are now on 892 the same link, trying to use the same name. 894 In order to enable ongoing detection of name conflicts, when an LLMNR 895 sender receives multiple LLMNR responses to a query, it MUST check if 896 the 'C' bit is clear in any of the responses. If so, the sender 897 SHOULD send another query for the same name, type and class, this 898 time with the 'C' bit set, with the potentially conflicting resource 899 records included in the additional section. 901 Queries with the 'C' bit set are considered advisory and responders 902 MUST verify the existence of a conflict before acting on it. A 903 responder receiving a query with the 'C' bit set MUST NOT respond. 905 If the query is for a UNIQUE name, then the responder MUST send its 906 own query for the same name, type and class, with the 'C' bit clear. 907 If a response is received, the sender MUST check if the source 908 address matches the address of any of its interfaces; if so, then the 909 response is not considered a conflict, since it originates from the 910 sender. To avoid triggering conflict detection, a responder that 911 detects that it is connected to the same link on multiple interfaces 912 SHOULD set the 'C' bit in responses. 914 An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD 915 log them. Upon detecting a conflict, an LLMNR responder MUST 916 immediately stop using the conflicting name in response to LLMNR 917 queries received over any supported protocol, if the source IP 918 address in the response, is lexicographically smaller than than the 919 source IP address in the uniqueness verification query. 921 After stopping the use of a name, the responder MAY elect to 922 configure a new name. However, since name reconfiguration may be 923 disruptive, this is not required, and a responder may have been 924 configured to respond to multiple names so that alternative names may 925 already be available. A host that has stopped the use of a name may 926 attempt uniqueness verification again after the expiration of the TTL 927 of the conflicting response. 929 4.3. Considerations for Multiple Interfaces 931 A multi-homed host may elect to configure LLMNR on only one of its 932 active interfaces. In many situations this will be adequate. 933 However, should a host need to configure LLMNR on more than one of 934 its active interfaces, there are some additional precautions it MUST 935 take. Implementers who are not planning to support LLMNR on multiple 936 interfaces simultaneously may skip this section. 938 Where a host is configured to issue LLMNR queries on more than one 939 interface, each interface maintains its own independent LLMNR 940 resolver cache, containing the responses to LLMNR queries. 942 A multi-homed host checks the uniqueness of UNIQUE records as 943 described in Section 4. The situation is illustrated in Figure 1. 945 ---------- ---------- 946 | | | | 947 [A] [myhost] [myhost] 949 Figure 1. Link-scope name conflict 951 In this situation, the multi-homed myhost will probe for, and defend, 952 its host name on both interfaces. A conflict will be detected on one 953 interface, but not the other. The multi-homed myhost will not be 954 able to respond with a host RR for "myhost" on the interface on the 955 right (see Figure 1). The multi-homed host may, however, be 956 configured to use the "myhost" name on the interface on the left. 958 Since names are only unique per-link, hosts on different links could 959 be using the same name. If an LLMNR client sends queries over 960 multiple interfaces, and receives responses from more than one, the 961 result returned to the client is defined by the implementation. The 962 situation is illustrated in Figure 2. 964 ---------- ---------- 965 | | | | 966 [A] [myhost] [A] 968 Figure 2. Off-segment name conflict 970 If host myhost is configured to use LLMNR on both interfaces, it will 971 send LLMNR queries on both interfaces. When host myhost sends a 972 query for the host RR for name "A" it will receive a response from 973 hosts on both interfaces. 975 Host myhost cannot distinguish between the situation shown in Figure 976 2, and that shown in Figure 3 where no conflict exists. 978 [A] 979 | | 980 ----- ----- 981 | | 982 [myhost] 984 Figure 3. Multiple paths to same host 986 This illustrates that the proposed name conflict resolution mechanism 987 does not support detection or resolution of conflicts between hosts 988 on different links. This problem can also occur with DNS when a 989 multi-homed host is connected to two different networks with 990 separated name spaces. It is not the intent of this document to 991 address the issue of uniqueness of names within DNS. 993 4.4. API Issues 995 [RFC2553] provides an API which can partially solve the name 996 ambiguity problem for applications written to use this API, since the 997 sockaddr_in6 structure exposes the scope within which each scoped 998 address exists, and this structure can be used for both IPv4 (using 999 v4-mapped IPv6 addresses) and IPv6 addresses. 1001 Following the example in Figure 2, an application on 'myhost' issues 1002 the request getaddrinfo("A", ...) with ai_family=AF_INET6 and 1003 ai_flags=AI_ALL|AI_V4MAPPED. LLMNR queries will be sent from both 1004 interfaces and the resolver library will return a list containing 1005 multiple addrinfo structures, each with an associated sockaddr_in6 1006 structure. This list will thus contain the IPv4 and IPv6 addresses 1007 of both hosts responding to the name 'A'. Link-local addresses will 1008 have a sin6_scope_id value that disambiguates which interface is used 1009 to reach the address. Of course, to the application, Figures 2 and 3 1010 are still indistinguishable, but this API allows the application to 1011 communicate successfully with any address in the list. 1013 5. Security Considerations 1015 LLMNR is a peer-to-peer name resolution protocol designed for use on 1016 the local link. While LLMNR limits the vulnerability of responders 1017 to off-link senders, it is possible for an off-link responder to 1018 reach a sender. 1020 In scenarios such as public "hotspots" attackers can be present on 1021 the same link. These threats are most serious in wireless networks 1022 such as IEEE 802.11, since attackers on a wired network will require 1023 physical access to the network, while wireless attackers may mount 1024 attacks from a distance. Link-layer security such as [IEEE-802.11i] 1025 can be of assistance against these threats if it is available. 1027 This section details security measures available to mitigate threats 1028 from on and off-link attackers. 1030 5.1. Denial of Service 1032 Attackers may take advantage of LLMNR conflict detection by 1033 allocating the same name, denying service to other LLMNR responders 1034 and possibly allowing an attacker to receive packets destined for 1035 other hosts. By logging conflicts, LLMNR responders can provide 1036 forensic evidence of these attacks. 1038 An attacker may spoof LLMNR queries from a victim's address in order 1039 to mount a denial of service attack. Responders setting the IPv6 Hop 1040 Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP 1041 response may be able to reach the victim across the Internet. 1043 While LLMNR responders only respond to queries for which they are 1044 authoritative and LLMNR does not provide wildcard query support, an 1045 LLMNR response may be larger than the query, and an attacker can 1046 generate multiple responses to a query for a name used by multiple 1047 responders. A sender may protect itself against unsolicited 1048 responses by silently discarding them. 1050 5.2. Spoofing 1052 LLMNR is designed to prevent reception of queries sent by an off-link 1053 attacker. LLMNR requires that responders receiving UDP queries check 1054 that they are sent to a link-scope multicast address. However, it is 1055 possible that some routers may not properly implement link-scope 1056 multicast, or that link-scope multicast addresses may leak into the 1057 multicast routing system. To prevent successful setup of TCP 1058 connections by an off-link sender, responders receiving a TCP SYN 1059 reply with a TCP SYN-ACK with TTL set to one (1). 1061 While it is difficult for an off-link attacker to send an LLMNR query 1062 to a responder, it is possible for an off-link attacker to spoof a 1063 response to a query (such as an A or AAAA query for a popular 1064 Internet host), and by using a TTL or Hop Limit field larger than one 1065 (1), for the forged response to reach the LLMNR sender. Since the 1066 forged response will only be accepted if it contains a matching ID 1067 field, choosing a pseudo-random ID field within queries provides some 1068 protection against off-link responders. 1070 When LLMNR is utilized as a secondary name resolution service, 1071 queries can be sent when DNS server(s) do not respond. An attacker 1072 can execute a denial of service attack on the DNS server(s) and then 1073 poison the LLMNR cache by responding to an LLMNR query with incorrect 1074 information. As noted in "Threat Analysis of the Domain Name System 1075 (DNS)" [RFC3833] these threats also exist with DNS, since DNS 1076 response spoofing tools are available that can allow an attacker to 1077 respond to a query more quickly than a distant DNS server. However, 1078 while switched networks or link-layer security may make it difficult 1079 for an on-link attacker to snoop unicast DNS queries, multicast 1080 LLMNR queries are propagated to all hosts on the link, making it 1081 possible for an on-link attacker to spoof LLMNR responses without 1082 having to guess the value of the ID field in the query. 1084 Since LLMNR queries are sent and responded to on the local link, an 1085 attacker will need to respond more quickly to provide its own 1086 response prior to arrival of the response from a legitimate 1087 responder. If an LLMNR query is sent for an off-link host, spoofing 1088 a response in a timely way is not difficult, since a legitimate 1089 response will never be received. 1091 This vulnerability can be reduced by limiting use of LLMNR to 1092 resolution of single-label names as described in Section 3, or by 1093 implementation of authentication (see Section 5.3). 1095 5.3. Authentication 1097 LLMNR is a peer-to-peer name resolution protocol, and as a result, 1098 it is often deployed in situations where no trust model can be 1099 assumed. Where a pre-arranged security configuration is possible, 1100 the following security mechanisms may be used: 1102 [a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) 1103 [RFC2931] security mechanisms. "DNS Name Service based on Secure 1104 Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes 1105 the use of TSIG to secure LLMNR, based on group keys. While group 1106 keys can be used to demonstrate membership in a group, they do not 1107 protect against forgery by an attacker that is a member of the 1108 group. 1110 [b] IPsec ESP with null encryption algorithm MAY be used to 1111 authenticate unicast LLMNR queries and responses or LLMNR responses 1112 to multicast queries. In a small network without a certificate 1113 authority, this can be most easily accomplished through 1114 configuration of a group pre-shared key for trusted hosts. As with 1115 TSIG, this does not protect against forgery by an attacker with 1116 access to the group pre-shared key. 1118 [c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to 1119 support DNSSEC, LLMNR implementations MAY be configured with trust 1120 anchors, or they MAY make use of keys obtained from DNS queries. 1121 Since LLMNR does not support "delegated trust" (CD or AD bits), 1122 LLMNR implementations cannot make use of DNSSEC unless they are 1123 DNSSEC-aware and support validation. Unlike approaches [a] or [b], 1124 DNSSEC permits a responder to demonstrate ownership of a name, not 1125 just membership within a trusted group. As a result, it enables 1126 protection against forgery. 1128 5.4. Cache and Port Separation 1130 In order to prevent responses to LLMNR queries from polluting the DNS 1131 cache, LLMNR implementations MUST use a distinct, isolated cache for 1132 LLMNR on each interface. LLMNR operates on a separate port from DNS, 1133 reducing the likelihood that a DNS server will unintentionally 1134 respond to an LLMNR query. 1136 If a DNS server is running on a host that supports LLMNR, the LLMNR 1137 responder on that host MUST respond to LLMNR queries only for the 1138 RRSets relating to the host on which the server is running, but MUST 1139 NOT respond for other records for which the DNS server is 1140 authoritative. DNS servers MUST NOT send LLMNR queries in order to 1141 resolve DNS queries. 1143 6. IANA Considerations 1145 This specification creates a new name space: the LLMNR namespace. 1147 In order to to avoid creating any new administrative procedures, 1148 administration of the LLMNR namespace will piggyback on the 1149 administration of the DNS namespace. 1151 The rights to use a fully qualified domain name (FQDN) within LLMNR 1152 are obtained by acquiring the rights to use that name within DNS. 1153 Those wishing to use a FQDN within LLMNR should first acquire the 1154 rights to use the corresponding FQDN within DNS. Using a FQDN within 1155 LLMNR without ownership of the corresponding name in DNS creates the 1156 possibility of conflict and therefore is discouraged. 1158 LLMNR responders may self-allocate a name within the single-label 1159 name space, first defined in [RFC1001]. Since single-label names are 1160 not unique, no registration process is required. 1162 7. Constants 1164 The following timing constants are used in this protocol; they are 1165 not intended to be user configurable. 1167 JITTER_INTERVAL 100 ms 1168 LLMNR_TIMEOUT 1 second (if set statically on all interfaces) 1169 100 ms (IEEE 802 media, including IEEE 802.11) 1171 8. References 1173 8.1. Normative References 1175 [RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS 1176 Service on a TCP/UDP Transport: Concepts and Methods", RFC 1177 1001, March 1987. 1179 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1180 Specification", RFC 1035, November 1987. 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, March 1997. 1185 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1186 Specification", RFC 2181, July 1997. 1188 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1189 RFC 2308, March 1998. 1191 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 1192 Architecture", RFC 2373, July 1998. 1194 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1195 Considerations Section in RFCs", BCP 26, RFC 2434, October 1196 1998. 1198 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 1199 August 1999. 1201 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 1202 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 1203 2845, May 2000. 1205 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 1206 (SIG(0)s)", RFC 2931, September 2000. 1208 8.2. Informative References 1210 [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of 1211 Caching", IEEE/ACM Transactions on Networking, Volume 10, 1212 Number 5, pp. 589, October 2002. 1214 [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local 1215 unicast addresses to communicate with recursive DNS servers", 1216 Internet draft (work in progress), draft-ietf-ipv6-dns- 1217 discovery-07.txt, October 2002. 1219 [IEEE-802.11i] 1220 Institute of Electrical and Electronics Engineers, "Supplement 1221 to Standard for Telecommunications and Information Exchange 1222 Between Systems - LAN/MAN Specific Requirements - Part 11: 1223 Wireless LAN Medium Access Control (MAC) and Physical Layer 1224 (PHY) Specifications: Specification for Enhanced Security", 1225 IEEE 802.11i, July 2004. 1227 [LLMNREnable] 1228 Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work 1229 in progress), draft-guttman-mdns-enable-02.txt, April 2002. 1231 [LLMNRSec] 1232 Jeong, J., Park, J. and H. Kim, "DNS Name Service based on 1233 Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT 1234 2004, Phoenix Park, Korea, February 9-11, 2004. 1236 [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- 1237 Portable Operating System Interface (POSIX). Open Group 1238 Technical Standard: Base Specifications, Issue 6, December 1239 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin 1241 [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested 1242 Fixes", RFC 1536, October 1993. 1244 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1245 Recommendations for Security", RFC 1750, December 1994. 1247 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 1248 March 1997. 1250 [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", 1251 RFC 2292, February 1998. 1253 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 1254 2365, July 1998. 1256 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 1257 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 1259 [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC 1260 2937, September 2000. 1262 [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for 1263 IPv6 (DHCPv6)", RFC 3315, July 2003. 1265 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 1266 System (DNS)", RFC 3833, August 2004. 1268 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 1269 of Link-Local IPv4 Addresses", RFC 3927, October 2004. 1271 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, 1272 "DNS Security Introduction and Requirement", RFC 4033, March 1273 2005. 1275 Acknowledgments 1277 This work builds upon original work done on multicast DNS by Bill 1278 Manning and Bill Woodcock. Bill Manning's work was funded under 1279 DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge 1280 their contribution to the current specification. Constructive input 1281 has also been received from Mark Andrews, Rob Austein, Randy Bush, 1282 Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur 1283 Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, 1284 Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, 1285 Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike 1286 St. Johns, Sander van Valkenburg, and Brian Zill. 1288 Authors' Addresses 1290 Bernard Aboba 1291 Microsoft Corporation 1292 One Microsoft Way 1293 Redmond, WA 98052 1295 Phone: +1 425 706 6605 1296 EMail: bernarda@microsoft.com 1298 Dave Thaler 1299 Microsoft Corporation 1300 One Microsoft Way 1301 Redmond, WA 98052 1303 Phone: +1 425 703 8835 1304 EMail: dthaler@microsoft.com 1306 Levon Esibov 1307 Microsoft Corporation 1308 One Microsoft Way 1309 Redmond, WA 98052 1311 EMail: levone@microsoft.com 1313 Intellectual Property Statement 1315 The IETF takes no position regarding the validity or scope of any 1316 Intellectual Property Rights or other rights that might be claimed to 1317 pertain to the implementation or use of the technology described in 1318 this document or the extent to which any license under such rights 1319 might or might not be available; nor does it represent that it has 1320 made any independent effort to identify any such rights. Information 1321 on the procedures with respect to rights in RFC documents can be 1322 found in BCP 78 and BCP 79. 1324 Copies of IPR disclosures made to the IETF Secretariat and any 1325 assurances of licenses to be made available, or the result of an 1326 attempt made to obtain a general license or permission for the use of 1327 such proprietary rights by implementers or users of this 1328 specification can be obtained from the IETF on-line IPR repository at 1329 http://www.ietf.org/ipr. 1331 The IETF invites any interested party to bring to its attention any 1332 copyrights, patents or patent applications, or other proprietary 1333 rights that may cover technology that may be required to implement 1334 this standard. Please address the information to the IETF at ietf- 1335 ipr@ietf.org. 1337 Disclaimer of Validity 1339 This document and the information contained herein are provided on an 1340 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1341 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1342 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1343 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1344 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1345 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1347 Copyright Statement 1349 Copyright (C) The Internet Society (2006). This document is subject 1350 to the rights, licenses and restrictions contained in BCP 78, and 1351 except as set forth therein, the authors retain all their rights. 1353 Acknowledgment 1355 Funding for the RFC Editor function is currently provided by the 1356 Internet Society.