7 DNSEXT Working Group Bernard Aboba
8 INTERNET-DRAFT Dave Thaler
9 Category: Standards Track Levon Esibov
10 <draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation
13 Linklocal Multicast Name Resolution (LLMNR)
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 This Internet-Draft will expire on March 15, 2006.
42 Copyright (C) The Internet Society 2005.
46 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
47 name resolution in scenarios in which conventional DNS name
48 resolution is not possible. LLMNR supports all current and future
49 DNS formats, types and classes, while operating on a separate port
50 from DNS, and with a distinct resolver cache. Since LLMNR only
51 operates on the local link, it cannot be considered a substitute for
58 Aboba, Thaler & Esibov Standards Track [Page 1]
64 INTERNET-DRAFT LLMNR 29 August 2005
69 1. Introduction .......................................... 3
70 1.1 Requirements .................................... 4
71 1.2 Terminology ..................................... 4
72 2. Name Resolution Using LLMNR ........................... 4
73 2.1 LLMNR Packet Format ............................. 6
74 2.2 Sender Behavior ................................. 9
75 2.3 Responder Behavior .............................. 10
76 2.4 Unicast Queries and Responses ................... 12
77 2.5 Off-link Detection .............................. 13
78 2.6 Responder Responsibilities ...................... 13
79 2.7 Retransmission and Jitter ....................... 14
80 2.8 DNS TTL ......................................... 15
81 2.9 Use of the Authority and Additional Sections .... 15
82 3. Usage model ........................................... 16
83 3.1 LLMNR Configuration ............................. 17
84 4. Conflict Resolution ................................... 18
85 4.1 Uniqueness Verification ......................... 19
86 4.2 Conflict Detection and Defense .................. 20
87 4.3 Considerations for Multiple Interfaces .......... 21
88 4.4 API issues ...................................... 22
89 5. Security Considerations ............................... 22
90 5.1 Denial of Service ............................... 23
91 5.2 Spoofing ...............,........................ 23
92 5.3 Authentication .................................. 24
93 5.4 Cache and Port Separation ....................... 25
94 6. IANA considerations ................................... 25
95 7. Constants ............................................. 25
96 8. References ............................................ 25
97 8.1 Normative References ............................ 25
98 8.2 Informative References .......................... 26
99 Acknowledgments .............................................. 27
100 Authors' Addresses ........................................... 28
101 Intellectual Property Statement .............................. 28
102 Disclaimer of Validity ....................................... 29
103 Copyright Statement .......................................... 29
118 Aboba, Thaler & Esibov Standards Track [Page 2]
124 INTERNET-DRAFT LLMNR 29 August 2005
129 This document discusses Link Local Multicast Name Resolution (LLMNR),
130 which is based on the DNS packet format and supports all current and
131 future DNS formats, types and classes. LLMNR operates on a separate
132 port from the Domain Name System (DNS), with a distinct resolver
135 The goal of LLMNR is to enable name resolution in scenarios in which
136 conventional DNS name resolution is not possible. Usage scenarios
137 (discussed in more detail in Section 3.1) include situations in which
138 hosts are not configured with the address of a DNS server; where the
139 DNS server is unavailable or unreachable; where there is no DNS
140 server authoritative for the name of a host, or where the
141 authoritative DNS server does not have the desired RRs, as described
144 Since LLMNR only operates on the local link, it cannot be considered
145 a substitute for DNS. Link-scope multicast addresses are used to
146 prevent propagation of LLMNR traffic across routers, potentially
147 flooding the network. LLMNR queries can also be sent to a unicast
148 address, as described in Section 2.4.
150 Propagation of LLMNR packets on the local link is considered
151 sufficient to enable name resolution in small networks. In such
152 networks, if a network has a gateway, then typically the network is
153 able to provide DNS server configuration. Configuration issues are
154 discussed in Section 3.1.
156 In the future, it may be desirable to consider use of multicast name
157 resolution with multicast scopes beyond the link-scope. This could
158 occur if LLMNR deployment is successful, the need arises for
159 multicast name resolution beyond the link-scope, or multicast routing
160 becomes ubiquitous. For example, expanded support for multicast name
161 resolution might be required for mobile ad-hoc networks.
163 Once we have experience in LLMNR deployment in terms of
164 administrative issues, usability and impact on the network, it will
165 be possible to reevaluate which multicast scopes are appropriate for
166 use with multicast name resolution. IPv4 administratively scoped
167 multicast usage is specified in "Administratively Scoped IP
168 Multicast" [RFC2365].
170 Service discovery in general, as well as discovery of DNS servers
171 using LLMNR in particular, is outside of the scope of this document,
172 as is name resolution over non-multicast capable media.
178 Aboba, Thaler & Esibov Standards Track [Page 3]
184 INTERNET-DRAFT LLMNR 29 August 2005
189 In this document, several words are used to signify the requirements
190 of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
191 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
192 and "OPTIONAL" in this document are to be interpreted as described in
197 This document assumes familiarity with DNS terminology defined in
198 [RFC1035]. Other terminology used in this document includes:
201 Responses with RCODE set to zero are referred to in this document
202 as "positively resolved".
205 An address other than a Link-Local address. This includes globally
206 routable addresses, as well as private addresses.
209 An LLMNR responder considers one of its addresses reachable over a
210 link if it will respond to an ARP or Neighbor Discovery query for
211 that address received on that link.
214 A host that listens to LLMNR queries, and responds to those for
215 which it is authoritative.
218 A host that sends an LLMNR query.
221 There are some scenarios when multiple responders may respond to
222 the same query. There are other scenarios when only one responder
223 may respond to a query. Names for which only a single responder is
224 anticipated are referred to as UNIQUE. Name uniqueness is
225 configured on the responder, and therefore uniqueness verification
226 is the responder's responsibility.
228 2. Name Resolution Using LLMNR
230 LLMNR is a peer-to-peer name resolution protocol that is not intended
231 as a replacement for DNS. LLMNR queries are sent to and received on
232 port 5355. The IPv4 link-scope multicast address a given responder
233 listens to, and to which a sender sends queries, is 224.0.0.252. The
234 IPv6 link-scope multicast address a given responder listens to, and
238 Aboba, Thaler & Esibov Standards Track [Page 4]
244 INTERNET-DRAFT LLMNR 29 August 2005
247 to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
249 Typically a host is configured as both an LLMNR sender and a
250 responder. A host MAY be configured as a sender, but not a
251 responder. However, a host configured as a responder MUST act as a
252 sender, if only to verify the uniqueness of names as described in
253 Section 4. This document does not specify how names are chosen or
254 configured. This may occur via any mechanism, including DHCPv4
255 [RFC2131] or DHCPv6 [RFC3315].
257 LLMNR usage MAY be configured manually or automatically on a per
258 interface basis. By default, LLMNR responders SHOULD be enabled on
259 all interfaces, at all times. Enabling LLMNR for use in situations
260 where a DNS server has been configured will result in a change in
261 default behavior without a simultaneous update to configuration
262 information. Where this is considered undesirable, LLMNR SHOULD NOT
263 be enabled by default, so that hosts will neither listen on the link-
264 scope multicast address, nor will they send queries to that address.
266 By default, LLMNR queries MAY be sent only when one of the following
269 [1] No manual or automatic DNS configuration has been performed.
270 If DNS server address(es) have been configured, then LLMNR
271 SHOULD NOT be used as the primary name resolution mechanism,
272 although it MAY be used as a secondary name resolution
273 mechanism. A dual stack host SHOULD attempt to reach DNS
274 servers overall protocols on which DNS server address(es) are
275 configured, prior to sending LLMNR queries. For dual stack
276 hosts configured with DNS server address(es) for one protocol
277 but not another, this inplies that DNS queries SHOULD be sent
278 over the protocol configured with a DNS server, prior to
279 sending LLMNR queries.
281 [2] All attempts to resolve the name via DNS on all interfaces
282 have failed after exhausting the searchlist. This can occur
283 because DNS servers did not respond, or because they
284 responded to DNS queries with RCODE=3 (Authoritative Name
285 Error) or RCODE=0, and an empty answer section. Where a
286 single resolver call generates DNS queries for A and AAAA RRs,
287 an implementation MAY choose not to send LLMNR queries if any
288 of the DNS queries is successful. An LLMNR query SHOULD only
289 be sent for the originally requested name; a searchlist
290 is not used to form additional LLMNR queries.
292 While these conditions are necessary for sending an LLMNR query, they
293 are not sufficient. While an LLMNR sender MAY send a query for any
294 name, it also MAY impose additional conditions on sending LLMNR
298 Aboba, Thaler & Esibov Standards Track [Page 5]
304 INTERNET-DRAFT LLMNR 29 August 2005
307 queries. For example, a sender configured with a DNS server MAY send
308 LLMNR queries only for unqualified names and for fully qualified
309 domain names within configured zones.
311 A typical sequence of events for LLMNR usage is as follows:
313 [a] DNS servers are not configured or attempts to resolve the
314 name via DNS have failed, after exhausting the searchlist.
315 Also, the name to be queried satisfies the restrictions
316 imposed by the implementation.
318 [b] An LLMNR sender sends an LLMNR query to the link-scope
319 multicast address(es), unless a unicast query is indicated,
320 as specified in Section 2.4.
322 [c] A responder responds to this query only if it is authoritative
323 for the domain name in the query. A responder responds to a
324 multicast query by sending a unicast UDP response to the sender.
325 Unicast queries are responded to as indicated in Section 2.4.
327 [d] Upon reception of the response, the sender processes it.
329 The sections that follow provide further details on sender and
332 2.1. LLMNR Packet Format
334 LLMNR is based on the DNS packet format defined in [RFC1035] Section
335 4 for both queries and responses. LLMNR implementations SHOULD send
336 UDP queries and responses only as large as are known to be
337 permissible without causing fragmentation. When in doubt a maximum
338 packet size of 512 octets SHOULD be used. LLMNR implementations MUST
339 accept UDP queries and responses as large as the smaller of the link
340 MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
341 octets for the header, VLAN tag and CRC).
343 2.1.1. LLMNR Header Format
345 LLMNR queries and responses utilize the DNS header format defined in
346 [RFC1035] with exceptions noted below:
358 Aboba, Thaler & Esibov Standards Track [Page 6]
364 INTERNET-DRAFT LLMNR 29 August 2005
368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
369 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
371 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
372 |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
373 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
375 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
377 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
379 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
381 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
385 ID A 16 bit identifier assigned by the program that generates any kind
386 of query. This identifier is copied from the query to the response
387 and can be used by the sender to match responses to outstanding
388 queries. The ID field in a query SHOULD be set to a pseudo-random
389 value. For advice on generation of pseudo-random values, please
392 QR Query/Response. A one bit field, which if set indicates that the
393 message is an LLMNR response; if clear then the message is an LLMNR
397 A four bit field that specifies the kind of query in this message.
398 This value is set by the originator of a query and copied into the
399 response. This specification defines the behavior of standard
400 queries and responses (opcode value of zero). Future
401 specifications may define the use of other opcodes with LLMNR.
402 LLMNR senders and responders MUST support standard queries (opcode
403 value of zero). LLMNR queries with unsupported OPCODE values MUST
404 be silently discarded by responders.
406 C Conflict. When set within a request, the 'C'onflict bit indicates
407 that a sender has received multiple LLMNR responses to this query.
408 In an LLMNR response, if the name is considered UNIQUE, then the
409 'C' bit is clear, otherwise it is set. LLMNR senders do not
410 retransmit queries with the 'C' bit set. Responders MUST NOT
411 respond to LLMNR queries with the 'C' bit set, but may start the
412 uniqueness verification process, as described in Section 4.2.
418 Aboba, Thaler & Esibov Standards Track [Page 7]
424 INTERNET-DRAFT LLMNR 29 August 2005
427 TC TrunCation - specifies that this message was truncated due to
428 length greater than that permitted on the transmission channel.
429 The TC bit MUST NOT be set in an LLMNR query and if set is ignored
430 by an LLMNR responder. If the TC bit is set in an LLMNR response,
431 then the sender SHOULD discard the response and resend the LLMNR
432 query over TCP using the unicast address of the responder as the
433 destination address. See [RFC2181] and Section 2.4 of this
434 specification for further discussion of the TC bit.
436 T Tentative. The 'T'entative bit is set in a response if the
437 responder is authoritative for the name, but has not yet verified
438 the uniqueness of the name. A responder MUST ignore the 'T' bit in
439 a query, if set. A response with the 'T' bit set is silently
440 discarded by the sender, except if it is a uniqueness query, in
441 which case a conflict has been detected and a responder MUST
442 resolve the conflict as described in Section 4.1.
444 Z Reserved for future use. Implementations of this specification
445 MUST set these bits to zero in both queries and responses. If
446 these bits are set in a LLMNR query or response, implementations of
447 this specification MUST ignore them. Since reserved bits could
448 conceivably be used for different purposes than in DNS,
449 implementors are advised not to enable processing of these bits in
450 an LLMNR implementation starting from a DNS code base.
453 Response code -- this 4 bit field is set as part of LLMNR
454 responses. In an LLMNR query, the sender MUST set RCODE to zero;
455 the responder ignores the RCODE and assumes it to be zero. The
456 response to a multicast LLMNR query MUST have RCODE set to zero. A
457 sender MUST silently discard an LLMNR response with a non-zero
458 RCODE sent in response to a multicast query.
460 If an LLMNR responder is authoritative for the name in a multicast
461 query, but an error is encountered, the responder SHOULD send an
462 LLMNR response with an RCODE of zero, no RRs in the answer section,
463 and the TC bit set. This will cause the query to be resent using
464 TCP, and allow the inclusion of a non-zero RCODE in the response to
465 the TCP query. Responding with the TC bit set is preferable to not
466 sending a response, since it enables errors to be diagnosed.
467 Errors include those defined in [RFC2845], such as BADSIG(16),
468 BADKEY(17) and BADTIME(18).
470 Since LLMNR responders only respond to LLMNR queries for names for
471 which they are authoritative, LLMNR responders MUST NOT respond
472 with an RCODE of 3; instead, they should not respond at all.
474 LLMNR implementations MUST support EDNS0 [RFC2671] and extended
478 Aboba, Thaler & Esibov Standards Track [Page 8]
484 INTERNET-DRAFT LLMNR 29 August 2005
490 An unsigned 16 bit integer specifying the number of entries in the
491 question section. A sender MUST place only one question into the
492 question section of an LLMNR query. LLMNR responders MUST silently
493 discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
494 MUST silently discard LLMNR responses with QDCOUNT not equal to
498 An unsigned 16 bit integer specifying the number of resource
499 records in the answer section. LLMNR responders MUST silently
500 discard LLMNR queries with ANCOUNT not equal to zero.
503 An unsigned 16 bit integer specifying the number of name server
504 resource records in the authority records section. Authority
505 record section processing is described in Section 2.9. LLMNR
506 responders MUST silently discard LLMNR queries with NSCOUNT not
510 An unsigned 16 bit integer specifying the number of resource
511 records in the additional records section. Additional record
512 section processing is described in Section 2.9.
516 A sender MAY send an LLMNR query for any legal resource record type
517 (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
518 As described in Section 2.4, a sender MAY also send a unicast query.
520 The sender MUST anticipate receiving no replies to some LLMNR
521 queries, in the event that no responders are available within the
522 link-scope. If no response is received, a resolver treats it as a
523 response that the name does not exist (RCODE=3 is returned). A
524 sender can handle duplicate responses by discarding responses with a
525 source IP address and ID field that duplicate a response already
528 When multiple valid LLMNR responses are received with the 'C' bit
529 set, they SHOULD be concatenated and treated in the same manner that
530 multiple RRs received from the same DNS server would be. However,
531 responses with the 'C' bit set SHOULD NOT be concatenated with
532 responses with the 'C' bit clear; instead, only the responses with
533 the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
534 received along with error response(s), then the error responses are
538 Aboba, Thaler & Esibov Standards Track [Page 9]
544 INTERNET-DRAFT LLMNR 29 August 2005
549 If error responses are received from both DNS and LLMNR, then the
550 lowest RCODE value should be returned. For example, if either DNS or
551 LLMNR receives a response with RCODE=0, then this should returned to
554 Since the responder may order the RRs in the response so as to
555 indicate preference, the sender SHOULD preserve ordering in the
556 response to the querying application.
558 2.3. Responder Behavior
560 An LLMNR response MUST be sent to the sender via unicast.
562 Upon configuring an IP address, responders typically will synthesize
563 corresponding A, AAAA and PTR RRs so as to be able to respond to
564 LLMNR queries for these RRs. An SOA RR is synthesized only when a
565 responder has another RR in addition to the SOA RR; the SOA RR MUST
566 NOT be the only RR that a responder has. However, in general whether
567 RRs are manually or automatically created is an implementation
570 For example, a host configured to have computer name "host1" and to
571 be a member of the "example.com" domain, and with IPv4 address
572 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
573 authoritative for the following records:
575 host1. IN A 192.0.2.1
576 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
578 host1.example.com. IN A 192.0.2.1
579 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
581 1.2.0.192.in-addr.arpa. IN PTR host1.
582 IN PTR host1.example.com.
584 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.
585 ip6.arpa IN PTR host1. (line split for formatting reasons)
586 IN PTR host1.example.com.
588 An LLMNR responder might be further manually configured with the name
589 of a local mail server with an MX RR included in the "host1." and
590 "host1.example.com." records.
592 In responding to queries:
598 Aboba, Thaler & Esibov Standards Track [Page 10]
604 INTERNET-DRAFT LLMNR 29 August 2005
607 [a] Responders MUST listen on UDP port 5355 on the link-scope multicast
608 address(es) defined in Section 2, and on UDP and TCP port 5355 on
609 the unicast address(es) that could be set as the source address(es)
610 when the responder responds to the LLMNR query.
612 [b] Responders MUST direct responses to the port from which the query
613 was sent. When queries are received via TCP this is an inherent
614 part of the transport protocol. For queries received by UDP the
615 responder MUST take note of the source port and use that as the
616 destination port in the response. Responses MUST always be sent
617 from the port to which they were directed.
619 [c] Responders MUST respond to LLMNR queries for names and addresses
620 they are authoritative for. This applies to both forward and
621 reverse lookups, with the exception of queries with the 'C' bit
622 set, which do not elicit a response.
624 [d] Responders MUST NOT respond to LLMNR queries for names they are not
627 [e] Responders MUST NOT respond using data from the LLMNR or DNS
630 [f] If a DNS server is running on a host that supports LLMNR, the DNS
631 server MUST respond to LLMNR queries only for the RRSets relating
632 to the host on which the server is running, but MUST NOT respond
633 for other records for which the server is authoritative. DNS
634 servers also MUST NOT send LLMNR queries in order to resolve DNS
637 [g] If a responder is authoritative for a name, it MUST respond with
638 RCODE=0 and an empty answer section, if the type of query does not
639 match a RR that the responder has.
641 As an example, a host configured to respond to LLMNR queries for the
642 name "foo.example.com." is authoritative for the name
643 "foo.example.com.". On receiving an LLMNR query for an A RR with the
644 name "foo.example.com." the host authoritatively responds with A
645 RR(s) that contain IP address(es) in the RDATA of the resource
646 record. If the responder has a AAAA RR, but no A RR, and an A RR
647 query is received, the responder would respond with RCODE=0 and an
648 empty answer section.
650 In conventional DNS terminology a DNS server authoritative for a zone
651 is authoritative for all the domain names under the zone apex except
652 for the branches delegated into separate zones. Contrary to
653 conventional DNS terminology, an LLMNR responder is authoritative
654 only for the zone apex.
658 Aboba, Thaler & Esibov Standards Track [Page 11]
664 INTERNET-DRAFT LLMNR 29 August 2005
667 For example the host "foo.example.com." is not authoritative for the
668 name "child.foo.example.com." unless the host is configured with
669 multiple names, including "foo.example.com." and
670 "child.foo.example.com.". As a result, "foo.example.com." cannot
671 reply to an LLMNR query for "child.foo.example.com." with RCODE=3
672 (authoritative name error). The purpose of limiting the name
673 authority scope of a responder is to prevent complications that could
674 be caused by coexistence of two or more hosts with the names
675 representing child and parent (or grandparent) nodes in the DNS tree,
676 for example, "foo.example.com." and "child.foo.example.com.".
678 Without the restriction on authority an LLMNR query for an A resource
679 record for the name "child.foo.example.com." would result in two
680 authoritative responses: RCODE=3 (authoritative name error) received
681 from "foo.example.com.", and a requested A record - from
682 "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
683 hosts could perform a dynamic update of the parent (or grandparent)
684 zone with a delegation to a child zone; for example a host
685 "child.foo.example.com." could send a dynamic update for the NS and
686 glue A record to "foo.example.com.". However, this approach
687 significantly complicates implementation of LLMNR and would not be
688 acceptable for lightweight hosts.
690 2.4. Unicast Queries and Responses
692 Unicast queries SHOULD be sent when:
694 [a] A sender repeats a query after it received a response
695 with the TC bit set to the previous LLMNR multicast query, or
697 [b] The sender queries for a PTR RR of a fully formed IP address
698 within the "in-addr.arpa" or "ip6.arpa" zones.
700 Unicast LLMNR queries MUST be done using TCP and the responses MUST
701 be sent using the same TCP connection as the query. Senders MUST
702 support sending TCP queries, and responders MUST support listening
703 for TCP queries. If the sender of a TCP query receives a response to
704 that query not using TCP, the response MUST be silently discarded.
706 Unicast UDP queries MUST be silently discarded.
708 If TCP connection setup cannot be completed in order to send a
709 unicast TCP query, this is treated as a response that no records of
710 the specified type and class exist for the specified name (it is
711 treated the same as a response with RCODE=0 and an empty answer
718 Aboba, Thaler & Esibov Standards Track [Page 12]
724 INTERNET-DRAFT LLMNR 29 August 2005
727 2.5. "Off link" Detection
729 A sender MUST select a source address for LLMNR queries that is
730 assigned on the interface on which the query is sent. The
731 destination address of an LLMNR query MUST be a link-scope multicast
732 address or a unicast address.
734 A responder MUST select a source address for responses that is
735 assigned on the interface on which the query was received. The
736 destination address of an LLMNR response MUST be a unicast address.
738 On receiving an LLMNR query, the responder MUST check whether it was
739 sent to a LLMNR multicast addresses defined in Section 2. If it was
740 sent to another multicast address, then the query MUST be silently
743 Section 2.4 discusses use of TCP for LLMNR queries and responses. In
744 composing an LLMNR query using TCP, the sender MUST set the Hop Limit
745 field in the IPv6 header and the TTL field in the IPv4 header of the
746 response to one (1). The responder SHOULD set the TTL or Hop Limit
747 settings on the TCP listen socket to one (1) so that SYN-ACK packets
748 will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
749 prevents an incoming connection from off-link since the sender will
750 not receive a SYN-ACK from the responder.
752 For UDP queries and responses, the Hop Limit field in the IPv6 header
753 and the TTL field in the IPV4 header MAY be set to any value.
754 However, it is RECOMMENDED that the value 255 be used for
755 compatibility with Apple Bonjour [Bonjour].
759 In the sockets API for IPv4 [POSIX], the IP_TTL and
760 IP_MULTICAST_TTL socket options are used to set the TTL of
761 outgoing unicast and multicast packets. The IP_RECVTTL socket
762 option is available on some platforms to retrieve the IPv4 TTL of
763 received packets with recvmsg(). [RFC2292] specifies similar
764 options for setting and retrieving the IPv6 Hop Limit.
766 2.6. Responder Responsibilities
768 It is the responsibility of the responder to ensure that RRs returned
769 in LLMNR responses MUST only include values that are valid on the
770 local interface, such as IPv4 or IPv6 addresses valid on the local
771 link or names defended using the mechanism described in Section 4.
772 IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
773 addresses are defined in [RFC2373]. In particular:
778 Aboba, Thaler & Esibov Standards Track [Page 13]
784 INTERNET-DRAFT LLMNR 29 August 2005
787 [a] If a link-scope IPv6 address is returned in a AAAA RR,
788 that address MUST be valid on the local link over which
791 [b] If an IPv4 address is returned, it MUST be reachable
792 through the link over which LLMNR is used.
794 [c] If a name is returned (for example in a CNAME, MX
795 or SRV RR), the name MUST be resolvable on the local
796 link over which LLMNR is used.
798 Where multiple addresses represent valid responses to a query, the
799 order in which the addresses are returned is as follows:
801 [d] If the source address of the query is a link-scope address,
802 then the responder SHOULD include a link-scope address first
803 in the response, if available.
805 [e] If the source address of the query is a routable address,
806 then the responder MUST include a routable address first
807 in the response, if available.
809 2.7. Retransmission and Jitter
811 An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
812 when to retransmit an LLMNR query. An LLMNR sender SHOULD either
813 estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
814 high initial timeout. Suggested constants are described in Section
817 If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
818 then a sender SHOULD repeat the transmission of the query in order to
819 assure that it was received by a host capable of responding to it,
820 while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR
821 query SHOULD NOT be sent more than three times.
823 Where LLMNR queries are sent using TCP, retransmission is handled by
824 the transport layer. Queries with the 'C' bit set MUST be sent using
825 multicast UDP and MUST NOT be retransmitted.
827 An LLMNR sender cannot know in advance if a query sent using
828 multicast will receive no response, one response, or more than one
829 response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
830 has been received, or if it is necessary to collect all potential
831 responses, such as if a uniqueness verification query is being made.
832 Otherwise an LLMNR sender SHOULD consider a multicast query answered
833 after the first response is received, if that response has the 'C'
838 Aboba, Thaler & Esibov Standards Track [Page 14]
844 INTERNET-DRAFT LLMNR 29 August 2005
847 However, if the first response has the 'C' bit set, then the sender
848 SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
849 responses. When multiple valid answers are received, they may first
850 be concatenated, and then treated in the same manner that multiple
851 RRs received from the same DNS server would. A unicast query sender
852 considers the query answered after the first response is received, so
853 that it only waits for LLMNR_TIMEOUT if no response has been
856 Since it is possible for a response with the 'C' bit clear to be
857 followed by a response with the 'C' bit set, an LLMNR sender SHOULD
858 be prepared to process additional responses for the purposes of
859 conflict detection and LLMNR_TIMEOUT estimation, even after it has
860 considered a query answered.
862 In order to avoid synchronization, the transmission of each LLMNR
863 query and response SHOULD delayed by a time randomly selected from
864 the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
865 responders responding with names which they have previously
866 determined to be UNIQUE (see Section 4 for details).
870 The responder should insert a pre-configured TTL value in the records
871 returned in an LLMNR response. A default value of 30 seconds is
872 RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
873 networks), the TTL value may need to be reduced.
875 Due to the TTL minimalization necessary when caching an RRset, all
876 TTLs in an RRset MUST be set to the same value.
878 2.9. Use of the Authority and Additional Sections
880 Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
881 concept of delegation. In LLMNR, the NS resource record type may be
882 stored and queried for like any other type, but it has no special
883 delegation semantics as it does in the DNS. Responders MAY have NS
884 records associated with the names for which they are authoritative,
885 but they SHOULD NOT include these NS records in the authority
886 sections of responses.
888 Responders SHOULD insert an SOA record into the authority section of
889 a negative response, to facilitate negative caching as specified in
890 [RFC2308]. The TTL of this record is set from the minimum of the
891 MINIMUM field of the SOA record and the TTL of the SOA itself, and
892 indicates how long a resolver may cache the negative answer. The
893 owner name of the SOA record (MNAME) MUST be set to the query name.
894 The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
898 Aboba, Thaler & Esibov Standards Track [Page 15]
904 INTERNET-DRAFT LLMNR 29 August 2005
907 by senders. Negative responses without SOA records SHOULD NOT be
910 In LLMNR, the additional section is primarily intended for use by
911 EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
912 senders MAY only include pseudo RR-types in the additional section of
913 a query; unless the 'C' bit is set, responders MUST ignore the
914 additional section of queries containing other RR types.
916 In queries where the 'C' bit is set, the sender SHOULD include the
917 conflicting RRs in the additional section. Since conflict
918 notifications are advisory, responders SHOULD log information from
919 the additional section, but otherwise MUST ignore the additional
922 Senders MUST NOT cache RRs from the authority or additional section
923 of a response as answers, though they may be used for other purposes
924 such as negative caching.
928 Since LLMNR is a secondary name resolution mechanism, its usage is in
929 part determined by the behavior of DNS implementations. This
930 document does not specify any changes to DNS resolver behavior, such
931 as searchlist processing or retransmission/failover policy. However,
932 robust DNS resolver implementations are more likely to avoid
933 unnecessary LLMNR queries.
935 As noted in [DNSPerf], even when DNS servers are configured, a
936 significant fraction of DNS queries do not receive a response, or
937 result in negative responses due to missing inverse mappings or NS
938 records that point to nonexistent or inappropriate hosts. This has
939 the potential to result in a large number of unnecessary LLMNR
942 [RFC1536] describes common DNS implementation errors and fixes. If
943 the proposed fixes are implemented, unnecessary LLMNR queries will be
944 reduced substantially, and so implementation of [RFC1536] is
947 For example, [RFC1536] Section 1 describes issues with retransmission
948 and recommends implementation of a retransmission policy based on
949 round trip estimates, with exponential backoff. [RFC1536] Section 4
950 describes issues with failover, and recommends that resolvers try
951 another server when they don't receive a response to a query. These
952 policies are likely to avoid unnecessary LLMNR queries.
954 [RFC1536] Section 3 describes zero answer bugs, which if addressed
958 Aboba, Thaler & Esibov Standards Track [Page 16]
964 INTERNET-DRAFT LLMNR 29 August 2005
967 will also reduce unnecessary LLMNR queries.
969 [RFC1536] Section 6 describes name error bugs and recommended
970 searchlist processing that will reduce unnecessary RCODE=3
971 (authoritative name) errors, thereby also reducing unnecessary LLMNR
974 3.1. LLMNR Configuration
976 Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
977 possible for a dual stack host to be configured with the address of a
978 DNS server over IPv4, while remaining unconfigured with a DNS server
979 suitable for use over IPv6.
981 In these situations, a dual stack host will send AAAA queries to the
982 configured DNS server over IPv4. However, an IPv6-only host
983 unconfigured with a DNS server suitable for use over IPv6 will be
984 unable to resolve names using DNS. Automatic IPv6 DNS configuration
985 mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
986 deployed, and not all DNS servers support IPv6. Therefore lack of
987 IPv6 DNS configuration may be a common problem in the short term, and
988 LLMNR may prove useful in enabling link-local name resolution over
991 Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
992 IPv6-only hosts may not be configured with a DNS server. Where there
993 is no DNS server authoritative for the name of a host or the
994 authoritative DNS server does not support dynamic client update over
995 IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
996 be able to do DNS dynamic update, and other hosts will not be able to
999 For example, if the configured DNS server responds to a AAAA RR query
1000 sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
1001 RCODE=0 and an empty answer section, then a AAAA RR query sent using
1002 LLMNR over IPv6 may be successful in resolving the name of an
1003 IPv6-only host on the local link.
1005 Similarly, if a DHCPv4 server is available providing DNS server
1006 configuration, and DNS server(s) exist which are authoritative for
1007 the A RRs of local hosts and support either dynamic client update
1008 over IPv4 or DHCPv4-based dynamic update, then the names of local
1009 IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
1010 DNS server is authoritative for the names of local hosts, or the
1011 authoritative DNS server(s) do not support dynamic update, then LLMNR
1012 enables linklocal name resolution over IPv4.
1014 Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
1018 Aboba, Thaler & Esibov Standards Track [Page 17]
1024 INTERNET-DRAFT LLMNR 29 August 2005
1027 configure LLMNR on an interface. The LLMNR Enable Option, described
1028 in [LLMNREnable], can be used to explicitly enable or disable use of
1029 LLMNR on an interface. The LLMNR Enable Option does not determine
1030 whether or in which order DNS itself is used for name resolution.
1031 The order in which various name resolution mechanisms should be used
1032 can be specified using the Name Service Search Option (NSSO) for DHCP
1033 [RFC2937], using the LLMNR Enable Option code carried in the NSSO
1036 It is possible that DNS configuration mechanisms will go in and out
1037 of service. In these circumstances, it is possible for hosts within
1038 an administrative domain to be inconsistent in their DNS
1041 For example, where DHCP is used for configuring DNS servers, one or
1042 more DHCP servers can fail. As a result, hosts configured prior to
1043 the outage will be configured with a DNS server, while hosts
1044 configured after the outage will not. Alternatively, it is possible
1045 for the DNS configuration mechanism to continue functioning while
1046 configured DNS servers fail.
1048 An outage in the DNS configuration mechanism may result in hosts
1049 continuing to use LLMNR even once the outage is repaired. Since
1050 LLMNR only enables linklocal name resolution, this represents a
1051 degradation in capabilities. As a result, hosts without a configured
1052 DNS server may wish to periodically attempt to obtain DNS
1053 configuration if permitted by the configuration mechanism in use. In
1054 the absence of other guidance, a default retry interval of one (1)
1055 minute is RECOMMENDED.
1057 4. Conflict Resolution
1059 By default, a responder SHOULD be configured to behave as though its
1060 name is UNIQUE on each interface on which LLMNR is enabled. However,
1061 it is also possible to configure multiple responders to be
1062 authoritative for the same name. For example, multiple responders
1063 MAY respond to a query for an A or AAAA type record for a cluster
1064 name (assigned to multiple hosts in the cluster).
1066 To detect duplicate use of a name, an administrator can use a name
1067 resolution utility which employs LLMNR and lists both responses and
1068 responders. This would allow an administrator to diagnose behavior
1069 and potentially to intervene and reconfigure LLMNR responders who
1070 should not be configured to respond to the same name.
1078 Aboba, Thaler & Esibov Standards Track [Page 18]
1084 INTERNET-DRAFT LLMNR 29 August 2005
1087 4.1. Uniqueness Verification
1089 Prior to sending an LLMNR response with the 'T' bit clear, a
1090 responder configured with a UNIQUE name MUST verify that there is no
1091 other host within the scope of LLMNR query propagation that is
1092 authoritative for the same name on that interface.
1094 Once a responder has verified that its name is UNIQUE, if it receives
1095 an LLMNR query for that name, with the 'C' bit clear, it MUST
1096 respond, with the 'T' bit clear. Prior to verifying that its name is
1097 UNIQUE, a responder MUST set the 'T' bit in responses.
1099 Uniqueness verification is carried out when the host:
1101 - starts up or is rebooted
1102 - wakes from sleep (if the network interface was inactive
1104 - is configured to respond to LLMNR queries on an interface
1105 enabled for transmission and reception of IP traffic
1106 - is configured to respond to LLMNR queries using additional
1107 UNIQUE resource records
1108 - verifies the acquisition of a new IP address and configuration
1111 To verify uniqueness, a responder MUST send an LLMNR query with the
1112 'C' bit clear, over all protocols on which it responds to LLMNR
1113 queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
1114 uniqueness of a name by sending a query for the name with type='ANY'.
1116 If no response is received, the sender retransmits the query, as
1117 specified in Section 2.7. If a response is received, the sender MUST
1118 check if the source address matches the address of any of its
1119 interfaces; if so, then the response is not considered a conflict,
1120 since it originates from the sender. To avoid triggering conflict
1121 detection, a responder that detects that it is connected to the same
1122 link on multiple interfaces SHOULD set the 'C' bit in responses.
1124 If a response is received with the 'T' bit clear, the responder MUST
1125 NOT use the name in response to LLMNR queries received over any
1126 protocol (IPv4 or IPv6). If a response is received with the 'T' bit
1127 set, the responder MUST check if the source IP address in the
1128 response, interpreted as an unsigned integer, is less than the source
1129 IP address in the query. If so, the responder MUST NOT use the name
1130 in response to LLMNR queries received over any protocol (IPv4 or
1131 IPv6). For the purpose of uniqueness verification, the contents of
1132 the answer section in a response is irrelevant.
1134 Periodically carrying out uniqueness verification in an attempt to
1138 Aboba, Thaler & Esibov Standards Track [Page 19]
1144 INTERNET-DRAFT LLMNR 29 August 2005
1147 detect name conflicts is not necessary, wastes network bandwidth, and
1148 may actually be detrimental. For example, if network links are
1149 joined only briefly, and are separated again before any new
1150 communication is initiated, temporary conflicts are benign and no
1151 forced reconfiguration is required. LLMNR responders SHOULD NOT
1152 periodically attempt uniqueness verification.
1154 4.2. Conflict Detection and Defense
1156 Hosts on disjoint network links may configure the same name for use
1157 with LLMNR. If these separate network links are later joined or
1158 bridged together, then there may be multiple hosts which are now on
1159 the same link, trying to use the same name.
1161 In order to enable ongoing detection of name conflicts, when an LLMNR
1162 sender receives multiple LLMNR responses to a query, it MUST check if
1163 the 'C' bit is clear in any of the responses. If so, the sender
1164 SHOULD send another query for the same name, type and class, this
1165 time with the 'C' bit set, with the potentially conflicting resource
1166 records included in the additional section.
1168 Queries with the 'C' bit set are considered advisory and responders
1169 MUST verify the existence of a conflict before acting on it. A
1170 responder receiving a query with the 'C' bit set MUST NOT respond.
1172 If the query is for a UNIQUE name, then the responder MUST send its
1173 own query for the same name, type and class, with the 'C' bit clear.
1174 If a response is received, the sender MUST check if the source
1175 address matches the address of any of its interfaces; if so, then the
1176 response is not considered a conflict, since it originates from the
1177 sender. To avoid triggering conflict detection, a responder that
1178 detects that it is connected to the same link on multiple interfaces
1179 SHOULD set the 'C' bit in responses.
1181 An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
1182 log them. Upon detecting a conflict, an LLMNR responder MUST
1183 immediately stop using the conflicting name in response to LLMNR
1184 queries received over any supported protocol, if the source IP
1185 address in the response, interpreted as an unsigned integer, is less
1186 than the source IP address in the uniqueness verification query.
1188 After stopping the use of a name, the responder MAY elect to
1189 configure a new name. However, since name reconfiguration may be
1190 disruptive, this is not required, and a responder may have been
1191 configured to respond to multiple names so that alternative names may
1192 already be available. A host that has stopped the use of a name may
1193 attempt uniqueness verification again after the expiration of the TTL
1194 of the conflicting response.
1198 Aboba, Thaler & Esibov Standards Track [Page 20]
1204 INTERNET-DRAFT LLMNR 29 August 2005
1207 4.3. Considerations for Multiple Interfaces
1209 A multi-homed host may elect to configure LLMNR on only one of its
1210 active interfaces. In many situations this will be adequate.
1211 However, should a host need to configure LLMNR on more than one of
1212 its active interfaces, there are some additional precautions it MUST
1213 take. Implementers who are not planning to support LLMNR on multiple
1214 interfaces simultaneously may skip this section.
1216 Where a host is configured to issue LLMNR queries on more than one
1217 interface, each interface maintains its own independent LLMNR
1218 resolver cache, containing the responses to LLMNR queries.
1220 A multi-homed host checks the uniqueness of UNIQUE records as
1221 described in Section 4. The situation is illustrated in figure 1.
1223 ---------- ----------
1225 [A] [myhost] [myhost]
1227 Figure 1. Link-scope name conflict
1229 In this situation, the multi-homed myhost will probe for, and defend,
1230 its host name on both interfaces. A conflict will be detected on one
1231 interface, but not the other. The multi-homed myhost will not be
1232 able to respond with a host RR for "myhost" on the interface on the
1233 right (see Figure 1). The multi-homed host may, however, be
1234 configured to use the "myhost" name on the interface on the left.
1236 Since names are only unique per-link, hosts on different links could
1237 be using the same name. If an LLMNR client sends requests over
1238 multiple interfaces, and receives replies from more than one, the
1239 result returned to the client is defined by the implementation. The
1240 situation is illustrated in figure 2.
1242 ---------- ----------
1247 Figure 2. Off-segment name conflict
1249 If host myhost is configured to use LLMNR on both interfaces, it will
1250 send LLMNR queries on both interfaces. When host myhost sends a
1251 query for the host RR for name "A" it will receive a response from
1252 hosts on both interfaces.
1254 Host myhost cannot distinguish between the situation shown in Figure
1258 Aboba, Thaler & Esibov Standards Track [Page 21]
1264 INTERNET-DRAFT LLMNR 29 August 2005
1267 2, and that shown in Figure 3 where no conflict exists.
1275 Figure 3. Multiple paths to same host
1277 This illustrates that the proposed name conflict resolution mechanism
1278 does not support detection or resolution of conflicts between hosts
1279 on different links. This problem can also occur with DNS when a
1280 multi-homed host is connected to two different networks with
1281 separated name spaces. It is not the intent of this document to
1282 address the issue of uniqueness of names within DNS.
1286 [RFC2553] provides an API which can partially solve the name
1287 ambiguity problem for applications written to use this API, since the
1288 sockaddr_in6 structure exposes the scope within which each scoped
1289 address exists, and this structure can be used for both IPv4 (using
1290 v4-mapped IPv6 addresses) and IPv6 addresses.
1292 Following the example in Figure 2, an application on 'myhost' issues
1293 the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
1294 ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
1295 interfaces and the resolver library will return a list containing
1296 multiple addrinfo structures, each with an associated sockaddr_in6
1297 structure. This list will thus contain the IPv4 and IPv6 addresses
1298 of both hosts responding to the name 'A'. Link-local addresses will
1299 have a sin6_scope_id value that disambiguates which interface is used
1300 to reach the address. Of course, to the application, Figures 2 and 3
1301 are still indistinguishable, but this API allows the application to
1302 communicate successfully with any address in the list.
1304 5. Security Considerations
1306 LLMNR is a peer-to-peer name resolution protocol designed for use on
1307 the local link. While LLMNR limits the vulnerability of responders
1308 to off-link senders, it is possible for an off-link responder to
1311 In scenarios such as public "hotspots" attackers can be present on
1312 the same link. These threats are most serious in wireless networks
1313 such as 802.11, since attackers on a wired network will require
1314 physical access to the network, while wireless attackers may mount
1318 Aboba, Thaler & Esibov Standards Track [Page 22]
1324 INTERNET-DRAFT LLMNR 29 August 2005
1327 attacks from a distance. Link-layer security such as [IEEE-802.11i]
1328 can be of assistance against these threats if it is available.
1330 This section details security measures available to mitigate threats
1331 from on and off-link attackers.
1333 5.1. Denial of Service
1335 Attackers may take advantage of LLMNR conflict detection by
1336 allocating the same name, denying service to other LLMNR responders
1337 and possibly allowing an attacker to receive packets destined for
1338 other hosts. By logging conflicts, LLMNR responders can provide
1339 forensic evidence of these attacks.
1341 An attacker may spoof LLMNR queries from a victim's address in order
1342 to mount a denial of service attack. Responders setting the IPv6 Hop
1343 Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
1344 response may be able to reach the victim across the Internet.
1346 While LLMNR responders only respond to queries for which they are
1347 authoritative and LLMNR does not provide wildcard query support, an
1348 LLMNR response may be larger than the query, and an attacker can
1349 generate multiple responses to a query for a name used by multiple
1350 responders. A sender may protect itself against unsolicited
1351 responses by silently discarding them as rapidly as possible.
1355 LLMNR is designed to prevent reception of queries sent by an off-link
1356 attacker. LLMNR requires that responders receiving UDP queries check
1357 that they are sent to a link-scope multicast address. However, it is
1358 possible that some routers may not properly implement link-scope
1359 multicast, or that link-scope multicast addresses may leak into the
1360 multicast routing system. To prevent successful setup of TCP
1361 connections by an off-link sender, responders receiving a TCP SYN
1362 reply with a TCP SYN-ACK with TTL set to one (1).
1364 While it is difficult for an off-link attacker to send an LLMNR query
1365 to a responder, it is possible for an off-link attacker to spoof a
1366 response to a query (such as an A or AAAA query for a popular
1367 Internet host), and by using a TTL or Hop Limit field larger than one
1368 (1), for the forged response to reach the LLMNR sender. Since the
1369 forged response will only be accepted if it contains a matching ID
1370 field, choosing a pseudo-random ID field within queries provides some
1371 protection against off-link responders.
1373 Since LLMNR queries can be sent when DNS server(s) do not respond, an
1374 attacker can execute a denial of service attack on the DNS server(s)
1378 Aboba, Thaler & Esibov Standards Track [Page 23]
1384 INTERNET-DRAFT LLMNR 29 August 2005
1387 and then poison the LLMNR cache by responding to an LLMNR query with
1388 incorrect information. As noted in "Threat Analysis of the Domain
1389 Name System (DNS)" [RFC3833] these threats also exist with DNS, since
1390 DNS response spoofing tools are available that can allow an attacker
1391 to respond to a query more quickly than a distant DNS server.
1392 However, while switched networks or link layer security may make it
1393 difficult for an on-link attacker to snoop unicast DNS queries,
1394 multicast LLMNR queries are propagated to all hosts on the link,
1395 making it possible for an on-link attacker to spoof LLMNR responses
1396 without having to guess the value of the ID field in the query.
1398 Since LLMNR queries are sent and responded to on the local-link, an
1399 attacker will need to respond more quickly to provide its own
1400 response prior to arrival of the response from a legitimate
1401 responder. If an LLMNR query is sent for an off-link host, spoofing
1402 a response in a timely way is not difficult, since a legitimate
1403 response will never be received.
1405 Limiting the situations in which LLMNR queries are sent, as described
1406 in Section 2, is the best protection against these attacks. If LLMNR
1407 is given higher priority than DNS among the enabled name resolution
1408 mechanisms, a denial of service attack on the DNS server would not be
1409 necessary in order to poison the LLMNR cache, since LLMNR queries
1410 would be sent even when the DNS server is available. In addition,
1411 the LLMNR cache, once poisoned, would take precedence over the DNS
1412 cache, eliminating the benefits of cache separation. As a result,
1413 LLMNR is only used as a name resolution mechanism of last resort.
1417 LLMNR is a peer-to-peer name resolution protocol, and as a result,
1418 it is often deployed in situations where no trust model can be
1419 assumed. This makes it difficult to apply existing DNS security
1420 mechanisms to LLMNR.
1422 LLMNR does not support "delegated trust" (CD or AD bits). As a
1423 result, unless LLMNR senders are DNSSEC aware, it is not feasible to
1424 use DNSSEC [RFC4033] with LLMNR.
1426 If authentication is desired, and a pre-arranged security
1427 configuration is possible, then the following security mechanisms may
1430 [a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
1431 [RFC2931] security mechanisms. "DNS Name Service based on Secure
1432 Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
1433 the use of TSIG to secure LLMNR responses, based on group keys.
1438 Aboba, Thaler & Esibov Standards Track [Page 24]
1444 INTERNET-DRAFT LLMNR 29 August 2005
1447 [b] IPsec ESP with a null-transform MAY be used to authenticate unicast
1448 LLMNR queries and responses or LLMNR responses to multicast
1449 queries. In a small network without a certificate authority, this
1450 can be most easily accomplished through configuration of a group
1451 pre-shared key for trusted hosts.
1453 Where these mechanisms cannot be supported, responses to LLMNR
1454 queries may be unauthenticated.
1456 5.4. Cache and Port Separation
1458 In order to prevent responses to LLMNR queries from polluting the DNS
1459 cache, LLMNR implementations MUST use a distinct, isolated cache for
1460 LLMNR on each interface. The use of separate caches is most
1461 effective when LLMNR is used as a name resolution mechanism of last
1462 resort, since this minimizes the opportunities for poisoning the
1463 LLMNR cache, and decreases reliance on it.
1465 LLMNR operates on a separate port from DNS, reducing the likelihood
1466 that a DNS server will unintentionally respond to an LLMNR query.
1468 6. IANA Considerations
1470 This specification creates one new name space: the reserved bits in
1471 the LLMNR header. These are allocated by IETF Consensus, in
1472 accordance with BCP 26 [RFC2434].
1474 LLMNR requires allocation of port 5355 for both TCP and UDP.
1476 LLMNR requires allocation of link-scope multicast IPv4 address
1477 224.0.0.252, as well as link-scope multicast IPv6 address
1482 The following timing constants are used in this protocol; they are
1483 not intended to be user configurable.
1485 JITTER_INTERVAL 100 ms
1486 LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
1487 100 ms (IEEE 802 media, including IEEE 802.11)
1491 8.1. Normative References
1493 [RFC1035] Mockapetris, P., "Domain Names - Implementation and
1494 Specification", RFC 1035, November 1987.
1498 Aboba, Thaler & Esibov Standards Track [Page 25]
1504 INTERNET-DRAFT LLMNR 29 August 2005
1507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1508 Requirement Levels", BCP 14, RFC 2119, March 1997.
1510 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1511 Specification", RFC 2181, July 1997.
1513 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
1514 RFC 2308, March 1998.
1516 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
1517 Architecture", RFC 2373, July 1998.
1519 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
1520 Considerations Section in RFCs", BCP 26, RFC 2434, October
1523 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
1526 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
1527 "Secret Key Transaction Authentication for DNS (TSIG)", RFC
1530 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
1531 (SIG(0)s)", RFC 2931, September 2000.
1533 8.2. Informative References
1535 [Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
1536 (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
1539 [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
1540 Caching", IEEE/ACM Transactions on Networking, Volume 10,
1541 Number 5, pp. 589, October 2002.
1543 [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
1544 unicast addresses to communicate with recursive DNS servers",
1545 Internet draft (work in progress), draft-ietf-ipv6-dns-
1546 discovery-07.txt, October 2002.
1549 Institute of Electrical and Electronics Engineers, "Supplement
1550 to Standard for Telecommunications and Information Exchange
1551 Between Systems - LAN/MAN Specific Requirements - Part 11:
1552 Wireless LAN Medium Access Control (MAC) and Physical Layer
1553 (PHY) Specifications: Specification for Enhanced Security",
1554 IEEE 802.11i, July 2004.
1558 Aboba, Thaler & Esibov Standards Track [Page 26]
1564 INTERNET-DRAFT LLMNR 29 August 2005
1568 Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
1569 in progress), draft-guttman-mdns-enable-02.txt, April 2002.
1572 Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
1573 Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
1574 2004, Phoenix Park, Korea, February 9-11, 2004.
1576 [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
1577 Portable Operating System Interface (POSIX). Open Group
1578 Technical Standard: Base Specifications, Issue 6, December
1579 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
1581 [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
1582 Fixes", RFC 1536, October 1993.
1584 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
1585 Recommendations for Security", RFC 1750, December 1994.
1587 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
1590 [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
1591 RFC 2292, February 1998.
1593 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
1596 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
1597 Socket Interface Extensions for IPv6", RFC 2553, March 1999.
1599 [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
1600 2937, September 2000.
1602 [RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
1603 IPv6 (DHCPv6)", RFC 3315, July 2003.
1605 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
1606 System (DNS)", RFC 3833, August 2004.
1608 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
1609 of Link-Local IPv4 Addresses", RFC 3927, October 2004.
1611 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
1612 "DNS Security Introduction and Requirement", RFC 4033, March
1618 Aboba, Thaler & Esibov Standards Track [Page 27]
1624 INTERNET-DRAFT LLMNR 29 August 2005
1629 This work builds upon original work done on multicast DNS by Bill
1630 Manning and Bill Woodcock. Bill Manning's work was funded under
1631 DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
1632 their contribution to the current specification. Constructive input
1633 has also been received from Mark Andrews, Rob Austein, Randy Bush,
1634 Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
1635 Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
1636 Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
1637 Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
1638 St. Johns, Sander Van-Valkenburg, and Brian Zill.
1643 Microsoft Corporation
1647 Phone: +1 425 706 6605
1648 EMail: bernarda@microsoft.com
1651 Microsoft Corporation
1655 Phone: +1 425 703 8835
1656 EMail: dthaler@microsoft.com
1659 Microsoft Corporation
1663 EMail: levone@microsoft.com
1665 Intellectual Property Statement
1667 The IETF takes no position regarding the validity or scope of any
1668 Intellectual Property Rights or other rights that might be claimed to
1669 pertain to the implementation or use of the technology described in
1670 this document or the extent to which any license under such rights
1671 might or might not be available; nor does it represent that it has
1672 made any independent effort to identify any such rights. Information
1673 on the procedures with respect to rights in RFC documents can be
1674 found in BCP 78 and BCP 79.
1678 Aboba, Thaler & Esibov Standards Track [Page 28]
1684 INTERNET-DRAFT LLMNR 29 August 2005
1687 Copies of IPR disclosures made to the IETF Secretariat and any
1688 assurances of licenses to be made available, or the result of an
1689 attempt made to obtain a general license or permission for the use of
1690 such proprietary rights by implementers or users of this
1691 specification can be obtained from the IETF on-line IPR repository at
1692 http://www.ietf.org/ipr.
1694 The IETF invites any interested party to bring to its attention any
1695 copyrights, patents or patent applications, or other proprietary
1696 rights that may cover technology that may be required to implement
1697 this standard. Please address the information to the IETF at ietf-
1700 Disclaimer of Validity
1702 This document and the information contained herein are provided on an
1703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1705 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1706 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1707 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1712 Copyright (C) The Internet Society (2005). This document is subject
1713 to the rights, licenses and restrictions contained in BCP 78, and
1714 except as set forth therein, the authors retain all their rights.
1718 Funding for the RFC Editor function is currently provided by the
1723 Open issues with this specification are tracked on the following web
1726 http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
1738 Aboba, Thaler & Esibov Standards Track [Page 29]