Branch Office Infrastructure

Solutions
Name Resolution Services Guide

Version 3.0

Published: February 2008

Revised: September 2008
For the latest information, please see
microsoft.com/BranchOffice
Copyright © 2008 Microsoft Corporation. All rights reserved. Complying with the applicable copyright laws is
your responsibility. By using or providing feedback on this documentation, you agree to the license agreement
below.

If you are using this documentation solely for non-commercial purposes internally within YOUR company or
organization, then this documentation is licensed to you under the Creative Commons Attribution-
NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or
send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

This documentation is provided to you for informational purposes only, and is provided to you entirely "AS IS".
Your use of the documentation cannot be understood as substituting for customized service and information
that might be developed by Microsoft Corporation for a particular user based upon that user’s particular
environment. To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS
ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY
DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.

Microsoft may have patents, patent applications, trademarks, or other intellectual property rights covering
subject matter within this documentation. Except as provided in a separate agreement from Microsoft, your
use of this document does not give you any license to these patents, trademarks or other intellectual property.

Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-
mail addresses, logos, people, places and events depicted herein are fictitious.

Microsoft, Active Directory, Internet Security and Acceleration Server, Windows Server 2003, Windows Server
2008, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United
States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.

You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to
the documentation. However, if you do provide any Feedback to Microsoft then you provide to Microsoft,
without charge, the right to use, share and commercialize your Feedback in any way and for any purpose. You
also give to third parties, without charge, any patent rights needed for their products, technologies and services
to use or interface with any specific parts of a Microsoft software or service that includes the Feedback. You will
not give Feedback that is subject to a license that requires Microsoft to license its software or documentation to
third parties because we include your Feedback in them.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Contents

Solution Accelerators microsoft.com/technet/SolutionAccelerators

iv Guide Title (for single guide/doc accelerator or accelerator title (for multi-guide/doc accelerator)

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Name Resolution Services
For many years, designing IT infrastructures that are capable of supporting branch sites
has been a challenging task. The complexities introduced by the limitations in available
network bandwidth, performance issues, and geographic separation, have a significant
impact on an organization’s ability to implement an appropriate single IT solution for all of
its sites. As wide area network (WAN) bandwidth and performance grows, client and
server technologies are also introduced (or enhanced) so that they support branch
operations better. However, although the situation will improve, there will always be a
fundamental difference between the design for a geographically distributed IT
infrastructure and the design for a single site. The addition of branch sites introduces a
number of significant constraints that modify the options that are available to solution
designers.
This guide, as part of the Branch Office Infrastructure Solutions version 3 (BOISv3)
series, updates the design that was described in the Name Resolution and Network
Addressing section of Chapter 3 of the “Branch Office Infrastructure Solution for Microsoft
Windows Server 2003 Release 2” guide and specifically deals with the changes that are
introduced by the Microsoft Windows® Server® 2008 operating system. Although many
of the fundamental design principles in this guide remain the same, there are some
important implementation details that have changed, especially with the introduction of
Windows Server 2008 Server Core implementations and improved server virtualization
technologies like Hyper-V. This guide provides the necessary updates to ensure your
branch infrastructure designs take advantage of the latest network name resolution
services design approaches.

Goals and Objectives

This guide introduces a method of designing name resolution services for a service-
based branch infrastructure. The branch environment is typically part of a larger network
that supports the organization's main sites and data centers. However, the addition of
branch sites introduces a number of significant constraints, which modify the options that
are available to solution designers. This guide describes how to look at the specific
requirements of the branch site name resolution services in the larger context of the
organization's IT services.

Audience
The primary audience for this guide is the experienced Infrastructure Architect or IT
professional who is responsible for designing the name resolution services solutions for
branch site infrastructures. Name resolution services, like Domain Name System (DNS)
are a fundamental part of the Windows Server platform and, as such, name resolution
functionality can impact other services within the branch infrastructure. Therefore IT
professionals responsible for other services within the IT infrastructure will also benefit
from this guidance.

Domain Name System

DNS is the primary name resolution service for Windows-based computers. Active
Directory® Domain Services (AD DS) requires DNS to be available and appropriately
configured. If DNS is not available, names cannot be resolved to an IP address except in
the following situations:
• Windows Internet Name Service (WINS) is available for legacy services and
applications that use NetBIOS names.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

2 BOIS Name Resolution Services Guide

• Broadcasting is possible within a single local area network (LAN) segment.

The information in this section covers branch site–specific DNS design information. For
more information about DNS design, see the following documents:
• “How DNS Works” at http://go.microsoft.com/fwlink/?LinkId=46653
• “How DNS Support for Active Directory Works” at
http://go.microsoft.com/fwlink/?LinkId=46672
Figure 1 shows the DNS service design reference (SDR) for a branch site solution.

Figure 1. DNS SDR

DNS Namespace Design

The DNS namespace design is directly related to the Active Directory design in a
Windows environment. The main aim of this stage of the design is to ensure that the
traffic between the branch sites and the hub sites is optimized to maximize the
performance of the name resolution for the branch site-based hosts. Under typical
circumstances, the DNS namespace mirrors the Active Directory design. However, there
might be occasions when additional DNS domains are included in the DNS design.
Considerations for this stage of the design include:
• Active directory design. Active Directory cannot work without DNS, so a DNS
design must exist before Active Directory can be created. For more information about
the design of Active Directory in a branch environment, see the Directory Service
section of this guide.
• Business namespace requirements. If the organization has requirements for DNS
namespaces for business identity reasons, such as a brand or product name,
additional DNS-only domains can be created and managed as part of the DNS
environment.
In the BOIS design model, DNS namespaces were created for the directory server and
were inherited for the DNS namespace, as shown in Figure 2.

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Name Resolution Services Guide 3

Figure 2. BOIS DNS namespace model

The following list explains the role of each of these DNS domains:
• corp.woodgrovebank.com. This domain is the BOIS forest root domain.
• americas.corp.woodgrovebank.com. This domain is for the Americas datacenter.
• americas-branch.corp.woodgrovebank.com. This domain is the Americas branch
site domain.
• _msdcs.corp.woodgrove.com. This domain is automatically created by DNS to
replicate DNS data to all of the domain controllers in the forest.

DNS Server Placement

In a branch site, it is important for the DNS environment to be highly available. DNS
servers should be located so that clients can quickly and reliably access them. In
addition, you should consider the following issues:
• Server type. There are a number of options available for DNS server types that can
be broken down into two main groups: server-based and appliance-based. Although
an appliance-based DNS service provider can include single-purpose DNS devices,
they can also be part of a multi-function device such as a router or other network
attached device. Although easier to deploy initially, appliance-based DNS service
providers can be more difficult to manage and less flexible than server-based service
providers.
Sever-based DNS providers are more flexible because of the available options,
which include:
• A Server Core based installation that performs only a DNS services role
• A multi-purpose server that provides DNS services and other roles
• A domain controller that provides DNS services and directory services
Windows Server 2008 enables you to deploy Server Core instances, which are
dedicated role-based servers that contain only the binaries and applications that are
required to perform a specific role. The advantage of this approach is that it reduces
the vulnerability profile, administrative overhead, and the resources that are required
for the server operating system, which generally requires about 2 gigabytes of total
disk space for a Server Core implementation and service related data. Generally, this
type of deployment works especially well as part of a virtualized single server branch
infrastructure.
However, in branch environments it may be more appropriate to deploy DNS services
as a co-located service on a multi-functional server, especially if other related
services are also hosted on the same server (such as DHCP or WINS), in order to
reduce resource requirements and hardware maintenance costs.
• Domain controller placement. Usually, DNS should be located with each domain
controller. So, if the branch site has a domain controller, it should also run DNS, even
if it is a Read-Only Domain Controller (RODC). This approach includes the following
benefits:
• Stores DNS data in an application partition
Solution Accelerators microsoft.com/technet/SolutionAccelerators
4 BOIS Name Resolution Services Guide

• Provides integrated replication

• Provides secure dynamic updates
Co-location of DNS with other services is seldom a problem if the branch site does
not have a domain controller and DNS needs to be locally available, even if the WAN
link is not available. There are three options for this:
• Use a DNS server in caching mode. In this mode, DNS caches queries, which
speeds up subsequent queries and provides name resolution for entries that
were previously cached, unless they have expired (even if the central DNS
service is unavailable).
• Use a DNS server as secondary. In this mode, DNS hosts a complete read only
copy of the specified DNS zones. By default in
Microsoft Windows Server™ 2003, only changes are transferred. Setting up a
DNS server as a secondary server is a little more complicated than using a DNS
server in caching mode because zone transfers must be defined.
• For RODCs, use primary read-only zone types. In this mode, the RODC
replicates a full read-only copy of all of the application directory partitions that
DNS uses, including the domain partition, ForestDNSZones, and
DomainDNSZones. This ensures that the DNS Server service that is running on
the RODC has a full read-only copy of any DNS zones that are stored in the
directory partitions of a domain controller that is not an RODC. You can view the
contents of a primary read-only zone on an RODC, but you cannot change them.
You should not use local client caching as a fallback option because DNS lookups
are local to each client. This severely restricts name resolution, because only IP
addresses that were accessed very recently by the client can be resolved.
• Network topology. The existing network infrastructure must be considered to ensure
that the routers and firewalls that are in place can enable the intended design to
function as planned. For example, the DNS lookup requests will need access to the
designated DNS servers, even if the access is across the WAN.
• Network availability. If the WAN link is likely to be down for long periods of time, the
design may need to include a local DNS service, or a local broadcast-based name
resolution service may be required as a backup.
• Service availability. Providing a backup to a DNS service is a simple matter of
ensuring that both the primary and secondary DNS server properties are populated
for the branch site servers and clients. The primary server could be a local server
with a backup at the hub site (for a decentralized design), or two DNS servers at the
hub site (for a centralized design).
• WAN link speeds. Poor bandwidth to a DNS server can affect the performance of
access to even local resources, because the initial lookup may need to travel to the
hub site and back again before a local connection is made.

DNS Configuration Design

The final stage of the DNS design involves tuning the configuration of the various DNS
settings to optimize the operation of the service in a branch site environment. You should
consider the following configuration options during this stage of the design:
• DNS client configuration. This configuration controls the DNS servers that the DNS
clients in the branch site contact.
• DNS zone configuration. These settings control how DNS information is registered
and queried in a branch site environment.
• DNS record registration configuration. These records control how DNS clients
search for nearby domain controllers.
• Automated site coverage. This record ensures that a domain controller is located
by a client computer in the site that is closest to it, if not in the same site. Windows
Server 2008 automatically attempts to register a domain controller in every site by

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Name Resolution Services Guide 5

using an automated site coverage algorithm. The algorithm determines how one site
can provide cover for a second site when no domain controller exists in the second
site.
• Group Policy configuration. Group Policy can be used to control DNS-specific
settings on domain controllers in the design.
• GlobalNames Zone. The GlobalNames zone provides single-label name resolution
for networks that do not deploy WINS. The GlobalNames zone is useful when you
cannot use DNS name suffixes to provide single-label name resolution.
For more information about the settings for these options, see "Chapter 4 - Planning a
DNS Structure for the Branch Office Environment" of the “Windows Server 2003 Active
Directory Branch Office Guide”, at http://go.microsoft.com/fwlink/?LinkId=46583.

Windows Internet Name Service

WINS is a legacy name-resolution protocol, so the requirement for WINS at branch
locations should eventually cease to exist. If WINS still exists in your organization, you
should already know what services or applications depend on it and either have a plan, or
develop a plan, for removing those dependencies. You might be able to remove WINS as
part of the streamlining process for branch sites, either now or in the near future,
especially if any services or applications in branch locations are to be redesigned. If a
branch site still depends on WINS, the primary design option to consider is where it
should be located. Figure 3 illustrates this design consideration.

Figure 3. WINS design reference

The approach used for WINS in previous models was to centralize the WINS server in a
centralized site and to co-locate the service on the same server as the DHCP service.
Because there have not been any significant changes to WINS with Windows Server
2008, apart from some security enhancements, the following section outlines the
Windows Server 2003 issues that you should still consider when you determine whether
this design will meet the needs of your organization.

WINS Server Placement

When you consider whether a server that is hosting the WINS service is required at the
branch site, you should take the following design considerations into account:
• Administrative overhead. Each WINS server generates more administrative
workload. Configuring, monitoring, updating, and backing up the WINS database
adds costs to the management of the infrastructure.
• Network topology. The existing network infrastructure needs to be considered to
ensure that the routers and firewalls in place can enable the intended design to

Solution Accelerators microsoft.com/technet/SolutionAccelerators

6 BOIS Name Resolution Services Guide

function as planned. For example, replication data from the WINS databases will
need to be passed between the various WINS servers in the environment.
• Network availability. If the WAN becomes unavailable with a centralized WINS
design, resolution of NetBIOS names is dependent on either local broadcast, which
works only within the local TCP/IP network and not across IP routers, or local client
caching of WINS data.
• Service availability. If WINS is provided locally and the local service becomes
unavailable, resolution of NetBIOS names is dependent on the configuration of a
secondary WINS server. This would typically be configured as a WINS server in the
hub site.
• WAN link speeds. The available bandwidths and latency of the WAN links of the
network are a significant consideration for the DHCP server. High latency links may
not be able to support the passing of DHCP requests from the branch clients to a
centralized server.
• Hardware costs. If the branch sites require a local WINS service, this service can
probably be co-located on a general purpose branch server. For more information
about hardware costs, see the following Service Co-location Notes section in this
guide. If co-location is not possible due to an incompatibility or performance issue,
the service must be configured on new hardware. You should pay particular attention
to the disk performance of any server hardware that hosts co-located services.
• Database convergence time. The time that is needed to replicate a new entry in a
WINS database, from the WINS server that owns the entry to all of the other WINS
servers on the network, is defined as convergence time. You must decide what
convergence time is acceptable for your network; the longer the replication path and
the lower the replication frequency of WINS databases, the longer this convergence
time becomes. The WINS servers must be replicated frequently enough to prevent
the downtime of a single WINS server from affecting the reliability of the mapping
information in other WINS servers. However, the time interval between replications
cannot be so small that it interferes with network throughput. The available network
bandwidth influences replication frequency.
For more information about planning and operating guidance for WINS, see the
Managing Core Network Services section of Windows Server 2008 Help.

Service Co-Location Notes

Like DNS, WINS can generally coexist with other services on a shared instance of the
operating system. Therefore, WINS is a good candidate for co-location on a single
instance of the operating system. As with any other service, you should use the least
privileges possible. The WINS administrator must be a member of the Administrators
group on the local computer.
The following list outlines the options for supplying WINS with or without other services (if
it cannot be centralized):
• Server Core-based WINS. Windows Server 2008 supports a WINS Server Core
implementation if a server instance would only supply WINS services. Although this
approach requires fewer resources than a standard server deployment and has a
reduced vulnerability profile, it can be difficult to justify deploying a server solely for
WINS, unless it is a virtual server instance.
• Co-locate WINS with Active Directory and DNS. This is useful for organizations in
which WINS is operated by the same group that operates Active Directory and DNS.
This is logical because DNS and WINS are both name resolution services. However,
WINS puts an additional load on the computer if a large number of changes occur.
• Co-locate WINS with file and print services. This can be a good choice for
organizations that want to separate WINS from Active Directory and DNS. This is
only feasible if service administration can be coordinated (when separation of
administration is not required).

Solution Accelerators microsoft.com/technet/SolutionAccelerators

BOIS Name Resolution Services Guide 7

• Co-locate WINS on a networking server. This can be a good solution for branch
sites that have a Windows-based networking server. WINS can be co-located with
Microsoft Internet Security and Acceleration Server or run on a virtual machine on the
networking server (although, additional software licensing and management costs
related to virtual machines can sometimes be difficult to justify).
For more information about WINS planning and deployment, see the "Deploying Network
Services" chapter of the “Windows Server 2003 Deployment Guide” at
http://go.microsoft.com/fwlink/?LinkId=46613

Summary
DNS services are part of the core services that technology workers depend on to access
resources and other services, and other service architectures can be directly affected by
the infrastructure design of a DNS. Because DNS is such an important part of an
organization’s IT infrastructure it is important to understand how best to deliver DNS
services to branch sites and how branch infrastructures can influence the overall DNS
design of an organization’s infrastructure.
By examining branch site needs and the overall business structure, it is possible to
design an agile and resilient name resolution service infrastructure that can be easily
expanded to accommodate growth while remaining flexible enough to accept new
technologies as business needs change, and that also minimizes impact on other design
elements and infrastructure components.

Additional Resources
The following links can be used to discover more information about using name
resolution services like DNS and WINS in a Windows Server 2008 environment:
For more information about Windows Server 2008 branch site design, see the Windows
Server 2008 in Branch Offices Guide at
http://www.microsoft.com/windowsserver2008/branch-office.mspx
For more information about Windows Server 2008, see the Windows Server 2008
Learning Portal at http://go.microsoft.com/?linkid=8167044
For more information about DNS server roles in Windows Server 2008, see the TechNet
DNS Server Role in Windows Server 2008 TechCenter at
http://technet2.microsoft.com/windowsserver2008/en/library/533a1cfc-5173-4248-914c-
433bd018f66d1033.mspx?mfr=true
For more information about the new DNS features in Windows Server 2008, see to the
TechNet Magazine: DNS Enhancements in Windows Server 2008 article at
http://www.microsoft.com/technet/technetmag/issues/2008/01/CableGuy/?topics=/technet
/technetmag/issues/2008/01/CableGuy
For more information about server core installations, see the Server Core Installation
Option for Windows Server 2008 Step-by-Step Guide at
http://technet2.microsoft.com/windowsserver2008/en/library/edc9ae73-8df6-4bb5-a863-
45fdcb5496cb1033.mspx?mfr=true
For more information about server virtualization in Windows Server 2008, see the
Windows Server 2008 Hyper-V TechCenter at
http://go.microsoft.com/fwlink/?LinkId=101268

Feedback
Please direct questions and comments about this guide to satfdbk@microsoft.com.

Solution Accelerators microsoft.com/technet/SolutionAccelerators