An Overview of Link Local Multicast Name Resolution

When a user on a corporate network needs to access some resource off of another computer, the user usually specifies the remote system’s NetBIOS name when establishing the connection. This technique works well on corporate networks because the Active Directory mandates the existence of a DNS server. This means that users can attach to a remote system by using its NetBIOS name and Windows will query the DNS server in order to determine the IP addresses associated with the host record matching the computer’s name. That’s great for corporate networks, but name resolution has always been a problem for ad-hoc networks at home networks. In most cases, it is either impossible or impractical to add a DNS server to a home network or to an ad-hoc network. This makes name resolution impossible. Windows Vista in Longhorn Server will change this with the new technology called link local multicast name resolution. In this article, I will show you how it works.

What About WINS?

Before I get into a discussion of link local multicast name resolution, some of you are probably wondering why you couldn’t just use WINS for name resolution on an ad-hoc or a home network. Assuming that all of the computers on the network in question are running the IPv4 protocol, WINS will get the job done. The problem is that, with Windows Vista and Longhorn Server, Microsoft is making the transition to IPv6. This means that it is no longer safe to assume that all of the computers on a network are going to be running the IPv4 protocol.

Link Local Multicast Name Resolution is not a Substitute for DNS

Before I begin explaining how link local multicast name resolution works, I just want to clarify that link local multicast name resolution is not a substitute for DNS. While it’s true that both technologies are designed to provide name resolution services, link local multicast name resolution is much more limited in scope than DNS is.

To see where this is the case, think about how DNS works for a minute. When a machine needs to resolve another computer name, it sends a query to a DNS server. The DNS server attempts to match the query against the information stored within it. If the DNS server does not have a record matching the specified host, the request is forwarded to a higher level DNS server. Here the same thing happens. The DNS server checks to see if it has a record for the host, and if not it forwards the request to another DNS server. This could potentially keep happening until the request reaches the DNS server that is authoritative for the requested host’s domain.

As you can see, DNS is hierarchical in nature. Because of the number of hosts on the Internet, it is impossible for one DNS server to know everything. Therefore, DNS servers are arranged in a way that allows them to contain information regarding specific domains and forward all other requests to a higher level DNS server.

With this in mind, let’s turn our attention to link local multicast name resolution. The biggest limitation with link local multicast name resolution is that it is not routable. The name resolution process can only be used for computers that share a common subnet. Computers across a router are inaccessible to the name resolution process.

The reason why Microsoft chose to make link local multicast name resolution non-routable is because of the sheer number of hosts on the Internet. I already talked about there being so many hosts that no one DNS server could possibly handle them all. Link local multicast name resolution doesn’t even have a name resolution database to fall back on. Instead, computers on the subnet broadcast their host names. Can you imagine what would happen if these broadcasts could cross routers? There would be so much broadcast traffic that the name resolution process would have the same outcome as a denial of service attack.

This being the case, DNS is still the preferred name resolution method for Windows Vista and for Longhorn Server. Both of these operating systems are designed so that they will attempt to use DNS name resolution first. Link local multicast name resolution will only be used once the computer determines that it can not resolve the name using DNS.

How Link Local Multicast Name Resolution Works

Now that I’ve talked about what link local multicast name resolution is and is not capable of, I want to spend some time talking about how link local multicast name resolution works. Typically, the name resolution process begins when a computer needs to communicate with another host on the network. This computer needs to resolve the remote host’s name to an IP address. It therefore checks its TCP/IP configuration to get the IP address of a DNS server.

At this point, several different things could potentially happen. One possibility is that the computer contacts the DNS server and the DNS server resolves the name. Since my goal in writing this is to illustrate how link local multicast name resolution works, we will assume that DNS name resolution fails.

There are several reasons why this might happen. For example, imagine that you have a laptop that is configured to work on a corporate network. You take the laptop home one night to do some work. When you finish doing whatever it is that you needed to do, you decide to print your document. You’ve got a small wireless network set up in your home, so you attempt a connection to the PC that is hosting the network printer. Being that the laptop is configured to work on your corporate network, it probably has your company’s DNS server specified (assuming that the DNS server’s IP address is not being specified by a DHCP server). Right now you are attached to your home network and not to the corporate network, so your laptop cannot contact the specified DNS server. This would cause DNS name resolution to fail.

Now that DNS name resolution has failed, the computer will send a multicast name query out using the UDP protocol. All of the other devices on the network will receive the query. Assuming that these computers are running Windows Vista or Longhorn Server (meaning that they are link local multicast name resolution enabled), they will compare the query to their own host name. Assuming that the requested host is not prohibited from responding to link local multicast name resolution queries, the computer will send a unicast message to the computer that sent the query. This message will contain the host’s IP address.

Link local multicast name resolution also supports reverse mapping queries. This means that a host can send a query to a specific IP address and request that the host at that address responds with its computer name.

Why is Link Local Multicast Name Resolution Useful?

I’ve already given you one example of how link local multicast name resolution could be used when a laptop is attached to a wireless home network, but I wanted to give you a couple of other examples of how this technology is useful.

Perhaps the most obvious example is that several users from your company want to meet outside of the office to collaborate on a project. In doing so, they form an ad-hoc network that may or may not have Internet connectivity. Assuming that a DNS server is inaccessible, link local multicast name resolution steps in and provides name resolution services for hosts on the ad-hoc network.

A less obvious example of how link local multicast name resolution is useful is that it can be used during a router failure. For example, imagine that your company’s DNS server resides in the main office, and that DNS queries from branch offices flow across a WAN link. If the router were to fail, then DNS queries would be impossible until the router is fixed. However, users in the various branch offices could still resolve the names of network resources within their own office using link local multicast name resolution.

Conclusion

As you can see, Link Local Multicast Name Resolution is not a replacement for DNS based name resolution. It is however an alternative name resolution service that can be used when a DNS server is not available.

Post Views: 1,322

Featured Links

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Featured Product

Latest Podcast

Featured Freeware

Recommended

Follow Us

An Overview of Link Local Multicast Name Resolution

TECHGENIX

TechGenix reaches millions of IT Professionals every month, and has set the standard for providing free technical content through its growing family of websites, empowering them with the answers and tools that are needed to set up, configure, maintain and enhance their networks.