A common requirement in computer networks is the ability to resolve simple, single-label names. The use of single-label names makes it possible for a computer to access hosts such as file and Web servers by using short, easy-to-remember names instead of the fully qualified domain names (FQDNs) that form the default naming convention for Domain Name System (DNS). To make the use of single-label names possible, many networks deploy Windows Internet Name Service (WINS) technology and servers in their environment. As a name resolution protocol, WINS is an alternative to DNS. It is an older service that uses NetBIOS over TCP/IP (NetBT). WINS and NetBT do not support Internet Protocol version 6 (IPv6) protocols; therefore, they are being phased out in many networks.
To help network administrators migrate to DNS for all name resolution, the DNS Server role in Windows Server 2008 supports a specially named zone, called GlobalNames. By deploying a zone with this name, you can have the static, global records with single-label names, without relying on WINS. These single-label names typically refer to records for important, well-known and widely-used servers—servers that are already assigned static IP addresses and that are currently managed by IT-administrators using WINS.
The GlobalNames zone is not designed to be a complete replacement for WINS. You should not use the GlobalNames zone to support the 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 or multiple forests.
Deciding if you need to deploy a GlobalNames zone
Consider deploying a GlobalNames zone if:
- You are retiring WINS or you are planning to
deploy only IPv6 in your environment, so that all name resolution
will depend on DNS.
- Your need for single-label name resolution is
limited to important servers or Web sites that can be statically
registered in DNS. (Typically, these names are also configured
statically and globally in the WINS database.) Host names cannot be
registered in the GlobalNames zone by dynamic updates.
- You cannot rely on the suffix search lists on
client computers to provide single-label name resolution; for
example, because the number of target domains is too great or the
domains cannot be centrally managed to guarantee that host names
will be unique. For more information about using suffix search
lists, see Understanding DNS Client
Settings.
- All the DNS servers that are authoritative
for your zones are servers running Windows Server 2008. To
resolve names that are registered in the GlobalNames zone, all DNS
servers that are authoritative for a zone and that serve client
query requests must be running Windows Server 2008 and they
must either be configured with a local copy of the GlobalNames zone
or they must be able to contact remote DNS servers that host the
GlobalNames zone.
We also recommend that the GlobalNames zone be integrated with Active Directory Domain Services (AD DS). This integration with AD DS ensures easier management and future scalability.
Deploying a GlobalNames zone
The specific steps for deploying a GlobalNames zone can vary somewhat, depending on the AD DS topology of your network.
Step 1: Create the GlobalNames zone
The first step in deploying a GlobalNames zone is to create the zone on a DNS server that is a domain controller running Windows Server 2008. The GlobalNames zone is not a special zone type; rather, it is simply an AD DS-integrated forward lookup zone that is called GlobalNames. For information about creating a primary forward lookup zone, see Add a Forward Lookup Zone.
Step 2: Enable GlobalNames zone support
The GlobalNames zone is not available to provide name resolution until GlobalNames zone support is explicitly enabled by using the following command on every authoritative DNS server in the forest:
dnscmd <ServerName> /config /enableglobalnamessupport 1
where ServerName is the DNS name or IP address
of the DNS server that hosts the GlobalNames zone. To specify the
local computer, replace ServerName with a period (.), for
example, dnscmd . /config /enableglobalnamessupport
1.
Step 3: Replicate the GlobalNames zone
To make the GlobalNames zone available to all DNS servers and clients in a forest, replicate the zone to all domain controllers in the forest, that is, add the GlobalNames zone to the forest-wide DNS application partition. For more information, see Change the Zone Replication Scope.
If you want to limit the servers that will be authoritative for the GlobalNames zone, you can create a custom DNS application partition for replicating the GlobalNames zone. For more information, see Understanding DNS Zone Replication in Active Directory Domain Services.
Step 4: Populate the GlobalNames zone
For each server that you want to be able to provide single-label name resolution for, add an alias (CNAME) resource record to the GlobalNames zone. For more information, see Add an Alias (CNAME) Resource Record to a Zone.
Step 5: Publish the location of the GlobalNames zone in other forests
If you want DNS clients in other forests to use the GlobalNames zone for resolving names, add service location (SRV) resource records to the forest-wide DNS application partition, using the service name _globalnames._msdcs and specifying the FQDN of the DNS server that hosts the GlobalNames zone. For more information, see Add a Resource Record to a Zone and Service Location (SRV) Resource Record Dialog Box.
In addition, you must run the dnscmd ServerName /config /enableglobalnamessupport 1 command on every authoritative DNS server in the forests that do not host the GlobalNames zone.
Additional considerations
- By default, an authoritative DNS server uses
local zone data first to respond to a query, before trying the
GlobalNames zone to see if the name exists. If there is no relevant
data in the GlobalNames zone and resolution using suffixes fails,
resolution fails over to WINS. Querying local zone data first is a
performance optimization.
- Dynamic updates that are sent to an
authoritative DNS server are checked against GlobalNames zone data
first before being checked against local zone data. This ensures
that GlobalNames zone names remain unique.
- No software updates are required for clients
to enable them to resolve the names that are configured in the
GlobalNames zone. Primary DNS suffix, connection-specific suffixes,
and the DNS suffix search list continue to work as usual.
- DNS client registration is not affected
unless a computer tries to register a name that is already
configured in the GlobalNames zone.