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

Number of Locations?

Number of Hosts at Each Location?

Existing DNS Servers?

Active Directory Infrastructure?

DNS

PrivateNetwork

ActiveDirectory

UNIXDNS

Firewall

Internet DNS

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

WINS Server

NameRegistration

AuthenticationReplication

Name Resolution

DNS Server

Active Directory

DHCP 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 withDNS integrates with ToToDHCP Automatically update DNS entries when DHCP

addresses are assigned to DHCP client computers.

WINS Resolve DNS queries by forwarding the queries to a WINS server and resolving the queries from the WINS database entries.

Active Directory 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

Chosen for Integration into Existing Infrastructure

Separate Support for DNS and Active Directory

Chosen When Root Server is Traditional DNS

Supports Active Directory Integrated Zones As a Delegated Domain

Active DirectoryIntegrated Zone

Combination ofBoth Zone Types

Traditional DNSZone

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 multi-master, 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 DNSFeatures of DNS Active Directory Active Directory integrated zonesintegrated zones

Traditional Traditional DNS zonesDNS zones

Adheres to current IETF specifications Yes YesUses 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 Improvement Procedure

Recommendation

Active Directory integrated zone

Requires one Active Directory integrated zone

Add DNS servers for availability and performance

Recommend one DNS server at 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 Choose this zonezone

When you need to create a DNS server thatWhen you need to create a DNS server that

Active Directory integrated

Is any server in a design based on Active Directory.

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

Reverse Lookup Zone Types Dynamic Updates and Reverse Lookup Zones

Internet

172.168.in-addr.arpaPrimary Zone

172.168.in-addr.arpaSecondary Zone

10.in-addr.arpaActive Directory Integrated Zone

10.in-addr.arpaActive Directory Integrated Zone

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

Forwarding DNS Queries to Internet-based DNS Servers

Responding to DNS Queries from the Internet

SecuredPrivate

Network

DNS Server

Forward QueriesForward Queries

Respond to QueriesRespond to Queries

Firewall

Firewall

Internet

ScreenedSubnet

DNS Server

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

Dynamic DNS Zone Updates

Unicode Characters

Non-RFC Compliant Records

SRV Record Types

WINS and WINS-R Record Types

Private Network

BIND DNS

DNS in Windows NT 4.0

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

wins.private.nwtraders.msft

public.nwtraders.msft

nwtraders.msft

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

Separate Public and Private Namespace Single Subdomain Within Namespace Multiple Subdomains Within Namespace No Changes to Namespace

Active DirectoryIntegrated Zone

nwtraders.msft

public.nwtraders.msftprivate.nwtraders.msft

Traditional Zone

Traditional Zone

Existing DNSNamespace

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

Los Angeles

Dallas

Winnipeg

Toronto

Montreal

New York

Washington DC

Atlanta

Kansas City

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

Active Directory Integrated Zone Required Permissions Assigned in the Active Directory Dynamic DNS Updates from DHCP Dynamic DNS Updates from Windows 2000

OriginalWeb Server

DynamicallyUpdated Zone

HOST (A)ResourceRecord

sales.contoso.msft

New UNIX-basedWeb Server

sales.contoso.msft

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 2000-based 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

Encryption Using IPSec or VPN Tunnels Encryption and Authentication Using Active Directory

Active DirectoryIntegrated Zone

Secondary Zone

Primary Zone

Active Directory Integrated Zone

= VPN Tunnel

Internet

= Active DirectoryReplication

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

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

public.contoso.msft

Firewall Firewall

InternetScreened

Subnet

public.contoso.msftPrimary DNS Zone Secondary DNS Zone

PrivateNetwork

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 ZonesTraditional DNS Zones

Active Directory Integrated Zones

Active DirectoryIntegrated Zone

ReplicationPrimary Zone

Secondary Zone

Replication

For this zone type You can improve availability byActive 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.

Active DirectoryIntegrated Zone

For this zone typeFor this zone type You can improve availability byYou can improve availability by

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 typeFor this zone type You can improve availability byYou can improve availability byActive 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

Store DNS Zone Files on Cluster Drive Restore Failed Servers Faster Do Not Provide Immediate Failover

Server Cluster

PrimaryCluster Node

ClusterClusterDriveDrive

DNS Zone

BackupCluster 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

Caching-only Servers Delegated Zones Load Balancing Using Multiple DNS Servers

New York

LondonTokyo

Secondary Zone

Caching-onlyDNS Server Delegated Zone

CacheCache

Primary Zone

contoso.msft

london.contoso.msft

Load Balancing

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

Use Fast Zone Transfers to Compress Replication Data Modify the Replication Schedule Perform Incremental Zone Updates

New York

LondonTokyo

Secondary Zone

Secondary Zone Secondary Zone

Primary Zone

Replication Schedule

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

Los Angeles

Dallas

Winnipeg

Toronto

Montreal

New York

Washington DC

Atlanta

Kansas City

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 re-evaluated.

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 day-to-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 24-hours-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