Let's say you've got a LAN at home (crazy thought!). You're a single minded kind of person,so all your computers are running the same operating system family. Assuming you remember what you namedthem, you can open a terminal and run "ping BobPC" and get back some ping timings. All is well.
Now you have a friend over, who's running one of Those Other operating systems. "Very well," yousay, "something as basic as naming devices on a LAN must surely be solved in an interoperablemanner by now, it's 2015 after all." And you'd be wrong, of course, which you find out whenyou ask your friend what the name of the visiting computer is and try typing "ping AliceMac"without getting any replies back.
When you're looking for something, you're usually looking for either a specific object, orany object that will enable you to complete your current task. If you want to talk to Bob,you really need to find Bob. If you're in need of a printer, it's likely that just aboutany printer will do.
These two different types of search are called "name resolution" and "service discovery" in thecontext of computers and LANs. A name resolution will tell you the address of a specific device,and service discovery will give you a list of devices that provide a requested service.
A long time ago, there was a protocol called NetBIOS. A surprisingly long time ago, actually: it was created in the early 80s . This also explains someof the limitations that we've learned to live with, like the limited name length allowed and such.Microsoft first implemented the protocol in 1985, and we've had it all the way up to Windows 2000.NetBIOS was used not only for name resolution, but also for network printing and file sharing.
In other parts of the world, other protocols were used. Macs used AppleTalk, thatdid the same things. I don't know what the UNIX way of solving this problem in thegood ol'days was (if there even was a way?); when Linux computers started getting common they mostlydid what Microsoft did and implemented the NetBIOS protocol family - probably using Samba.
Then the future started happening. MacOS Classic was replaced with OSX, and AppleTalk was consideredold and in need of replacement. The printing functionality was replaced by CUPS, and servicediscovery and name resolution was replaced by Multicast DNS (mDNS). In the Linux world, avahi(which implements mDNS) started appearing alongside Samba.
On the Windows side, Microsoft decided that NetBIOS wouldn't do any longer, and replaced it with,among other protocols, LLMNR (Link-Local Multicast Name Resolution).
In short:
A slight aside
mDNS and LLMNR both do name resolution, but mDNS is also used for service discoverywhen paired with something called DNS-SD (DNS Service Discovery) .On the LLMNR side, service discovery is handled using a protocol called SSDP (Simple Service Discovery Protocol) which is based on HTTP-over-UDP. Yes, really.
Both LLMNR and mDNS are based on the same general principle: use a subset of DNS and send requestsover multicast. Multicast is a variant of broadcast where packets are delivered to anyone who hasnotified the switches (and possibly routers) on the network that they'd like to get them. Thismeans that when someone is trying to resolve a name, all interested devices on the network willsee the request.
In the case of mDNS, replies are also sent over multicast so that everyone can see them andkeep their local mDNS cache up to date. LLMNR replies are sent using unicast, so only the devicethat sent the request will see the reply. For both protocols, if no reply is received within a fewhundred milliseconds, the request is repeated a few times. Eventually the requester will give upand the resolution fails.
While LLMNR and mDNS are superficially very similar, when looking at the details it turns outthat there are some significant differences.The differences are big enough that the protocols aren't compatible, and also big enough thatone of the protocols is being turned into an Internet Standard while the other was turned downby the IETF.
Work on the LLMNR protocol went on in a IETF workgroup, and when they decided that they were moreor less done they sent out a "Last Call" to the rest of the IETF. The purpose of the lastcall to a "global" mailing list is to get some final feedback, by having IETF members who aren'tpart of the originating workgroup and haven't followed the work on the document read and opine.And this time, they did have opinions. Lots of them. And most of the feedback was of the type"ehm, this really isn't a good idea". I tried finding a link to the actual Last Call email, butthe closest I've managed to find is a reply by the author of mDNS .Do read a couple of emails in that thread, it's interesting!
Now, if I had spent a couple of years working on something and gotten the same reaction when Ipresented the result, I'm pretty sure that I'd be a bit defensive too. I haven't read all theemails in the list archive, there are a lot of them, but I did read quite a few in a "reality TVdrama" kind of fascination.
Some major objections brought up were (according to a summary email ):
In the end, the IETF decided that LLMNR wasn't going to achieve consensus and put it up as anInformational RFC. mDNS was worked on some more, and in 2013 it was promoted to Proposed Standard.Microsoft didn't care and continues to use LLMNR anyway [but see the update note at the end !].
I found the security objections to LLMNR interesting. In short, since theLLMNR namespace overlaps "normal" DNS namespace, it's possible for a device on the local networkto impersonate any domain normally located on the Internet. LLMNR lookups are done after tryingand failing with normal DNS, which means that a lookup of "mybank.com" will usually be locatedin DNS before reaching LLMNR. However, suppose that I'd like to trick you into connecting to mydevice instead of the bank's server. I would be able to do that by causing a DoS of normal DNSservices (by various means), and then responding with my device's address when your computer performsa lookup of "mybank.com" over LLMNR. This is especially easy in the case of "coffee shop" wirelessnetworks, where you connect to untrusted networks.
mDNS solves this problem by allocating a specific subset of the DNS namespace for use exclusivelywith mDNS: any lookup of a name ending in ".local" will use only mDNS, and all other queries willuse normal DNS.
LLMNR proponents claim that this can be solved by protecting the DNS records using DNSSEC, butit's unclear to me how the DNSSEC information can be a factor when the adversary has cut offaccess to the normal DNS server.
Now, we started out by having computers on our network that don't talk the same language when tryingto discover each other. We now know that there are two competing protocols in use, and thatWindows uses one of them while everyone else uses the other. How do we bridge this gap?
The obvious solution might be to look at how many computers you've got of each kind, and theninstall software that implements the missing protocol on the kind you've got least of. So ifyou've got ten Macs and a single Windows box, install mDNS on the Windows machine.
I don't know of any LLMNR implementations for OSX, but there is one for Linux .I haven't tried it, but I assume it works as advertised. If Windows is your minority, you caninstall Bonjour print services which includes mDNS.
Or you can do what I did, and get coding!
In case you're not interested in installing software on every machine that comes into your networkand doesn't run the dominant protocol, there's an alternate solution: install and run a proxysoftware on some machine that's on all the time (a server or such), that will listen forunanswered requests on each protocol and try to resolve them using the alternate protocol. Bydoing this you can make sure that all requests for "somebox.local" will be resolved, regardlessof which OS the computer is running. This is due to a small detail in the way Windows handleslookups of names ending in ".local"; if the lookup fails it will be tried again but with the".local" suffix removed.
This means that a Mac will query for "somebox.local" using mDNS, which can be proxied by a LLMNRquery for "somebox", and a Windows box will do a LLMNR query for "somebox" which can beproxied by a mDNS query for "somebox.local".
To try this hypothesis, I whipped up a simple Python script that listens for LLMNR queries,and if nobody has answered within 100ms or so does a mDNS lookup to try to find the answer.If something is found, a LLMNR reply is sent. So now the Windows machines on the LAN at work canfinally resolve the URLs to "intranet.local" I send in emails. No more having to remember that192.168.0.20 is the file server and 192.168.0.21 is the intranet server - it's almost like we'reliving in the future! I can also run services on DHCP-configured servers (don't ask...), andthings will continue working after reboots of the DHCP server.
Windows 10 will support mDNS and DNS-SD!
According to a comment on Hacker News Windows 10will support mDNS and DNS-SD. That sounds awesome, but finding details about this wasn'teasy. The best I could find from a few quick searches was a note in the hardware developersection of MSDN that says that Windows 10 will indeed locate printers using mDNS+DNS-SD .