LLMNR – Another Reason to Upgrade

The ultimate goal of any network administrator is system uptime and the consistent availability of network resources . This should be easy, but alas DNS and WINS can be fickle creatures.

In the Windows 2000/Windows XP days, losing a DNS server usually meant a total lack of connectivity for a network.  WINS, while not nearly as important as it once was, was also the source of a lot of grief when it wasn’t working properly.

Now, we have IPv6 entering the scene which has created its own set of problems. WINS doesn’t support it at all, and DNS is not so keen on mixing the two types of addresses (although it is possible). The need for a technology to fill the gap was evident. There had to be a better way of keeping machines talking to each other on subnets.

The answer was LLMNR or Local-Link Multicast Name Resolution.  The RFC for LLMNR (#4795) arose from a need for a way to get hosts communicating with each other on a small network with zero configuration.  As the name implies, it is only on the local link, so this is not a substitute for DNS, but rather a complementary system that will improve connectivity. The technology works with both IPv4 and IPv6 and is included and enabled by default on Windows Vista, Windows Server 2008/R2 and Windows 7.

This feature alone, is reason enough for me to recommend an upgrade to customers. I have set up several small networks now with Windows 7 boxes and they were able to communicate and share files within minutes of being attached to the network. Browsing by hostname was reliable and easy.  Anybody that has done the same thing on a small Windows XP network will be all too aware of how easily name resolution can be broken. The bottom line is that this technology will save companies money as it will surely reduce calls from end-users with connectivity issues.

So, how does all of this magic work? It is not all that difficult actually.

The standard is based on a standard DNS data packet, but it sends out a packet that can be up to 512 octets in size in multicast on port 5535. IPv4 hosts will listen for these broadcasts at 224.0.0.252 or in the case of of IPv6 at FF02:0:0:0:0:0:1:3 .  Hosts will then respond and this information will be cached for use by the operating system allowing for fast name resolution.

The LLMNR cache will only be queried for information if a DNS query fails, and as mentioned above it should not be considered the primary form of name resolution but rather a complementary one. If one were to set the LLMNR cache with a higher precedence than the DNS cache, it could be used (inappropriately) as the primary resolution mechanism.

LLMNR is currently unable to propagate across routers, but it is interesting that in the actual RFC for LLMNR, there is considerable discussion with regard to enabling this in a wider, perhaps Internet level, fashion.

In Server 2008 (and presumably Vista/Windows 7) LLMNR can be disabled. I am not quite sure why anyone would want or need to do this, but should you find reason here is a link that will show you how it is done.

Anyway, I realize that this post was a little deep on the technical side, but I just wanted to highlight and perhaps promote this technology so that more people will make the switch to our new beautiful suite of stable, reliable and secure operating systems.

Cheers!