What's New in DNS and Name Resolution?

Considering the past two major Windows Server releases, we've come to expect changes to Windows name resolution and its primary naming protocol, DNS. Windows Server 2008 is no exception. In the interest of letting more people finally achieve a WINS-free environment, the latest name-resolution upgrades permit a local-only version of DNS, provide a DNS zone that somewhat replaces the need for WINS, and boast two improvements to the way Windows systems find domain controllers (DCs). But before we get into the particulars, you need to ask yourself ...

Do I Need WINS?
The first question in any discussion of Windows name resolution is, "Can I disable NetBIOS and WINS now?" The answer is pretty much the same as it has been for the past nine years: "It depends." Essentially, you're stuck with WINS if your OSs or your applications need NetBIOS. If your OSs are Windows XP or Windows Server 2003, you're mostly fine from the OS point of view (although ad hoc networks might still need NetBIOS, as you'll see). But many of our organizations' applications depend on NetBIOS/WINS.

Unlike many aspects of Windows networking, here's a case where many small to midsized businesses (SMBs) usually have an easier time cutting the WINS cord than large enterprises do. Many small shops have just one site, run only Windows Vista or XP on their desktops, run only Windows Server 2008 or Windows 2003 in the back office, and use little in the way of applications beyond Acrobat Reader, IE, and Office—a perfect environment in which to disable WINS and NetBIOS over TCP/IP. By contrast, virtually every large organization that I've encountered in my consulting experience depends on a collection of old, home-grown apps—apps that need WINS and will always need it, unless someone rewrites those apps (or unless an interesting new WINS-workaround called GlobalNames can do the job—more on that later).

So, can you pull the WINS plug? The only way to be 100 percent sure is to thoroughly test your apps in a Server 2008–based network. That's a lot of work for most people. One way to help determine whether you still need WINS comes from Microsoft coder Tim Rains, who suggested in a 2004 blog posting called "Why you still run Windows Internet Naming Service (WINS)" to run Performance Monitor on your WINS server (blogs.msdn.com/tim_rains/archive/2004/10/05/238236.aspx), logging the frequency of name-resolution requests to the WINS service. Perhaps the easiest answer, then, is to peek monthly at the Performance Monitor results, and when they start to dip, start looking more seriously into turning off WINS.

Replacing NetBIOS Broadcasts
A world without NetBIOS poses an important question: How can systems on the same subnet resolve names if they're not in DNS? Small ad hoc networks, test networks, and class lab networks sometimes either don't include a DNS server or can't include a DNS server—for example, most home networks don't include even a single copy of Windows Server, and Microsoft doesn't offer a DNS server for XP. Currently, any DNS-less network handles name resolution through NetBIOS broadcasts—bandwidth-wasting chatter that can chew up 10 to 20 percent of network capacity. Networks consisting of Server 2008 and Vista systems, however, can resolve names locally without broadcasts by using Link-Local Multicast Name Resolution (LLMNR), explained in RFC 4795 (tools.ietf.org/html/rfc4795).

LLMNR defines a multicast group at address 224.0.0.252 that LLMNR-capable systems (i.e., Vista and later—Microsoft hasn't offered a hotfix to add LLMNR to XP and 2003) can use to query names and get IP addresses in return. Thus, a query for the IP address of a system named PC33 doesn't hammer every IP-using box on the network but rather those systems that have joined the multicast group. As you'd guess, you don't need the Computer Browser service to make this sort of name resolution work.

LLMNR's benefits don't stop there. Unlike NetBIOS name-resolution broadcasts, LLMNR queries can return not just IPv4 addresses but also any IPv6 addresses that a given system owns. And if you think you'll have to learn some new obscure network protocol to troubleshoot an LLMNR problem, fear not: LLMNR queries are just familiar, standard DNS queries. And speaking of standards, if you work with Apple or Sun equipment, you might already be familiar with a similar protocol on those platforms to accomplish local name resolution without a DNS server: multicast DNS (mDNS). LLMNR works very much like mDNS (and in fact I can't quite figure out why Microsoft didn't just use seven-year-old mDNS in the first place).

Network Discovery Rising
We have tools such as DNS, LLMNR, and NetBIOS not just for simple name resolution. In many cases, we're resolving a server's name to determine what services that server offers: What are the names of its file and print shares, what web services reside on it, and so on. Thus, name resolution is closely associated with the larger (and more valuable) topic of resource discovery.

In the late 1980s, Microsoft gave users on LAN Manager networks the ability to obtain a list of servers on their network and to query those servers for a list of their shares. That was Microsoft Resource Discovery 1.0—so to speak—and it was terribly primitive. (It required you to guess which server had the share you wanted, then look at the server's resources to see if you guessed correctly.) Later, Windows 2000 introduced the idea of publishing print shares and file shares in Active Directory (AD), with full keyword tagging and search capabilities. Unfortunately, I know of few organizations that benefit from resource publishing; for most networks, resource discovery boils down to asking someone else on your team, "Where are those files we use for the project, again?"

With Server 2008 and Vista—and XP, to a certain extent—Microsoft is trying yet another approach to resource discovery with something called Network Discovery, which isn't a single protocol but rather a collection of protocols. Under Network Discovery, your system can use either the NetBIOS-based Computer Browser system or an LLMNR-based multicast system to enumerate other local systems. But to discover resources (e.g., who's sharing a color printer, who has the share related to the annual report), Server 2008, Vista, and XP—when equipped with SP3 and the hotfix from the Microsoft article "Network Map in Windows Vista does not display computers that are running Windows XP" (support.microsoft.com/kb/922120)—can exploit Web Services Discovery (WSD). Greatly simplified, WSD is the next generation of Simplified Services Discovery Protocol (SSDP) and Universal Plug and Play (UPnP), but with added security.

WSD is another peer-to-peer way for systems in a network to advertise their capabilities. The idea is that any system needing, for example, a shared printer can search for one by querying other systems on the network via a multicast message. Similarly, the system can send a directed message to another system, querying whether that system is sharing a printer. No, it's not a client/server approach such as AD publishing, but it's intended to be more standards-based than NetBIOS browsers because it's built atop the whole notion of web services, Simple Object Access Protocol (SOAP), and so on. You can recognize one kind of web services discovery traffic on your network when you see UDP messages sent to port 3702 on multicast address 239.255.255.250. Those messages—which are SOAP-formatted XML—are general queries seeking a gateway for connecting to the Internet. You'll also see TCP messages directed to particular servers on either port 5357 or port 5358 (one is HTTP, and the other is HTTPS, depending on how the client authenticates to the server); these messages are called directed discovery messages because the system isn't querying the multicast group but rather a particular server.

What sort of systems can participate in Network Discovery and WSD? Clearly Server 2008, Vista, and later versions of Windows systems can. To a limited extent, XP systems can participate—but only if you keep NetBIOS over TCP enabled on all systems, run SP3, and install the hotfix from the previously mentioned Microsoft article.

Client-Side DNS Changes
Some of Server 2008's most important DNS changes appear not in the DNS server software but in the DNS client software. In AD, member systems must first find a DC before they can log on to a domain. A member system uses DNS to do that, and once it finds a DC, it continues to use only that DC for future authentications until the member is rebooted (if it's a pre-Vista AD member). Typically, that's sound functionality, but in some situations a member's initially discovered DC is distant, and a sluggish WAN link between a member and its DC can slow authentication—a problem that continues until a reboot occurs or until someone notices and uses the Netdom Reset command to force the system to find a new (and presumably closer) DC.

With Server 2008, Vista, XP, and Windows 2003 (the latter two patched with the hotfix), the system no longer remains with a given DC until rebooted. Instead, it remembers its current "DC buddy" for 12 hours, then re-queries DNS when it needs a DC after that point. You can modify that behavior to make the time value larger or smaller: Navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters registry subkey, create a REG_DWORD entry called ForceRediscoveryInterval, and set the interval value in seconds. It's a good feature, but again, you'll need the aforementioned hotfix to add it to XP and Windows 2003.

That's not the only good news in terms of ensuring that your members find nearby DCs. Server 2008 and Vista provide another change to DNS client-side DC location behavior. When querying DNS to find the domain's DCs, AD clients from Win2K and later ask DNS for two lists of DCs. First, they ask DNS for the list of DCs in their site. If the member asks all local DCs to log it on but no DCs respond within 400 milliseconds, the member asks DNS for a second list—the list of all DCs in all sites—and the member then requests each of those DCs to log the member on. That's the reason you sometimes get logged on by a DC in Outer Mongolia when you're sitting in Austin, Texas.

With Server 2008 and Vista, you can optionally change how your AD members look for a DC. If they've queried all local DCs and gotten no answer, you can tell your members to next query DNS not for the worldwide list of DCs but instead the DCs from the next nearest site (as computed by site link costs). This behavior isn't the default; to enable it, navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters subkey, create a REG_DWORD value named TryNextClosestSite, set it to 1, and reboot. Or use the Group Policy setting at Computer ConfigurationAdministrative TemplatesSystemNetlogonDC Locator DNS RecordsTry Next Closest Site. Unfortunately, there's no retrofit available for XP or Windows 2003.

The GlobalNames Zone
Microsoft knows that many people are stuck with old, NetBIOS-centric applications that they can't replace any time soon, and that many of those folks want desperately to move away from NetBIOS as soon as possible. For those people, Server 2008's DNS offers an answer: the GlobalNames zone.

The idea is that many NetBIOS-fixated systems will work just fine without WINS, as long as you feed those applications short server names: Tell one of these apps to communicate with server44.bigfirm.com, and it complains; configure it instead for just server44, and all's well. Again, this isn't the answer for all old applications, but it works for a lot of them, and those are the applications that are the target of GlobalNames.

As you might know, the reason the hostname works in DNS-dumb apps is that your client OS is configured with a DNS suffix such as bigfirm.com. When the DNS-dumb app asks your client OS to resolve server44, your client's DNS server automatically attaches that DNS suffix to the hostname and asks its DNS server to resolve a Fully Qualified Domain Name (FQDN) such as server44.bigfirm.com. DNS can handle a name like that, so it returns an IP address and the old application is happy.

That's one reason why single-domain forests are more likely to be able to turn off WINS and not need GlobalNames—the DNS client's action was just the right thing. But what about an enterprise that has two or more domains? Suppose our client had a DNS suffix of mmco.com and the server44 system had a DNS suffix of bigfirm.com? In that case, there's no guarantee that server44 happens to be in the same domain as the client that's trying to access it, so the DNS name resolution would fail. Yes, you can deploy a series of DNS suffixes via Group Policy, but apparently a significant number of Microsoft's customers found that hard to manage, and that's where GlobalNames comes in.

Server 2008–based DNS servers can, if specially configured, contain a special zone called GlobalNames, a single-label name unlike more common two-label names such as bigfirm.com. When asked to resolve server44, our hypothetical client would add mmco.com and thus query DNS for server44.mmco.com—a query that would fail. A Server 2008 DNS server configured with a GlobalNames zone, however, wouldn't give up yet. It would take the hostname (server44) and look in the GlobalNames zone in search of an answer to this single-label query. The salient aspect of the GlobalNames zone is that it can include only CNAME (alias) records—records you've statically created. If any of those CNAME records match server44, the DNS server looks at the target of the CNAME record—for example, server44.bigfirm.com—and queries its A record. That query should succeed; we've already posited that a server44.bigfirm.com exists, so the Server 2008 DNS server would return that IP address to the client, and the old application would be happy.

Setting up GlobalNames is relatively easy, if stringent. First, all the DNS servers in your intranet need to be running Server 2008 because only a Server 2008 DNS server is smart enough to remove the old suffix and find the CNAME; if the client queries any other sort of DNS server, the game is over. Second, you'll probably find managing GlobalNames easiest if you make it an AD-integrated zone and put that zone in the ForestDNS partition. By default, Server 2008 DNS servers don't know how to use GlobalNames until you type the following command, which you'll need to do on each DNS server:

dnscmd /config /Enableglobalnamessupport 1

GlobalNames support in Server 2008 DNS has just one more (undocumented) quirk: It looks at the DNS suffix of the client requesting the name resolution and—if that DNS suffix doesn't match any zone that the DNS server is authoritative for—the DNS server, in my experience, doesn't ever look in GlobalNames.

Worth a Look
If you're already rolling out Vista and Server 2008, give its new name-resolution features a look. By doing so, you'll understand how they've changed what goes on under the hood of your networks. GlobalNames might just make your life easier in regards to legacy apps. And if you're still running XP or 2003, don't overlook their optional name-resolution upgrades, either—they don't want to miss out on the lower-bandwidth fun!