Link-Local Multicast Name Resolution (LLMNR) is a Microsoft tech for service discovery based on multicast DNS. Is it compatible with Bonjour/Zeroconf? If so, where's the API? The service discovery, I take it, is somehow rolled into vanilla DNS resolution (gethostbyname()
?), but what about service advertisement?
LLMNR solves a small subset of the problems that mDNS tackles, as set out in this post. In short, it's not compatible with Bonjour.
Here is the content of that post, in case archive.org decides to drop the page:
From: Marc Krochmal Date: Fri, 16 Apr 2004 08:54:54 -0700 Hi Tom,
I was reading the August 2003 article in Linux Magazine (http://www.linux-mag.com/2003-08/zeroconf_01.html) on Zeroconf environments. Within the article they mention that Link Local Multicast Name Resolution was adopted by the IETF and that more or less mDNS was thrown out on its ear, even though it uses existing standards instead of creating an all new protocol. One of the reasons they mentioned or implied was that LLMNR was more advanced than mDNS was 'includes provisions to keep link-local addresses from accidentally being propagated into the greater DNS space' Based on research I have been doing into Rendezvous environments this is incorrect (is it not??) since mDNS is aware that domains ending with '.local' are available only on the local link and that a host will only ever try and resolve a domain name ending with '.local' on the local link. So have i misread this article or the mDNS white-paper or is there some truth in this??
LLMNR is much less advanced than mDNS. LLMNR solves a very small problem. It provides very basic name resolution when the name server is misconfigured or when it returns an error.
mDNS provides a distributed notification and cache coherency protocol that facilities ad-hoc DNS-Based Service Discovery. mDNS also provides reliable local name resolution when a hostname ends with ".local", regardless of the state of the DNS server. LLMNR is not a service discovery protocol. You could say that mDNS is a superset of LLMNR.
After a year and a half of operational experience with mDNS, we have never seen accidental leakage of link-local addresses outside the local-link.
There are many people in the IETF DNSEXT working group that would like to see LLMNR interoperate with mDNS. In fact, some people including Paul Vixie are saying that LLMNR should be thrown out and replaced with mDNS. You can read this for yourself in the namedroppers archives.
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/
Another thing alluded to by this article was that Microsoft is pushing for LLMNR and as far as I recall this is something provided by Service Pack 2 in Win XP.
I am not aware of LLMNR being included in Service Pack 2.
Is this not going to take us back to a NetBIOS v AppleTalk days where instead of working towards a singular standard we now have two for name resolution in Zeroconf environments???
This is difficult to predict. If Rendezvous continues to gain momentum, it could easily become the standard in Zeroconf environments. Pretty much every network enabled printer today ships with Rendezvous. Rendezvous also enables iTunes Music Sharing on Mac and Windows which could allow you to potentially share music with many other devices in the home with zero configuration.
Finally on a different track, the mDNS responder provided by Apple for OS X handles traditional DNS responses as well as well as link local mDNS. Is the mDNS responder for Windows and Linux boxes intended to replace the respective traditional DNS handlers provided by the Windows OS and Linux OS or does mDNS work in conjunction with their existing DNS handling (i.e. On a windows box with an mDNS Responder installed, if a DNS Query (for a global domain) needs to be sent, will the OS now use the mDNS responder to handle the process or will it use its 'out-of-the-box' DNS responder ???)
Even though mDNSResponder could be used to replace all DNS query handling, it probably won't. The name space provider for Windows which is included in the mDNSResonder project only works for names that end with ".local".
Best Regards,
-Marc
From Apple's open source implementation of mDNSResponder:
// Note: Microsoft's proposed "Link Local Multicast Name Resolution Protocol" (LLMNR) is essentially a limited version of
// Multicast DNS, using the same packet formats, naming syntax, and record types as Multicast DNS, but on a different UDP
// port and multicast address, which means it won't interoperate with the existing installed base of Multicast DNS responders.
// LLMNR uses IPv4 multicast address 224.0.0.252, IPv6 multicast address FF02::0001:0003, and UDP port 5355.
© 2022 - 2024 — McMap. All rights reserved.