Understanding GlobalNames Zone in Windows Server 2008

by Daniel Petri - January 7, 2009
Printer Friendly Version

Today, before the introduction of windows Server 2008, many Microsoft-based networks deploy WINS technology and servers in their environment. WINS is an alternative name resolution protocol to DNS. It is an older service that uses NetBIOS over TCP/IP (NetBT), mostly used in older operating systems such as Windows 95/98 and Windows NT 4.0. WINS and NetBT do not support IPv6 protocols and both are entering legacy mode for Windows Server 2008, and since Windows 2000 Server and beyond, most network services are no longer based upon NetBT name resolution, and use DNS names instead. That is why, in most cases, it is assumed that clients would want to retire their WINS infrastructure in favor of DNS name resolution.

To help customers migrate to DNS for all name resolution, the DNS Server role in Windows Server 2008 supports a special GlobalNames Zone (also known as GNZ) feature. Some customers in particular require the ability to have the static, global records with single-label names that WINS currently provides. These single-label names typically refer to records for important, well-known and widely-used servers for the company, servers that are already assigned static IP addresses and are currently managed by IT-administrators using WINS. GNZ is designed to enable the resolution of these single-label, static, global names for servers using DNS.

GNZ is intended to aid the retirement of WINS, and it's worth noting that it is not a replacement for WINS. GNZ is not intended to support the single-label name resolution of records that are dynamically registered in WINS, records which typically are not managed by IT administrators. Support for these dynamically registered records is not scalable, especially for larger customers with multiple domains and/or forests. In GNZ, after the creation and enabling of the GlobalNames zone, the administrators must manually create, add, edit and, if required – delete, name records from that zone. GNZ does not support dynamic updates.

For example:

DNS Client is able to resolve single-label names by appending an appropriate list of suffixes to the name, which are then answered by the authoritative DNS Servers. If the client issues the following command:

Ping Webserver

And the machines DNS suffix is, for example, adatum.com, then the client will append the DNS suffix to the host name and query the DNS for the Fully Qualified domain Name (FQDN) of Webserver.adatum.com.

Note: The correct DNS suffix depends on the domain membership of the client, but can also be manually configured in the advanced TCP/IP properties for the computer, or by using Group Policy (GPO). This is the correct order in which the Domain name suffix is applied:

For computers running Windows XP/Vista the following DNS suffixes order is used:

1. The primary DNS suffix, which is the domain that the client computer is joined to. Note: if Group Policy is being used, then this suffix not employed.  
2. The Group Policy configured DNS Suffix Search List. If GPO DNS Suffix Search List is used, further processing using DNS suffixes stops here.  
3. If there is no Group Policy:
   • The connection-specific DNS suffix for each adapter is used.  
   • For Vista only, for IPv6 adapters using DHCPv6 servers only, if there is a connection-specific suffix search list configured via DHCPv6 servers for an adapter, the suffixes in the list are appended in order.  
4. If the name cannot be resolved via DNS by using various suffixes, the query fails over to WINS.  
5. If no WINS is used, the client might turn over to broadcasting in the local subnet.

Note:

LLMNR – New Microsoft-based operating systems such as Windows Vista and Windows Server 2008 can use a new name resolution method called "Link-Local Multicast Name Resolution" (LLMNR), also known as multicast DNS or mDNS, to resolve names on a local network segment when a DNS server is not available. For example, if a router fails, cutting a subnet off from all DNS servers on the network, clients on the subnet that supports LLMNR can continue to resolve names on a peer-to-peer basis until the network connection is restored.

So, if, for example, the IT administrator has decided that he wanted to retire all WINS servers and stop using NetBIOS over TCP/IP (NeBT), and he also wants to continue to be able to ensure that the host names of important servers, such as Web servers, remain unique throughout their multiple domains and multiple forests – he should consider using GNZ in their environment.

By default, an authoritative DNS server will use local zone data first to respond to a query, before trying the GNZ to see if the name exists. If there is no relevant data in the GNZ and resolution using suffixes fails, resolution will fail over to WINS. In order to configure the DNS server to look locally at the GNZ records before failing over to WINS, you must use the following command:

1. Click Start, right-click Command Prompt, and then click Run as Administrator.  
2. Type the following command, then press Enter:

   Dnscmd ServerName /config /Enableglobalnamessupport 1

   Where ServerName is your server's name.

In order to learn how to configure the GlobalNames Zone in Windows Server 2008 please read my "Using GlobalNames Zone in Windows Server 2008" article.

Links

DNS Server GlobalNames Zone Deployment

Recent Windows Server 2008 Forum threads

Got a question? Post it on our Windows Server 2008 forums!