This page contains answers to frequently asked questions about the Linklocal Multicast Name Resolution protocol (LLMNR).
What is the current status of LLMNR?
LLMNR is a standards track work item of the IETF DNSEXT WG. The draft has now completed IETF last call.
Has LLMNR been implemented?
Yes. Microsoft implemented LLMNR in WinCE 5.0 and an independent implementation (supporting TSIG security) also exists, documented in this paper:
DNS Name Service for IPv6 Mobile Adhoc Networks
Although LLMNR is not included in Windows Vista Beta 1, Microsoft is recommending that gateway vendors support LLMNR for compatibility with Windows Vista:
What are the key scenarios for LLMNR?
LLMNR is most useful in home or adhoc networking scenarios, such as:
A number of LLMNR enhancements have been proposed. These include:
Mechanisms for unique name generation
Support for TSIG Security
How many mDNS proposals are there?
There are three different "mDNS" proposals. They include:
mDNS by "The Bills" (the draft that started it all)
The "linklocal" mDNS proposal (adopted by DNSEXT WG, subsequently renamed to LLMNR)
Apple's mDNS proposal (used in Apple Bonjour)
What is the DNS Discover Opcode?
The DNS Discover Opcode is an experimental specification available here that can be used to discover DNS servers using a multicast or broadcast request. Unlike a conventional DNS query, The DNS Discover Opcode can also be used with multicast queries of greater than linklocal scope. LLMNR implementations typically will not include support for the DNS Discover Opcode. There are some that believe that the DNS Discover Opcode is not fully cooked. Note that the DISCOVER Opcode specification, if run on top of LLMNR would add "wildcard" query support -- resulting in additional potential security vulnerabilities.
How does LLMNR differ from IPv6 ICMP Node Information Query?
IPv6 ICMP Node Information query is a specification available here. The biggest difference between this and LLMNR is that Node Information Queries are only used with IPv6, whereas LLMNR can be used either with IPv4 or IPv6. Another difference is that LLMNR queries are only sent to a single multicast address, whereas IPv6 ICMP Node Information queries are sent to multiple multicast addresses, based on a hashing algorithm. This makes LLMNR somewhat simpler to implement (and more likely to interoperate).
Does LLMNR support wildcard queries?
In LLMNR there is no support for "wildcard" queries. This is intentional, in order to preclude a DoS attack where the attacker could send a "wildcard" query from the address of the intended victim, and deluge the victim with responses.
Why does LLMNR not use ".local"?
In situations where a DNS server is not available, such as in adhoc networks, it may be necessary for two machines from different companies to communicate. In these situations, an LLMNR sender may send a query for any name. This would not be possible if LLMNR only resolved names ending in the ".local" prefix. The only way that ".local" could handle this situation would be if it were appended to the searchlist, in which case any name would eventually be resolved with the ".local" suffix appended. Similarly, without placing ".local" in the searchlist a non-qualified name (e.g. "fred") also could not be resolved on the local link. Forcing users to append ".local" to names in order to enable link local name resolution is not helpful, and requires extra overhead and training for no useful benefit.
Are LLMNR queries always sent when DNS fails?
No. LLMNR is a name resolution protocol of last resort. LLMNR queries MAY only be sent if a DNS server is not configured, or if DNS queries are sent first, exhausting the search list. However, these conditions are NOTsufficient - an LLMNR implementation need not send LLMNR queries even if these conditions are satisfied. An implementation may further restrict the conditions under which LLMNR queries are sent. For example, when a DNS server is configured, an implementation may choose to only send LLMNR queries for unqualified names (e.g. "fred") or for names within configured zones (e.g. if the default domain is "example.com", only send queries for "foo.example.com" or "foo.bar.example.com" but not "foo.com").
Why do LLMNR responders place routable addresses first in responses?
Routable and link-scope IPv4 addresses cannot be used simultaneously on the same interface without potentially breaking applications. As a result LLMNR responders MUST include routable addresses first in the response, if available. This encourages use of routable address(es) for establishment of new connections. This does not cause communication problems with hosts that only have a Link-Local IPv4 address because these hosts should still be able to resolve routable addresses on the local link by using ARP or IPv6 Neighbor Discovery/Solicitation.
Why aren't UDP unicast queries allowed in LLMNR?
In LLMNR, UDP queries may be sent to the link-scope multicast address, or they may be sent using TCP with TTL=1. When receiving a UDP LLMNR query, the responder checks if it was sent to the link-scope multicast; if not, the query is silently discarded. This ensures that an LLMNR sender cannot receive an LLMNR query from a responder off the local link, preventing an off-link attacker from exploiting any LLMNR security vulnerabilities.
Why does LLMNR set TTL=1 for TCP queries and responses?
Within LLMNR, unicast queries MUST be sent using TCP. Setting TTL=1
within the TCP three way handshake ensures that a connection will only
be set up to a host on the same link. If TTL=255 were set on the TCP SYN, then
an LLMNR connection could be set up to any host on the Internet. This doesn't
make sense for linklocal name resolution.
Why does LLMNR recommend TTL=255 for UDP queries and responses?
LLMNR UDP queries are sent to a link-local multicast address. Properly functioning routers should not forward packets destined to a link-scope multicast address beyond the local scope. Therefore UDP queries sent to a link-scope multicast address can have the TTL set to any value without fear of leakage beyond the local link.
For UDP responses, the TTL may be set to any value. TTL=255 is recommended in UDP queries and responses, for compatibility with implementations that check TTL=255 on receipt.
Does LLMNR work with multiple prefixes on the same link?
Yes. LLMNR queries for any RR can be sent via multicast UDP. Therefore any host on the link will hear the query and respond. Assuming that TTL is set to 255 in the UDP response as recommended, the response will be received even if it goes through a router. Where PTR queries are sent via TCP with TTL=1, they may not reach their intended target if the router decrements TTL. However, a properly functioning router should send an ICMP redirect, so that when the sender retransmits the query it will be sent on the local link and will succeed. Also, in situations where a router is present, a DNS server is typically available, so that LLMNR queries will need to be sent at all. Since applications need to be prepared for PTR queries to fail, this should not be a problem.
Is LLMNR secure?
LLMNR is compatible with DNSSEC, TSIG or SIG(0) security mechanisms. However, unless an LLMNR sender is DNSSEC-aware, it is not possible for LLMNR to utilize DNSSEC, since LLMNR does not supported delegation of trust. While LLMNR implementations have demonstrated use of TSIG security on an adhoc network, this requires LLMNR senders and responders to be configured with a group key. Similarly, LLMNR responses can also be secured using IPsec with a group pre-shared key.
Will LLMNR break applications?
Not if used properly. The main way that a bad LLMNR implementation could break applications is by advertising a IPv4 Link-Local address inappropriately. Since LLMNR can only be used for name resolution on the local link, LLMNR responders can only respond to queries for names valid on the interface on which they are received, with information that is valid on the link on which the query is received. For example, if a host had two interfaces, one which had an IPv4 linklocal address, and another with a routable address, then it would be a bad idea to respond to an LLMNR query on the interface with the routable address with an A RR including the IPv4 linklocal address which was not valid on that interface. This would encourage the LLMNR sender to attempt to contact the host on an interface that was not reachable on the local link -- causing the application to break.
Is LLMNR scalable?
LLMNR is roughly as scalable as ARP; use of LLMNR on a single subnet with thousands of hosts is not recommended. LLMNR responses are only sent via unicast, so that senders need only listen for responses to their own queries. By default, a TTL of 30 seconds is recommended, so that caching is enabled. In more mobile environments, this value may need to be smaller (perhaps 0). LLMNR also supports negative caching of RCODE=0 responses with no data in the answer section, via use of the SOA RR.
Why does LLMNR utilize a separate port and multicast address from Bonjour?
While LLMNR and Bonjour are more similar than different, there are over half a dozen subtle differences between the protocols. For example:
Because of these differences, LLMNR and mDNS implementations do not interoperate. In order to prevent unpleasant interactions between the protocols they use different multicast addresses and ports.
Is Apple Bonjour on track to become an IETF standard?
Bonjour is an individual submission that is not a work item of any IETF working group, and is currently not an IETF standard. While it is possible for an individual submission to become an IETF standard, this is unlikely in this case because an existing WG (DNSEXT) is already working on a competing protocol (LLMNR), which has completed IETF last call. Comments by IETF veterans are available here:
Is use of the .local domain approved by the IETF?
No. Use of the .local domain has not been approved by the IETF for any purpose, nor has it been allocated by IANA. In addition to use by Apple Bonjour, the .local domain has been in use by the Microsoft Small Business Server (SBS) product since it was first released in 2000. Since Apple mDNS and DNS use different ports and name caches, there are no known bad interactions between the two uses.
The biggest difference between the original "Bills" proposal (which envisaged use of site local multicast) and the current LLMNR specification is that LLMNR is for use on the local link only and uses a different port from DNS, as well as a separate cache. This change was made primarily to address concerns about cache pollution as well as multicast storms resulting from site-wide mDNS usage.