module 4: dns as a solution for name resolution. overview introducing dns designing a functional dns...
DESCRIPTION
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.TRANSCRIPT
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