Module 4: DNS As a
Solution for
Name Resolution
Overview

Introducing DNS

Designing a Functional DNS Solution

Securing DNS

Enhancing a DNS Design for Availability

Optimizing a DNS Design for Performance

Name resolution processes allow users to remember
resource names. You can use these resource names
instead of the numerical Internet Protocol (IP) addresses
that computers use to identify themselves on the
network.
DNS in Microsoft® Windows® 2000 allows users to refer
to network resources with easy-to-remember names by
resolving names to IP addresses. In this module, you
will evaluate and design a DNS solution for name
resolution.
At the end of this module, you will be able to:

Recognize DNS as a solution for name resolution.

Evaluate and create a DNS solution to support an
organization's name resolution requirement.

Select appropriate strategies to secure DNS.

Select appropriate strategies to enhance the availability
of DNS.

Select appropriate strategies to improve DNS
performance.
Introducing DNS

Design Decisions for a DNS Solution

Microsoft DNS Features

Integrating DNS with Other Windows 2000 Services

While designing a network, you must identify solutions
for name resolution to locate computers and services
on the network. The large number of available network
resources creates the need for meaningful resource
names to simplify the user's access to resources.
Basics of DNS

Windows 2000 DNS allows users to refer to network
resources with names complying with the DNS standard.
You can use DNS to resolve names to IP addresses. DNS
can also integrate with other Windows 2000 services to
extend the name resolution capabilities.
To design a strategy for locating network resources by
using DNS, you must:

Collect information about network and host
configuration, and the number of locations.

Identify the features provided by DNS and how these
features support the design requirements.

Identify the benefits provided by integrating DNS with
other services in Windows 2000.
Design Decisions for a DNS Solution
Internet
DNS
Private
Network
Firewall
DNS
UNIX
DNS
 Number of Locations?
 Number of Hosts at Each Location?
 Existing DNS Servers?
 Active Directory Infrastructure?
Active
Directory

The design of your DNS solution is based on criteria
that you collect during the design process. After you
have collected the criteria, you can begin designing
your DNS solution.
Some of the criteria that affects your DNS design includes the:

Number of locations. The number of locations determines the
minimum number of DNS servers because each location typically has
at least one DNS server.

Number of users at each location. The number of users at each
location determines the number of DNS clients that must be
supported within the location.

Existence of any prior DNS servers, such as UNIX or DNS servers in
Microsoft Windows NT® version 4.0. Existing DNS servers may limit
the use of DNS features such as incremental zone transfers.

Existence or plans to include an Active Directory™ directory service
infrastructure. Active Directory provides the option of including Active
Directory integrated zones in your DNS design.
Microsoft DNS Features
 Resolving Domain Names
 Integrating with Active Directory
 Integrating into Existing Network Designs
Microsoft DNS Features

To determine how Windows 2000 DNS integrates into an
existing infrastructure, you need to define the features
provided by DNS, its compliancy with the existing
standards, and the scope for extending the existing
services.
Resolving Domain Names
The solutions provided by DNS include:

Resolving traditional fully qualified domain names
(FQDNs).

Resolving network basic input/output system (NetBIOS)
names by forwarding queries to WINS.
Integrating with Active Directory
The integration of the DNS service with Active Directory
enhances a DNS design by:

Reducing network management. Network management
is reduced because DNS uses Active Directory
replication to replicate DNS zone records.

Providing secured and automatic maintenance of DNS
zone records by using dynamically updated DNS.
Integrating into Existing Network Designs

The DNS service in Windows 2000 is a superset of the Internet
Engineering Task Force (IETF) standards. You can integrate DNS
with other products that are based on the IETF standards. DNS
provides compatibility with DNS servers on other operating
systems by complying with Berkeley Internet Name Domain (BIND)
version 8.2.2. Crucial BIND compatibility includes:




Incremental zone updates that are supported by BIND version 8.2.1
and later.
A dynamically updated DNS zone database that is supported by
BIND version 8.1.2 and later.
Support for the SRV (service) resource record that is supported by
BIND version 4.9.7 and later.
Note: Although other versions of BIND can integrate with the DNS
services in Windows 2000, BIND version 8.2.2 is recommended.
BIND version 8.2.2 is the latest version and supports all enhanced
features.
Integrating DNS with Other Windows 2000 Services
DHCP
Server
WINS
Server
Active
Directory
Name
Registration
Name Resolution
Authentication
Replication
DNS
Server

DNS integrates with other networking services to take
advantage of their features. These features require you
to include additional specifications in the design, such
as forwarding name resolution queries to a WINS server.

The following table describes the benefits of integrating DNS with
other networking services.
DNS integrates with To
DHCP
WINS
Active Directory
Automatically update DNS entries when DHCP
addresses are assigned to DHCP client
computers.
Resolve DNS queries by forwarding the queries
to a WINS server and resolving the queries from
the WINS database entries.
Provide multiple master DNS zones, secured
zone updates, and encrypted DNS replication.
 Designing a Functional DNS Solution

Selecting the Appropriate Zone Types

Server Placement by Zone Type

Reverse Lookup Zone Design

Connecting DNS to the Internet

Integrating with BIND and DNS Servers in Windows NT 4.0

Integrating DNS and WINS

Strategies for Integrating into the Existing Namespace

There are a few essential design decisions that you
need to make for a DNS solution. After these essential
design decisions are established, you can optimize the
DNS solution by adding security, availability, and
performance enhancements to your design.
The essential design decisions for your DNS solution must include:

Which zone types to include in your design.

Where to place DNS servers based upon the zone types.

How to create designs that include reverse lookup zones.

How to create designs if the DNS servers in the private network
interact with the DNS servers on the Internet.

How the DNS services in Windows 2000 integrate with UNIX BIND
and Windows NT 4.0 DNS servers.

How to create designs that include WINS servers as part of the
solution.

How the DNS services in Windows 2000 integrate into an
organization's existing namespace.
Selecting the Appropriate Zone Types
 Chosen When Integrating into
Existing Active Directory
 Single Point of Support for DNS and
Active Directory
Active Directory
Integrated Zone
 Chosen for Integration into Existing
Infrastructure
 Separate Support for DNS and Active
Directory
Traditional DNS
Zone
 Chosen When Root Server is
Traditional DNS
 Supports Active Directory Integrated
Zones As a Delegated Domain
Combination of
Both Zone Types

You can base DNS services on Active Directory integrated zones,
on traditional DNS zones, or on a combination of both. Choose
Active Directory integrated zones where Windows 2000 DNS
servers will provide the master (primary) zones for your
architecture.If your organization uses Active Directory as the
directory service, you can choose either traditional DNS zones or
Active Directory integrated zones.
Choose Active Directory integrated zones if an Active Directory
infrastructure exists or is part of the long-term strategy of the
organization. Choose Active Directory integrated zones where
Windows 2000 DNS servers will provide the master (primary) zones
for your architecture. Choose a traditional DNS zone if DNS is being
integrated with existing DNS servers running UNIX or some other
operating system.
Active Directory Integrated Zones

Active Directory integrated zones store DNS zone information in Active
Directory. Active Directory integrated zones are:





Multi-master, read/write copies of the zone information. The multi-master
characteristic enables you to make updates to the original Active Directory
integrated zone, or make replicated copies of the zone. It ensures that you can
always perform updates to the DNS zone information.
Note: As a best practice, select Active Directory integrated zones if your DNS
design includes dynamic updates to DNS. Traditional DNS zones are not multimaster, so the failure of a DNS server with a primary zone prevents dynamic
updates.
Replicated by Active Directory. Because Active Directory integrated zones store the
zone information in Active Directory, the zone information is replicated along with
other Active Directory data.
Required for secured, dynamically updated DNS zones. Because Active Directory
integrated zones store the zone information, you can establish permissions for the
computer account that can update the DNS zone information.
Replicated only within an Active Directory domain. However, you can replicate
Active Directory integrated zone information outside the domain to traditional
secondary zones.
Treated as a traditional primary zone from another BIND-based DNS server. To a
BIND-based DNS server, Active Directory integrated zones appear as traditional
primary zones.
Traditional DNS Zones
Traditional DNS zones store the zone information in a file on the
computer running Windows 2000 and DNS. Traditional DNS zones:

Follow a single master model for storing and replicating zone
information. Primary zones are the only zone types that support a
read/write copy of the zone information. You are allowed only one
primary zone, but you can replicate read-only copies of the zone
information to any number of secondary zones.

Replicate incrementally or by transferring the entire zone
information. The replication between primary and secondary zones
can occur incrementally or by transferring the entire zone contents.
The DNS service in Windows 2000 supports both incremental and
complete zone transfers.

Function identically to BIND-based DNS servers. Traditional DNS
zones have the same benefits and constraints as BIND-based DNS
zones.
Combination of Both Zone Types

The following table compares Active Directory integrated zones
with traditional DNS zones.
Features of DNS
Active Directory
integrated zones
Traditional
DNS zones
Adheres to current IETF specifications
Yes
Yes
Uses a zone information replication method
based on Active Directory replication
Yes
No
Improves availability because each DNS server
contains a read/write copy of the zone
information
Yes
No
Allows updates to the zone information, even
with the failure of a single (or primary) DNS
server
Yes
No
Supports incremental zone transfers
Yes
Yes
Server Placement by Zone Type
Zone Type
Requirement
Active
Directory
integrated
zone
Improvement
Recommendation
Procedure
Requires one
Add DNS servers
Recommend one
Active Directory for availability and DNS server at
integrated zone performance
each remote
location
Traditional
DNS zone
Requires one
primary zone
Add secondary
or delegated
zones for
availability and
performance
Recommend one
DNS server at
each remote
location

The DNS zone type influences the placement of DNS
servers in a name resolution design. Each zone type
solves a specific requirement within a design. For
example, you would add a secondary zone server at a
remote location to improve performance.

When placing servers within a DNS design, you need to consider the DNS zone type.
The following table lists the DNS zone types and when you must select them.
Choose this
zone
When you need to create a DNS server that
Active Directory Is any server in a design based on Active Directory.
integrated
Primary
Is the first DNS server in a design based on traditional DNS.Has a
read/write copy of the zone information.Can administer zone
information separately.
Secondary
Improves the availability of primary zones by providing a complete
copy of the primary zone.Has a read-only copy of the zone
information.Improves performance at local and remote locations
by providing a local copy of a primary zone.Is placed in screened
subnets and accessed by Internet-based users (only expose
zones required for Internet name resolution)
Delegated
domain
Contains a subset of the domain namespace in an Active
Directory integrated zone or a primary zone.Improves
performance by reducing the number of records to be searched to
a subset of the namespace.
Reverse Lookup Zone Design
172.168.in-addr.arpa
Primary Zone
10.in-addr.arpa
Active Directory Integrated Zone
Internet
172.168.in-addr.arpa
Secondary Zone
10.in-addr.arpa
Active Directory Integrated Zone

Reverse Lookup Zone Types

Dynamic Updates and Reverse Lookup Zones
Reverse Lookup Zone Design

If applications or network security requires the
conversion of IP addresses to domain names, you can
include reverse lookup zones in your design. The
design decisions that you must make for reverse lookup
zones are very similar to those of forward lookup zones.
Only the contents of the DNS zone records are different
between forward and reverse lookup zones.
Reverse Lookup Zone Types

You can include the same zone types for reverse lookup
zones that you include for forward lookup zones. The
reverse lookup zones can be Active Directory integrated
zones, traditional primary zones, or traditional
secondary zones. You can apply the same decision
process discussed earlier in this module to reverse
lookup zones.
Connecting DNS to the Internet
DNS Server
Firewall
Internet
Secured
Private
Network
Firewall
Screened
Subnet
Forward Queries
Respond to Queries
DNS Server
 Forwarding DNS Queries to Internet-based DNS Servers
 Responding to DNS Queries from the Internet
Connecting DNS to the Internet

The DNS servers within a private network must interact
with servers on the Internet to resolve names. To do
this, the DNS servers in the private network forward
queries to and respond to queries from Internet-based
DNS servers.
Forwarding DNS Queries to Internet-based DNS Servers

When a DNS server receives a query, it attempts to
locate the requested information within its local zones
and from the cache. If it cannot locate the requested
information and is not authoritative for the requested
information, it must communicate with other servers to
resolve the request. The DNS server to which requests
are sent can be designated by configuring forwarders or
root hints.
The DNS servers within the organization typically sends
requests to:

DNS servers provided by the Internet Service Provider
(ISP) that the organization uses.

Internet root DNS servers provided by the Internet.
Integrating with BIND and DNS Servers in Windows
NT 4.0
DNS in Windows NT 4.0
Private Network
BIND DNS
 Dynamic DNS Zone Updates
 Unicode Characters
 Non-RFC Compliant Records
 SRV Record Types
 WINS and WINS-R Record Types
DNS
Integrating with BIND and DNS Servers in Windows NT 4.0

You can integrate Windows 2000 DNS with BIND and
Windows NT 4.0 DNS servers if the organization is
unable or unwilling to replace existing DNS servers. If
your organization has existing BIND or Windows NT 4.0
DNS servers, you can integrate the DNS services in
Windows 2000 with the existing DNS servers.


Windows 2000 DNS service treats BIND and Windows
NT 4.0 DNS servers as traditional DNS servers. BIND
and Windows NT 4.0 DNS servers support:

Standard primary zones.

Standard secondary zones.

Delegated domains.
If your network designs include BIND and Windows NT
4.0 DNS servers, you can make the same design
decisions as you would with a Windows 2000 DNS
server with the same zone type.
Dynamic DNS Zone Updates

Dynamic DNS zone updates allow DNS client computers
or DHCP servers to dynamically update DNS zone
entries. Dynamic DNS zone updates reduce the
administration of DNS zones and eliminate errors that
manually updating DNS zones introduce.
The most common reason for including dynamic DNS
zone updates in your network design is to support
Active Directory. Although not required, dynamic DNS
zone updates are recommended if your DNS solution
must support Active Directory.
If your design includes dynamic DNS zone update,
remember:

BIND versions 8.1.2 and later support dynamic DNS
zone updates.

Windows NT 4.0 DNS servers do not support dynamic
DNS zone updates.
Unicode Characters

The DNS service in Windows 2000 supports the use of
Unicode characters in DNS zones. BIND DNS and
Windows NT 4.0 servers support only RFC-compliant
(ANSI) characters.
If including BIND or Windows NT 4.0 DNS servers in
your network design, you must enforce RFC-compliant
characters on the DNS service in Windows 2000. This
enables the replication of zone information to the BIND
or Windows NT 4.0 DNS servers.
Non-RFC-Compliant Resource Records

Many vendors who implement BIND include vendor
specific, non-RFC-compliant resource records in the
DNS zone. Normally, when the DNS service receives one
of these resource records, the zone replication process
stops. If the BIND DNS zone includes non-RFC
compliant resource records, you can specify that the
DNS service in Windows 2000 ignore the records.
SRV Record Types

SRV record types allow you to designate several
servers as primary and backup servers. SRV records
are a special type of DNS round robin entries that are
similar to mail exchange (MX) records used by Simple
Mail Transfer Protocol (SMTP).
The most common reason for including SRV record
types in your design is to support Active Directory.
If your design includes SRV record types, remember:

BIND versions 4.9.6 and later support SRV record types.
Note: RFC 2782 documents SRV record type support.
WINS and WINS-R Record Types

The DNS service in Windows 2000 and Windows NT 4.0
supports WINS forward lookup and reverse lookup
record types (WINS and WINS-R). WINS and WINS-R
record types enable the DNS server to submit queries to
a WINS server and attempt resolution through WINS.
Normally, when you replicate these records to BIND
DNS servers, they see the WINS and WINS-R records as
invalid, non-RFC-compliant records.
If your design includes the DNS service in Windows
2000 or Windows NT 4.0 that replicates to a BIND DNS
server, you can specify that the WINS and WINS-R
records are not replicated to the BIND DNS server.
Integrating DNS and WINS
nwtraders.msft
private.nwtraders.msft
public.nwtraders.msft
wins.private.nwtraders.msft
WINS

Designate a Subdomain for WINS Resolution

Delegate Unresolved DNS Queries to a Subdomain

Specify WINS Server in Zone Configuration

In your network design, you can allow DNS clients to
resolve host names found in WINS, so that you do not
need to create DNS zone entries for all of the computers
in the organization. In the existing Windows NT 4.0
networks, performing DNS queries, which are resolved
by using WINS, does not require many changes to the
existing network infrastructure.
You can resolve host names found in WINS by
forwarding unresolved DNS queries to a WINS server.
You can establish the forwarding of unresolved DNS
queries to WINS on a zone-by-zone basis.
Designating a Subdomain for WINS Resolution

To integrate a WINS resolution within your DNS design,
designate a subdomain within the organization's
namespace that you will use as a placeholder for the
WINS names. Specify that the subdomain contains no
entries, except for the WINS and WINS-R records.
For organizations that have a separate private and
public namespace, create the subdomain for WINS
under the private namespace. For organizations that
have the same namespace for private and public name
resolution, create the subdomain for WINS at a level
beneath the root of the organization.
Delegating Unresolved DNS Queries to a Subdomain
For domain names that are within the organization's
namespace, if you want to:

Resolve names within WINS prior to other domains,
specify that the DNS queries be forwarded to a
delegated subdomain for WINS first.

Resolve names within other domains prior to WINS,
specify that the DNS queries be forwarded to a
delegated subdomain for WINS last.
Specifying WINS Server in Zone Configuration

To forward unresolved DNS queries to a WINS server, you enable
WINS resolution on a zone. A zone can resolve queries by using
more than one WINS server. You can specify the IP address of the
WINS servers in the order that the servers are to be contacted. To
improve the availability of your DNS solution, include more than
one WINS server in the list.
Your organization may not replicate all WINS records between all
WINS servers. If your organization's WINS database is divided
across multiple WINS servers, you can create a unique DNS zone
for each WINS server.
For example, consider an organization that has a WINS server that
includes WINS records only for Paris and another WINS server that
includes WINS records only for London. You can create a DNS zone
for Paris and a DNS zone for London so that you can create
different subdomain names for the Paris WINS server versus the
London WINS server. Conversely, you can create one DNS zone that
could list both WINS servers so that the WINS resolution occurs
beneath a single subdomain name.
Strategies for Integrating into the Existing
Namespace
Traditional Zone
nwtraders.msft
Existing DNS
Namespace
Active Directory
Integrated Zone
Traditional Zone
private.nwtraders.msft

Separate Public and Private Namespace

Single Subdomain Within Namespace

Multiple Subdomains Within Namespace

No Changes to Namespace
public.nwtraders.msft

The DNS zones provided by Windows 2000 are
compatible with DNS zones on BIND, or other DNS
services that do not run on Windows 2000. You can
integrate the DNS zones provided by Windows 2000 into
the existing namespace of an organization. You need to
integrate into the existing namespace if you are unable
to specify a computer running Windows 2000 as the
DNS root server for the organization.
Separate Public and Private Namespace

You can integrate DNS into the existing namespace of
an organization by creating separate public and private
namespaces. The existing namespace is contained
within the public portion of the namespace. The DNS
service in Windows 2000 would manage the private
portion of the namespace.

The benefits of a separate public and private
namespace include:


Improved security because users and computers outside
the organization do not have access to the private
namespace.
Minimal impact on the existing namespace and effort on
the part of the current DNS administrators.
Single Subdomain Within Namespace

Creating a single subdomain within the namespace is
very similar to the separate public and private
namespace strategy. However, you do not divide the
namespace into public and private portions. Instead,
specify that all Windows 2000-based DNS servers reside
beneath a single subdomain within the namespace.

The primary benefit of this strategy is that there is
minimal impact on the existing namespace, and minimal
effort put forth on the part of the current DNS
administrators.
For example, if the root name of the organization is
nwtraders.msft, you could create a subdomain called
windows.nwtraders.msft that contains all Microsoft DNS
servers and DNS clients.
Multiple Subdomains Within Namespace

You can create multiple subdomains within the
namespace if the organization is unable or unwilling to
create subdomains close to the root domain. If
presented with this requirement, you can specify
subdomains within lower portions of the namespace
hierarchy. The benefit of this approach is that higher
portions of the namespace remain unchanged. The
consequence of this approach is that the existing DNS
administrators need to create subdomains at multiple
points in the namespace hierarchy.
No Changes to Namespace

There are also instances in which the existing DNS
servers manage all of the primary DNS zones. In this
situation, the DNS zones managed by Windows 2000 are
integrated as only secondary zones.
Active Directory requires a Windows 2000 domain
controller. The difficulty for the designer is that the
wizard for implementing Windows 2000 as a domain
controller defaults to creating an Active Directory
integrated zone. If you cannot create a separate zone
within the organization, you must integrate your first
domain controller without the wizard.

To integrate the first Windows 2000 domain controller, you can specify the
following process:
1.
Configure the computer running Windows 2000 as a standalone server.
2.
Ensure that the computer running Windows 2000 supports a secondary
zone to the exiting DNS zones.
3.
Configure the computer running Windows 2000 to perform dynamic updates
to the existing DNS primary zone.
Note: If the existing DNS servers do not support dynamic updates, the DNS
administrators must manually add records to the primary zone. For more
information about the records that you must add, see the Windows 2000
deployment guide.
4.
Promote the computer running Windows 2000 to a domain controller.
Note: If the existing DNS servers do not support SRV records, then the
existing DNS servers cannot support Active Directory unless the Active
Directory specific zones are delegated to a Windows 2000 DNS by using
Active Directory integrated zones. You must upgrade the version of DNS
running on the existing DNS servers or replace the servers with DNS servers
that support SRV records.
Discussion: Designing DNS Solutions
Seattle
Winnipeg
Montreal
Toronto
New York
Kansas City
Los Angeles
Washington DC
Atlanta
Dallas

As DNS designs are created, information relating to the
solution needs to be translated into design
requirements. This scenario involves designing basic
DNS solutions.
The following scenario describes the current network
configuration of a telemarketing company.
Read the scenario and answer the questions that follow.
Scenario

A telemarketing research company collects
demographics on potential consumers for other
organizations' products and services. At each location,
market research analysts conduct telephone interviews
to determine the purchasing decisions of the target
consumer profile. Each location has a dedicated T1 or
T3 connection to the Internet.

The market research analysts use a Web-based
application for call tracking and recording of consumer
responses. The organizations that are funding the study
can examine the results over the Internet by using a
Web-based application, or access the data directly from
a Microsoft SQL Server™ located in the Kansas City
location.
 Securing DNS

Securing Dynamically Updated DNS Zones

Securing DNS Zone Replication

Integrating DNS into Screened Subnets

You can secure DNS access from private and public
networks. Within a private network, you can secure DNS
by restricting updates to dynamically updated DNS
zones. Over public networks, you can secure DNS zone
replication traffic by using Internet Protocol Security
(IPSec), virtual private network (VPN) tunnels, and
Active Directory. To protect DNS servers exposed to the
Internet, you can restrict DNS zone information and use
screened subnets.
In this lesson you will learn about the following topics:

Securing dynamically updated DNS zones

Securing DNS zone replication

Integrating DNS into screened subnets
Securing Dynamically Updated DNS Zones
sales.contoso.msft
HOST (A)
Resource
Record
Dynamically
Updated Zone
Original
Web Server
sales.contoso.msft
New UNIX-based
Web Server

Active Directory Integrated Zone Required

Permissions Assigned in the Active Directory

Dynamic DNS Updates from DHCP

Dynamic DNS Updates from Windows 2000

Dynamically updated DNS servers can automatically
register the name and IP address of client computers.
To prevent the impersonation of servers within the
private network, you need to prevent unauthorized
updates to the dynamically updated DNS servers by
using secured dynamic updates.
For example, a server hosting a Web site has a Host (A)
record in a dynamically updated DNS zone. A second
server is installed that has the same FQDN as the server
hosting the Web site. Without secured dynamic updates,
the newly installed server can modify the Host (A)
record for the server that hosts the Web site. The
second server could also begin to capture secure
information from the Host record, such as user
accounts and passwords.
Active Directory Integrated Zone Required

Secured dynamic updates are a feature found only in
Active Directory integrated zones. Because the DNS
zone information is stored in Active Directory, you can
secure the DNS zone information by using the security
within Active Directory.
Permissions Assigned in Active Directory
You can view and change the permissions for all DNS
objects from within the Active Directory Users and
Computers console or through the properties of zone
and resource record in the DNS console. To secure
dynamically updated DNS zones within your design,
consider that permissions:

To update the DNS zone are made in the DNS zone
container within Active Directory.

Can be assigned for the entire DNS zone or for
individual resource records within the zone.

Can be assigned to a computer, group, or user account.
Dynamic DNS Updates from DHCP

You can specify that the DHCP servers within your
network dynamically update DNS when the DHCP server
configures a DHCP client computer. On the DHCP
server, you would specify the DNS zone(s) that the
DHCP server is responsible for automatically updating.
On the DNS server, you would specify the DHCP server
as the only computer that is authorized to update the
DNS entries.
Include dynamic DNS updates from DHCP servers if:

The DNS client operating system is not Windows 2000.

Assigning the permissions that enable each computer,
group, or user to update the respective NS entries
becomes unmanageable.

Allowing individual DNS clients to update DNS entries
without specifying secure dynamic update presents
possible security risks. This could potentially allow
unauthorized computers to impersonate authorized
computers.
Dynamic DNS Updates from Windows 2000

DNS clients that are running Windows 2000 can directly
update DNS automatically. When the Windows 2000based client starts, the DNS client can connect to the
DNS server and automatically register the DNS client
with the DNS server.

Include DNS clients that directly update DNS if:



The computer has a manually assigned, fixed IP
address.
Assigning the permissions that enable the computer to
update the respective DNS entries is manageable.
Allowing individual DNS clients to update DNS entries
poses no potential security risks
Securing DNS Zone Replication
Primary Zone
Active Directory
Integrated Zone
= VPN Tunnel
= Active Directory
Replication
Internet
Secondary Zone
Active Directory Integrated Zone
 Encryption Using IPSec or VPN Tunnels
 Encryption and Authentication Using Active Directory

With the increasing use of VPNs, DNS zone replication
can occur across public networks, such as the Internet.
It is important to protect the names and IP addresses
replicated over these public networks against
unauthorized access. You can protect the replication
data by using IPSec, VPN tunnels, or Active Directory.
Securing DNS Zone Replication
Encryption Using IPSec and VPN Tunnels
You need to encrypt all replication traffic sent over
public networks. If you encrypt replication traffic by
using IPSec or VPN tunnels, consider using:

The strongest level of encryption and VPN tunnel
authentication.

Routing found in the Routing and Remote Access
feature of Windows 2000 to provide the IPSec or VPN
tunnels.
Encryption and Authentication Using Active Directory
You can protect replication traffic by using Active
Directory integrated zones. Because Active Directory
integrated zones are based on Active Directory, they
provide inherent security by:

Replicating exclusively between DNS servers that have
Active Directory integrated zones.

Requiring all DNS servers that have Active Directory
integrated zones to be registered with Active Directory.

Encrypting all replication traffic between DNS servers.
Integrating DNS into Screened Subnets
public.contoso.msft
Primary DNS Zone
public.contoso.msft
Secondary DNS Zone
Internet
Private
Network
Firewall
Screened
Subnet
Firewall

Zones Contain Records for Public Resources

Configure Firewalls to Permit Appropriate DNS Traffic

Place Only Secondary Zones

Encrypt Replication Traffic with IPSec or VPN Tunnels

When integrating DNS servers into a screened subnet,
restrict Internet-based user access and encrypt any
zone replication that initiates within the private network.
You can restrict Internet-based user access (to prevent
unauthorized updates to the DNS zone information) by
using firewalls and secondary zones. You can encrypt
zone replication traffic with IPSec and VPN tunnels.

When integrating DNS servers into a screened subnet,
consider:

Placing DNS servers, which contain zone information
for resources, in a location that is accessible from the
Internet.
All of the DNS servers must not be accessible from the
Internet because:


Exposing the entire DNS namespace could expose
names and IP addresses that you want to hide from
Internet-based users.
Adding the entire DNS namespace increases the
number of entries in the DNS server and reduces
performance.

Configuring firewalls to permit DNS queries only from
the Internet, and replication traffic only from the private
network, to prevent potential paths for unauthorized
users to gain access.

Placing only DNS servers that contain secondary zones
in the screened subnet.
You must consider the placement of these DNS servers
because:



Secondary zones have read-only copies of zone
information that Internet-based users cannot modify.
Primary zones have read/write copies of zone
information that Internet-based users can modify.
Active Directory integrated zones have read/write copies
of zone information that Internet-based users can modify
and that can potentially provide an unauthorized path to
Active Directory.

Encrypting zone replication traffic with IPSec or VPN
tunnels. By using encryption, you can hide the names
and IP addresses within the replication traffic from the
Internet-based users.
 Enhancing a DNS Design for Availability

Enhancing DNS Availability with Replicated DNS Zones

Enhancing DNS Availability with Server Clusters
Any DNS solution that requires high availability must
include more than one DNS server. Availability in a DNS
implementation design is measured by the percentage
of time users are able to resolve names by using DNS.
Windows 2000 enhances DNS availability with:

Multiple DNS servers that use DNS zone transfers or
Active Directory replication.

Multiple DNS servers that use server clusters.
Enhancing DNS Availability with Replicated DNS Zones
Active Directory
Integrated Zones
Traditional
DNS Zones
Replication
Active Directory
Integrated Zone
Primary
Zone
Replication
Secondary
Zone
Active Directory
Integrated Zone
For this zone type You can improve availability by
Active Directory
integrated zone
Performing incremental replication between DNS
servers.
Adjusting the Active Directory replication schedule.
Traditional DNS
zone
Replicating between primary and secondary zones.
Performing an incremental zone transfer instead of a
complete zone transfer.
Enhancing DNS Availability with Replicated DNS Zones

You can enhance the availability of DNS by
implementing multiple DNS servers that have replicated
zones at local and remote locations. By adding
additional DNS servers at remote locations, you can
ensure DNS availability in the event of a wide area
network (WAN) link or router failure.

You can configure two DNS servers to provide redundancy and load
balancing. By using replication, both servers contain the same DNS
zone database information. The following table describes how to
improve availability of DNS for a particular zone type.
For this zone type
You can improve availability by
Active Directory integrated Performing incremental replication
between DNS servers.Adjusting the
Active Directory replication schedule.
Traditional DNS zones
Replicating between primary and
secondary zones.Performing an
incremental zone transfer instead of a
complete zone transfer.

Note: A network design that uses DNS replication to improve DNS
availability consumes fewer system resources than a network
design that uses Windows Clustering. However, Windows Clustering
provides a higher level of availability.
Enhancing DNS Availability with Server Clusters
DNS
Zone
Primary
Cluster Node
Cluster
Drive
Server Cluster

Store DNS Zone Files on Cluster Drive

Restore Failed Servers Faster

Do Not Provide Immediate Failover
Backup
Cluster Node

You can enhance the availability of DNS by using server clusters
found in Windows Clustering in Windows 2000 Advanced Server or
Windows 2000 Datacenter Server. You use server clusters to
enhance the availability of a single DNS server.
By configuring DNS on a server cluster, you can:



Store standard DNS zone file on a cluster drive so that the other
cluster node has access to the latest DNS zone file.
Maintain availability of DNS services in the event of primary DNS
server failure.
Restore failed servers sooner because zone database
resynchronization is not required.
Note: Although DNS is not a cluster-aware application, you can
enhance DNS availability by using server clusters.

The availability that is provided by server clusters is
used for solving availability issues only at local
locations. Windows 2000-based servers that belong to
the same cluster require persistent, high-speed
connections between all servers in the cluster. The need
for a persistent, high-speed connection prohibits server
clusters from providing a solution for remote locations.
 Optimizing a DNS Design for Performance

Reducing Query Resolution Time

Reducing the Impact of Replication on Network Traffic

You can measure the performance of a DNS design by
the time required to resolve DNS queries and by the
network bandwidth utilization during DNS replication.
You can optimize the performance of a DNS design to
provide the fastest possible response to client and
replication requests.
You can improve the performance of a DNS server by
upgrading the computer hardware. These improvements
include upgrading the processors, adding additional
memory, increasing the disk capacity, increasing the
disk data transfer rates, and increasing the network data
transfer rates.
In addition to upgrading the computer hardware, you
can also improve the performance of a DNS server by:

Reducing the query resolution time.

Reducing the impact of replication on network traffic.
Reducing Query Resolution Time
New York
Primary Zone
Load Balancing
contoso.msft
London
Tokyo
Cache
Secondary Zone
london.contoso.msft
Caching-only
DNS Server

Caching-only Servers

Delegated Zones

Load Balancing Using Multiple DNS Servers
Delegated Zone
Reducing Query Resolution Time

Reducing DNS query resolution time provides the
improvement in performance that is most visible to end
users and management. As a result, a network design
that reduces query resolution time is highly successful.
Caching-only Servers

Caching-only servers do not host any zones, but instead
cache requests that are forwarded to servers that do
host zones. The caching-only server retains cached
copies of queries for subsequent retrieval. By locally
caching DNS requests, the caching-only server reduces
traffic across WAN links to remote locations.
Caching-only Servers
Consider using caching-only servers if:

Remote locations are connected by low-speed WAN
links.

The addition of DNS zone replication traffic would
overuse WAN links.

The DNS zone information does not change frequently.
Delegated Zones

As the number of IP-based hosts within an organization
increases, the size of the DNS zone databases increases
as well. Similarly, as the DNS zone database size
increases, the length of time to resolve DNS queries
increases. Delegated zones divide a DNS zone database
into smaller parts, thereby reducing the length of time
needed to resolve DNS queries within the delegated
zone.
Delegated Zones
Consider using delegated zones if:

The DNS namespace design is hierarchical.

The cost of adding additional servers to support the
delegated zone is not prohibitive.
Load Balancing Using Multiple DNS Server Zones

DNS designs that contain redundant DNS zones on
multiple servers allow queries to be distributed across
servers, thereby improving performance by providing
load balancing.
Load Balancing Using Multiple DNS Server Zones
Consider using load balancing with redundant DNS
zones if:

The length of time required to resolve DNS queries is
unacceptably long.

The connection between the DNS servers supports the
additional DNS replication traffic.

The traffic generated by DNS clients accessing a DNS
server in another location overuses a WAN link.
Note: WINS may affect the length of time needed to
resolve DNS queries if you configure the DNS zone to
attempt resolution by using WINS.
Reducing the Impact of Replication on Network
Traffic
New York
Primary Zone
Replication Schedule
Secondary Zone
London
Tokyo
Secondary Zone
Secondary Zone

Use Fast Zone Transfers to Compress Replication Data

Modify the Replication Schedule

Perform Incremental Zone Updates
Reducing the Impact of Replication on Network Traffic

For network segments that are overused, you can
reduce the impact of DNS replication traffic. By reducing
the impact of DNS replication traffic, you improve the
data transmission rates for other network traffic.
To improve the performance of replication traffic,
consider:

Using fast zone transfers to compress the zone
replication data in a standard DNS infrastructure.
Versions of BIND prior to 4.9.7 are not tested by
Microsoft Corporation to support fast zone transfers.

Modifying the replication schedule of secondary zones
to replicate during non-peak hours of operation.

Performing incremental zone replication instead of
complete zone replication when possible.
Note: Incremental zone replication requires BIND
version 8.2.1 and later. Windows NT 4.0 DNS server
performs only complete zone transfers.
Discussion: Enhancing DNS Solutions
Seattle
Winnipeg
Montreal
Toronto
New York
Kansas City
Los Angeles
Washington DC
Atlanta
Dallas

After providing a basic DNS solution, the security,
availability, and performance requirements for the
solution need to be examined.
The following scenario describes the requirements for
enhancing the DNS design of a telemarketing company.
Read the scenario and answer the questions that follow.
Scenario

A year after creating the solution for the telemarketing
research company, the company decides to restructure
the domain name to create subdomains for each
location. The zone for each subdomain will be
administered within the respective location. During the
process, the DNS design for each location will be reevaluated.
Lab A: Designing a DNS Solution
Objectives
After completing this lab, you will be able to:

Evaluate an existing DNS-based network infrastructure.

Design a DNS solution for the given scenario.
Prerequisites
Before working on this lab, you must have:

Knowledge of DNS features and functionality.

Knowledge of DNS strategies for enhancing security,
availability, and performance.
Exercise 1: Designing a DNS Solution

In this exercise, you are presented with the task of
designing a DNS solution for an insurance firm. This
insurance firm has a central office, six regional offices,
and two types of insurance agent offices. You will
design the central office, the regional office, and one of
the insurance agent offices. You will design a DNS
solution that supports an organization's name
resolution requirements.
Review the scenario, the design requirements, and the
diagram. Follow the instructions to complete the
exercise.
Scenario

An insurance firm is evaluating their existing network in
preparation for the deployment of Windows 2000. As a
consultant to the firm, you have been assigned the task
of evaluating and redesigning the current network.
The insurance firm has a central office that handles
billing and accounting for the firm. In addition, the firm
has six regional offices that support the insurance
agents within each region.
The insurance agent offices are independently owned
and operated. The agent offices can consist of an
individual agent or a group of agents working at a single
location.
Design Requirements and Limitations

Investigation of the current network, user traffic
patterns, and future network requirements reveals the
following additional information that you must consider
when making your design decisions.
Applications
The insurance firm uses a number of applications to conduct dayto-day operations. To create a solution for the insurance firm, your
design must provide:

Support for a mission-critical Web-based application that manages
customers and their policies.

Support for a mission-critical Web-based application that allows
customers to check the status of claims and historical claim
payment information over the Internet.

Private network access to all shared folders and Web-based
applications from the central and regional offices.

Internet access from the central and regional offices.

DNS query response times such that the application response time
is not reduced. Pilot tests on approved DNS servers indicate that
each DNS server can support no more than 1,200 hosts while
providing performance within given application response times.

Support for all mission-critical applications to be available 24hours-a-day, 7-days-a-week.
Connectivity
The applications used by the insurance firm require connectivity
between the central office, the regional offices, and the agent
offices. When creating the DNS design for the insurance firm,
remember that your design must provide:

Support for the regional offices to connect to the central office by
using dedicated connections over the Internet.

Support for the agent offices that consist of multiple agents to
connect to the regional offices by using dedicated connections
over the Internet.

Support for the agent offices that consist of an individual agent to
connect to the regional offices by using dial-up connections over
the Internet.

Isolation of the central office, the regional offices, and the agent
offices from the Internet.
Instructions
To complete this exercise you must:
1.
Examine the current networking environment presented in the
scenario, the network diagrams, and the design requirements and
limitations.
2.
Design your DNS solution. Ensure that your design fulfills the
requirements of the scenario.
Consider the following while designing your DNS solution:

Placement of DNS servers within the network.

Types of DNS zones supported on each DNS server.


DNS replication specifications between the zones on each DNS
server.
Required methods of improving the security, availability, and
performance.
Review

Introducing DNS

Designing a Functional DNS Solution

Securing DNS

Enhancing a DNS Design for Availability

Optimizing a DNS Design for Performance