Host Name Resolution Process

Host Name Resolution Process

Host name resolution is the process of resolving a host name to an IP address before the source host sends the initial IP packet. Table 7-1 lists the standard methods of host name resolution for TCP/IP for Windows XP and Windows Server 2003.

Standard Methods of Host Name Resolution:

Resolution Method	Description
Local host name	The configured host name for the computer as displayed in the output of the Hostname tool. This name is compared to the destination host name.
Hosts file	A local text file in the same format as the 4.3 Berkeley Software Distribution (BSD) UNIX \etc\hosts file. This file maps host names to IP addresses. For TCP/IP for Windows XP and Windows Server 2003, the contents of the Hosts file are loaded into the DNS client resolver cache. For more information, see “The DNS Client Resolver Cache” in this chapter.
DNS server	A server that maintains a database of IP address-to-host name mappings and has the ability to query other DNS servers for mappings that it does not contain.

Windows-Specific Methods of Host Name Resolution:

Resolution Method	Description
DNS client resolver cache	A random access memory (RAM)-based table of the entries listed in the local Hosts file and the names that were attempted for resolution by using a DNS server.
NetBIOS name cache	A RAM-based table of recently resolved NetBIOS names and their associated IPv4 addresses.
NetBIOS name server (NBNS)	A server that resolves NetBIOS names to IPv4 addresses, as specified by Requests for Comments (RFCs) 1001 and 1002. The Microsoft implementation of an NBNS is a Windows Internet Name Service (WINS) server.
Local broadcast	Up to three NetBIOS Name Query Request messages are broadcast on the local subnet to resolve the IPv4 address of a specified NetBIOS name.
Lmhosts file	A local text file that maps NetBIOS names to IPv4 addresses for NetBIOS processes running on computers located on remote subnets.

Windows Methods of Resolving Host Names:

If NetBIOS over TCP/IP is enabled, Windows by default attempts to resolve host names using NetBIOS methods when standard methods fail. NetBIOS name resolution methods include the NetBIOS name cache, configured WINS servers, NetBIOS broadcasts, and the Lmhosts file

When an application uses Windows Sockets and either the application or a user specifies a host name, TCP/IP for Windows attempts to resolve the name in the following order when NetBIOS over TCP/IP is enabled:

1. Windows checks whether the host name is the same as the local host name.
   
2. If the host name and local host name are not the same, Windows searches the DNS client resolver cache.
   
3. If the host name cannot be resolved using the DNS client resolver cache, Windows sends DNS Name Query Request messages to its configured DNS servers.
   
4. If the host name is a single-label name (such as server1) and cannot be resolved using the configured DNS servers, Windows converts the host name to a NetBIOS name and checks its local NetBIOS name cache.
   

   Windows creates the 16-byte NetBIOS name by converting the host name, which must be less than 16 bytes long, to uppercase and padding it with space characters if needed to create the first 15 bytes of the NetBIOS name. Then, Windows adds 0x00 as the last byte. Every Windows-based computer running the Workstation service registers its computer name with a 0x00 as the last byte. Therefore, the NetBIOS form of the host name will typically resolve to the IPv4 address of the computer that has a NetBIOS computer name that matches the host name.
   

   If the host name is 16 characters or longer or an FQDN, Windows does not convert it to a NetBIOS name or try to resolve the host name using NetBIOS techniques.
   

5. If Windows cannot find the NetBIOS name in the NetBIOS name cache, Windows contacts its configured WINS servers.
   
6. If Windows cannot resolve the NetBIOS name by querying its configured WINS servers, Windows broadcasts as many as three NetBIOS Name Query Request messages on the directly attached subnet.
   
7. If there is no reply to the NetBIOS Name Query Request messages, Windows searches the local Lmhosts file.
   

The name resolution process stops when Windows finds the first IP address for the name. If Windows cannot resolve the host name using any of these methods, name resolution fails, and the only way to communicate with the destination host is to specify either its IP address or another name associated with the host that Windows can resolve to an IP address.

Introducing: GlobalNames Zone

Windows Server 2008 comes with IPv6 installed and enabled (if you haven’t already, check out my article on Windows Server 2008 IPv6 – The Future of Internet Protocol).

IPv6 makes no provision for WINS and Microsoft has wisely chosen not to shoehorn something in specifically for Microsoft networks.

IPv6 works with DNS, and DNS only. So, Microsoft came up with a rather ingenious solution to the problem of simple-name resolution, a special forward lookup zone.

The GlobalNames Zone (GNZ) is a regular issue, standards compliant forward lookup zone.

That means no interoperability issues for administrators. (And there was much rejoicing.) It does require a special name – GlobalNames – but otherwise, it is indistinguishable from other forward lookup zones.

It does take a specific configuration though. Specifically, it must be set to replicate to all DNS servers in the forest. It should not be set for dynamic updates, and GlobalNames Zone support has to be enabled on the DNS server.

How GlobalNames Zone Works

So how does this new bad boy work?

Basically, if a DNS server receives a request that it can’t resolve in its normal way by using local zones, it will then try and resolve the name with the GlobalNames Zone.

So, when that request comes in for AustinServer, the DNS servers will check its normal local zones (filled with FQDN) and come up empty. Then, it will check the GlobalNames Zone — where it will find AustinServer, and match it to its FQDN.

No extra configuration needed on the client to point to a WINS server, and no extra configuration on server to add a WINS role. You’ll be using DNS anyway, so everything that has to be there is already installed.

How to Setup GlobalNames Zone

Setting up GNZ is pretty straightforward as well. Just logon to your Domain Controller and fire up Server Manager.

Next, expand the DNS section under Roles until you come to Forward Lookup Zones. Inside Forward Lookup Zones, create a new zone.

The new zone should be a Primary Zone and needs to be set to Store the Zone in Active Directory. (Don’t forget this checkbox!)

Click Next to move on to the next page. Here, name the zone “GlobalNames” (this name is required).

Also, do not enable Allow Dynamic Updates. That is it for configuration only.

The one semi-bumpy spot is enabling GNZ support on the server. This requires issuing a command via the command-line. The command is:

dmscmd /config /EngalbeGlobalNamessupport 1

Where you are most likely to mess this up is the two “s”. It is Global Names Support not Global Name Support. Remember that and you’ll be fine.

This support has to be enabled on all the DNS servers in the forest. Don’t waste time typing it in all those times. Make a simple batch file and schedule it to replicate and run on all the servers.

In order to avoid any forgetfulness on new servers, make sure enabling GNZ support is included as standard operating procedure for all new DNS server installations.

All that is left is to build the forward lookup zone. Each entry will be a CNAME record with the corresponding Fully Qualified Domain Name.

Will You Ever Need WINS Again?

It is possible that some applications seem to require a WINS server. Unless the application interacts via specific WINS commands (not very common), it is usually possible to trick it by giving the program the address of a DNS server instead of a WINS server.

When your DNS server gets the name request, it will find the name and respond. Any application still being supported shouldn’t need this crutch for very long since most applications are being readied to work with IPv6 and there is no WINS in IPv6.

If you are tempted to configure both WINS and GNZ, don’t.

While it isn’t specifically forbidden, if you think your simple-name resolution is flakey now, wait until sometimes a WINS server responds and sometimes a GNZ server responds.

Not to mention you’ll have to add new entries to both places every time you add a resource to the network. The whole point of GNZ is to make things simpler not more complicated.