Module 5: Planning A DNS Strategy

Module 5: Planning a DNS Strategy
Contents Overview Lesson: Planning DNS Servers Multimedia: How DNS Clients Resolve Names Multimedia: Resolving Names with a DNS Server Lesson: Planning a Namespace Multimedia: A Planning DNS Namespace Strategy Lesson: Planning Zones Lesson: Planning Zone Replication and Delegation Lesson: Integrating DNS and WINS Multimedia: Integrating DNS and WINS Lab A: Planning a DNS Strategy 1 2 3 8 18 19 31 42 53 54 62
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2003 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT, Active Directory, MSDN, PowerPoint, SharePoint, Visual Basic, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
iii
Instructor Notes
Presentation: 2 hours, 30 minutes Lab: 60 minutes This module provides students with the information they need to plan a Domain Name System (DNS) implementation in an organization. After completing this module, students will be able to:

Plan a DNS server implementation. Plan a namespace strategy. Plan zones. Plan zone replication and deletion. Integrate DNS and WINS.
Required materials
To teach this module, you need the following materials:

Microsoft PowerPoint file 2278B_05.ppt Multimedia files: How DNS Clients Reserve Names Resolving Names with a DNS Server Planning a DNS Namespace Strategy Integrating DNS and WINS
Important It is recommended that you use PowerPoint 2002 or later to display the slides for this course. If you use PowerPoint Viewer or an earlier version of PowerPoint, all the features of the slides may not be displayed correctly. Preparation tasks To prepare for this module:

Read all of the materials for this module. Complete the practices and the lab, and review the lab answer key. Observe the multimedia presentations. Review the prerequisite courses and modules.
iv
How to Teach This Module

This section contains information that will help you to teach this module.
How To Pages, Guidelines and Practices, and Labs

Explain to the students how the How To pages, practices, and labs are designed for this course. A module includes two or more lessons. Most lessons include How To pages and a practice. After completing all of the lessons for a module, the module concludes with a lab. How To pages The How To pages are designed for the instructor to demonstrate how to do a task. The students do not perform the tasks on the How To page with the instructor. They will use these steps to perform the practice at the end of each lesson. The guidelines pages are pages that provide you with the key decision points for the topic of the lesson. You will use these guidelines as a reinforcement of the lesson content and objectives. After you have covered the contents of the topic, and demonstrated the How To procedures for the lesson, explain that a practice will give students a chance for hands-on learning of all the tasks discussed in the lesson. At the end of each module, the lab enables the students to practice the tasks that are discussed and applied in the entire module. Using scenarios that are relevant to the job role, the lab gives students a set of instructions in a two-column format. The left column provides the task, for example: Create a group. In the right column are specific instructions that the students need to perform the task, for example: From Active Directory Users and Computers, double-click the domain node. An answer key for each lab exercise is located on the Student Materials compact disc, in case the students need step-by-step instructions to complete the lab. They can also refer to the practices and How To pages in the module.
Guidelines pages
Practices
Labs
Lesson: Planning DNS Servers

This section describes the instructional methods for teaching this lesson. Overview When you introduce this lesson, emphasize that the planning decisions students will make for DNS servers are influenced by whether or not they will use the Active Directory directory service. When you teach this topic, point out that there are several issues that affect the placement of DNS servers. These include client considerations, the physical structure of the network, and the number of DNS servers on the network that perform different roles.
Determining DNS Server Placement
DNS Server Roles Levels of Securing Microsoft DNS Servers
When you discuss DNS server roles, tell students that they can use servers in any or all of these roles in an environment to provide a DNS solution. When you teach this topic, emphasize that it is unlikely that students would choose to implement low-level security on a DNS server. Also, clarify that these security levels are not discrete choices or setting labels. Instead they are general categories of security measures that the students implement using a variety of settings.
Lesson: Planning a Namespace

This section describes the instructional methods for teaching this lesson. DNS Namespace Options When you discuss DNS namespace options, point out that .local is not a valid domain suffix on the Internet; it is only valid internally. If the students choose an internal namespace that is valid on the Internet, they should register it.
Lesson: Planning Zones

This section describes the instructional methods for teaching this lesson. Selecting Zone Types When you discuss zone types, tell the students that in Microsoft Windows Server 2003, they select zone types first and then choose the storage location. To clarify this, you may want to demonstrate creating a new zone by using the wizard in Windows Server 2003. In this topic, recommend the use of an Active Directory zone whenever appropriate. In most cases, an Active Directory zone is more secure and easier to manage than a traditional zone.
Selecting Zone Data Location
Lesson: Planning Zone Replication and Delegation

This section describes the instructional methods for teaching this lesson. When to Create a Secondary Zone Zone Delegation Emphasize that in an exclusive Active Directory environment, if the students use Active Directoryintegrated zones, they will not require secondary zones. When you discuss the necessity of planning for zone delegation, emphasize that the students should also have a plan for forwarding.
Lesson: Integrating DNS and WINS

This section describes the instructional methods for teaching this lesson. Overview When you introduce this lesson, explain to students that they will need to integrate DNS and Windows Internet Name Service (WINS) when they have DNS clients that need to query names that are only located in WINS. Point out to students that modifying cache timeout settings is an optimization step and that you will discuss optimizing in more detail in Module 6, Optimizing and Troubleshooting DNS.
Modifying Cache Timeout Settings
vi
Lab A: Planning a DNS Strategy

Before beginning the lab, students should have completed all of the practices. Remind the students that they can return to guidelines and content pages in the module for assistance. The answer key for each lab is provided on the Student Materials compact disc.
Customization Information
This section identifies the lab setup requirements for a module and the configuration changes that occur on student computers during the labs. This information is provided to assist you in replicating or customizing Microsoft Official Curriculum (MOC) courseware. The lab in this module is also dependent on the classroom configuration that is specified in the Customization Information section at the end of the Automated Classroom Setup Guide for Course 2278, Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure.
Lab Setup
There are no lab setup requirements that affect replication or customization.
Lab Results
There are no configuration changes on student computers that affect replication or customization.
Overview
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Module objectives This module provides you with the information you need to plan a Domain Name System (DNS) implementation for your organization. After completing this module, you will be able to:

Plan a DNS server implementation. Plan a namespace strategy. Plan zones. Plan zone replication and deletion. Integrate DNS and WINS.
Lesson: Planning DNS Servers
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Enabling objectives This lesson covers DNS server configurations and properties. In addition, the lesson discusses security for DNS servers. After completing this lesson, you will be able to:

Determine DNS server configurations. Determine DNS server properties. Determine DNS Security (DNSSEC) support. Determine User Datagram Protocol (UDP) message size.
Multimedia: How DNS Clients Resolve Names
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objectives The objective of this presentation is to explain how DNS clients resolve host names to IP addresses. You will learn how to:

Explain the functionality of a DNS server in a routed network. Identify a fully qualified domain name. Explain the process for using a DNS server to resolve a HOST name to an IP address.
Key questions
When viewing this presentation, you should consider the following questions:

What is the function of a DNS server? How does a DNS server process fully qualified domain names? How does a DNS server resolve a HOST name to an IP address?
Determining DNS Server Requirements
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction After you have defined your DNS plan, you need to determine the server requirements. You will need to consider several factors when planning your DNS server. You should:

Perform capacity planning and review the server hardware requirements. Determine the number of DNS servers you need and their roles in your network. When deciding the number of DNS servers to use, you need to decide the servers that will host primary and secondary copies of the zones. Also, if you are using the Active Directory directory service, determine whether the server computer performs as a domain controller or a member server for the domain. Decide where you are going to place DNS servers on your network for traffic loads, replication, and fault tolerance. Decide whether to use only DNS servers running Microsoft Windows Server 2003 for all of your DNS servers or whether you will employ a mixture of Windows and other DNS server implementations.
Planning server capacity
Planning and deploying DNS servers on your network involves examining several aspects of the network and the capacity requirements for any DNS servers that you intend to use in it. Consider the following factors when planning server capacity:
Determine the number of zones that the DNS server is expected to load and host. For each zone that the server is loading for service, determine the size of the zone based on the size of the zone file or the number of resource records that are used in the zone. For a multiple-homed (more than one IP address) DNS server, determine the number of addresses that are to be enabled for listening to and servicing DNS clients on each of the servers connected subnets. Define the total number of client DNS query requests that a DNS server is expected to receive and service.
DNS server system requirements
In many cases, adding more RAM to a DNS server can result in noticeable performance improvement. This improvement is because the DNS server service fully loads all of its configured zones into memory at startup. If your server is operating and loading a large number of zones, and if dynamic updates occur frequently for zone clients, additional memory can be helpful. Keep in mind that, for typical usage, the DNS server consumes system memory as follows:
Approximately 4 megabytes (MB) of RAM is used when the DNS server is started without any zones. The DNS server consumes additional server memory for each zone or resource record that is added to the server. It is estimated that an average of approximately 100 bytes of server memory are used for every resource record that is added to a server zone. For example, if a zone containing 1000 resource records is added to a server, it will require approximately 100 kilobytes (KB) of server memory.
You can begin determining your server plans by reviewing sample DNS server performance test results collected by the Windows Server 2003 DNS development and testing teams. In addition, you can use DNS serverrelated counters that are provided for use with Windows Server 2003 monitoring tools to obtain your own performance measurements for the DNS servers that are running Windows Server 2003 that you deploy on your network. Important The preceding recommendations are not intended to indicate the maximum performance or limitations for DNS servers that are running Windows Server 2003. These numbers are approximate and can be influenced by the type of the resource records that are entered in zones, the number of resource records that have the same owner name, and the number of zones in use at a specific DNS server.
Determining DNS Server Placement
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You need to consider several factors when deciding where to place your DNS servers. You need to determine not only where to place the servers, but also the number of servers you need and their system configuration. In general, place your DNS servers at a location on your network that is most accessible to your clients. It is often most practical to use a DNS server on each subnet. Consider the following factors when deciding where to place a DNS server:
DNS server placement
If you are deploying DNS to support Active Directory, identify if the DNS server computer is also a domain controller or is likely to be promoted to one in the future. If the DNS server stops responding, determine if its local clients are able to gain access to an alternate DNS server. If the DNS server is located on a subnet that is remote to some of its clients, identify the other DNS servers or name resolution options that are available if the routed connection stops responding. For DNS server installations in which the use of Active Directory is an issue, review special interoperability issues and installation details. For all DNS server installations, including those in which the use of Active Directory is not an issue, it can be useful to apply the following server placement and planning guidelines.
How many servers should you have?
When determining the number of DNS servers you need to use, assess the effect of zone transfers and DNS query traffic on slower links in your network. Although DNS is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients. You should review this traffic, particularly when implementing DNS in complexly routed LAN or WAN environments. Consider the effects of zone transfer over slower links such as those typically used for a WAN connection. Although the DNS service supports incremental zone transfers, and Windows Server 2003 DNS clients and servers can cache recently used names, traffic can still be an issue particularly when shortened Dynamic Host Configuration Protocol (DHCP) leases result in more frequent dynamic updates in DNS. One option for dealing with remote locations on WAN links is to set up a DNS server at these locations to provide caching-only DNS service. With most installations, you should have at least two server computers hosting each of your DNS zones for fault tolerance. DNS was designed to have two servers for each zone: one as the primary server and the other as a backup or secondary server. Before deciding the number of servers you will use, you should first assess the level of fault tolerance you need for your network.
DNS server placement example
If you have a routed LAN and high-speed links that are fairly reliable, you might be able to use one DNS server for a larger, multiple subnetted network area. If you have a large number of client nodes on a single subnet design, you might want to add more than one DNS server to the subnet to provide backup and failover in case the preferred DNS server stops responding. Note When using only a single server running Windows Server 2003 on a small LAN in a single-subnet environment, you can configure the single server to simulate both the primary and secondary servers for a zone.
Multimedia: Resolving Names with a DNS Server
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objectives The objective of this presentation is to explain the process for resolving names with a DNS server. You will learn how to:

Explain the functionality of a DNS server. Define the process for name resolution using a DNS server. Identify the query types. Explain DNS and WINS integration.
Key questions

What are the two types of queries that a resolver can make to a DNS server? Why was the special zone in-addr.arpa created? What is a pointer (PTR) record? How do forward queries resolve host names? How do reverse queries resolve host names?
DNS Server Roles
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction In your DNS configuration, you may have a number of servers configured differently to perform specific roles within your environment. When planning your server implementation, you need to determine the functionality provided with each server. The following information discusses the different DNS server roles. Caching-only servers perform name resolution on behalf of clients and then cache, or store, the results. Because caching-only servers are not configured to be authoritative for a zone, they do not store standard primary or standard secondary zones. The cache is populated with the most frequently requested names. These names and their associated IP addresses are available from the cache for answering subsequent client queries. Caching-only servers help to reduce traffic across a WAN in the following ways:
Caching-only servers
A caching-only server attempts to locate information in its cache to resolve client requests. If the required information is not found, the caching-only server performs a query across the WAN to locate the necessary information and update its cache. The more information that is stored in its cache, the less likely it is that the caching-only server needs to perform a query, thus reducing traffic across the WAN. A caching-only server does not maintain zone files, as a primary DNS server does. Nor does it store a copy of a zone file, as a secondary DNS server does. Therefore, caching-only servers do not generate zone transfer traffic.
10
When a remote office has a limited amount of available bandwidth for connecting to a corporate office, a caching-only server should be configured at the remote office to send recursive queries to a DNS server at the corporate office. A recursive query is one in which the DNS server assumes the full workload and responsibility for providing a complete answer to the query. The DNS server at the corporate office is better equipped to handle recursive queries because it has a greater amount of available bandwidth for connecting to the Internet or an intranet. Non-recursive servers A non-recursive server is a DNS server on which recursion has been disabled. This prevents the server from using recursion to resolve names on behalf of clients. The server is also prevented from forwarding requests. If a nonrecursive server is unable to resolve a name directly, it returns a negative response to the query. You should disable recursion on Internet-facing DNS servers that are authoritative for one or more zones. This will allow the DNS server to respond to queries from other DNS servers for your zone information but will prevent Internet clients from using your DNS server to resolve other domain names on the Internet. You can also disable recursion if you want to restrict your clients to resolving names internal to your organization. Forward-only servers When a DNS server that is configured to use forwarders cannot resolve a query locally or by using its forwarders, the server attempts to resolve the query by using standard recursion. You can also configure a DNS server to not perform recursion after the forwarders fail. In this configuration, the server does not attempt any further recursive queries to resolve the name. Instead, if the server does not receive a successful query response from any of the servers that are configured as forwarders, it fails the query. A DNS server that is configured in this manner is called a forward-only DNS server. If all forwarders for a name in the query do not respond to a forward-only DNS server, that DNS server does not attempt recursion. Unlike a non-recursive DNS server, a forward-only DNS server builds up a cache relating to the domain name and uses this cache to attempt to resolve host names. You use forwarders to manage the DNS traffic between your network and the Internet by configuring the firewall used by your network to allow only one DNS server to communicate with the Internet.
11
Conditional forwarders
A conditional forwarder is a DNS server that is used to forward DNS queries according to the DNS domain name in the query. The conditional forwarder setting for a DNS server consists of the following elements:

The domain names for which the DNS server will forward queries. One or more DNS server IP addresses for each domain name specified.
A DNS server that is configured to use a forwarder behaves differently than a DNS server that is not configured to use a forwarder. A DNS server configured to use a forwarder behaves as follows:
When the DNS server receives a query, it attempts to resolve this query by using the primary and secondary zones that it hosts and its cache. If the query cannot be resolved by using this local data, the server forwards the query to the DNS server that is designated as a forwarder. The DNS server waits briefly for an answer from the forwarder before attempting to contact the DNS servers that are specified in its root hints. When a DNS server forwards a query to a forwarder, it sends a recursive query to the forwarder. This is different than the iterative query that a DNS server sends to another DNS server during standard name resolution (that is, name resolution that does not involve a forwarder).
In situations in which you want DNS clients in separate networks to resolve each others names without having to query DNS servers on the Internet, you can configure the DNS servers in each network to forward queries for names in the other network. DNS servers in one network will forward names for clients in the other network to a specific DNS server that will build up a large cache of information about the other network. When forwarding in this way, you create a direct point of contact between the two networks DNS servers, reducing the need for recursion.
12
Levels of Securing Microsoft DNS Servers
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction There are three levels of DNS security. You need to determine the appropriate security level for your network based on your organizations needs. The following three levels of DNS security will help you understand your current DNS configuration and enable you to increase your organizations DNS security. Low-level security is a standard DNS deployment without any security precautions configured. You deploy this level of DNS security only in network environments in which there is no concern for the integrity of your DNS data or in a private network in which there is no threat of external connectivity. When you implement low-level security:

Low-level security
Your organizations DNS infrastructure is fully exposed to the Internet. Standard DNS resolution is performed by all DNS servers in your network. All DNS servers are configured with root hints pointing to the root servers for the Internet. All DNS servers permit zone transfers to any server. All DNS servers are configured to listen on all of their IP addresses. Cache pollution prevention is disabled on all DNS servers. Dynamic updating is allowed for all DNS zones. UDP and TCP/IP port 53 is open on your network firewall for both source and destination addresses.

13
Medium-level security
Medium-level security uses the DNS security features that are available without running DNS servers on domain controllers and storing DNS zones in Active Directory. When you implement medium-level security:

Your organizations DNS infrastructure has limited exposure to the Internet. All DNS servers are configured to use forwarders to point to a specific list of internal DNS servers when they cannot resolve names locally. All DNS servers limit zone transfers to servers listed in the name server (NS) resource records in their zones. DNS servers are configured to listen on specified IP addresses. Cache pollution prevention is enabled on all DNS servers. Dynamic updating is not allowed for any DNS zones. Internal DNS servers communicate with external DNS servers through the firewall, allowing only a limited list of source and destination addresses. External DNS servers in front of your firewall are configured with root hints pointing to the root servers for the Internet. All Internet name resolution is performed by using proxy servers and gateways.

High-level security
High-level security uses the same configuration as medium-level security, in addition to the security features that are available when the DNS server service is running on a domain controller and DNS zones are stored in Active Directory. In addition, high-level security completely eliminates DNS communication with the Internet. This is not a typical configuration, but it is recommended whenever Internet connectivity is not required. When you implement high-level security:
Your organizations DNS infrastructure allows no Internet communication with internal DNS servers. Your network uses an internal DNS root and namespace where all authority for DNS zones is internal. DNS servers that are configured with forwarders use internal DNS server IP addresses only. All DNS servers limit zone transfers to specified IP addresses. DNS servers are configured to listen on specified IP addresses. Cache pollution prevention is enabled on all DNS servers. Internal DNS servers are configured with root hints pointing to the internal DNS servers hosting the root zone for your internal namespace. All DNS servers are running on domain controllers. A discretionary access control list (DACL) is configured on the DNS Server service to allow only specific individuals to perform administrative tasks on the DNS server. All DNS zones are stored in Active Directory. A DACL is configured to allow only specific individuals to create, delete, or modify DNS zones.

14

DACLs are configured on DNS resource records to allow only specific individuals to create, delete, or modify DNS data. Secure dynamic updating is configured for DNS zones, except the top-level and root zones, which do not allow dynamic updates at all.
Note For additional information about DNS security threats, see the following topic in the DNS help files: Security Information for DNS.
15
Guidelines for Planning a DNS Server
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Determine server requirements Determine DNS server placement Determine server functionality The following guidelines are recommended for planning a DNS server. Planning and deploying DNS servers on your network involve defining the server capacity that your enterprise requires and determining the DNS server configuration. When determining server placement, you need to determine the number of servers and their placement. This depends on whether you implement Active Directory and the connection speed between offices. Your DNS server can have any of several different functions. You need to determine if you will employ a caching-only solution, a forward-only server, conditional forwarders, or stub zones. Each of the options has unique characteristics and specialized performance. Finally, you need to determine whether to implement high-level, medium-level, or low-level security based on your DNS configuration and organizational needs.
Determine the level of security to implement
16
Practice: Planning DNS Server Security
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objective Instructions In this practice, you will plan and discuss the challenges of securing a DNS server configuration. The objective of this practice is to plan the DNS server security. 1. Read the scenario. 2. Prepare to discuss the challenges of this task in a post-practice discussion. Scenario You are a DNS consultant for Contoso, Ltd, a fast-growing custom automobile parts distributor and manufacturer. The company recently completed a security review by a security consulting firm and was warned that its DNS server was vulnerable to attack because its firewall allowed DNS traffic to and from any server. All of Contoso, Ltds DNS servers were allowed direct Internet communication through the firewall. The DNS design document has been changed to read as follows: The firewall will only allow DNS traffic out to the Internet from the one DNS server on the screened subnet. The only DNS traffic allowed from the intranet will be from the three DNS servers on the corporate network to the DNS server on the screened subnet.
17
Practice
How will you adjust your DNS plan to allow for this new security requirement? Plan to have the three DNS servers configured on the intranet as forwardonly servers. These servers will answer any queries that are authoritative for their own zone data and any queries for data outside their authority will be forwarded to the DNS server on the screened subnet. The intranet servers will not try to answer the queries recursively if the forwarder fails to answer the query. The intranet servers will build up a cache to reduce the amount of traffic sent through the firewall to answer a query. _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ What level of security would you recommend for the Contoso, Ltd DNS servers? Why? Medium-level security. High-level security would be too restrictive because the company needs to communicate with servers on the Internet. Low-level security would leave the company vulnerable to attack, as the security audit revealed. _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________
18
Lesson: Planning a Namespace
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objectives This lesson discusses concepts and required decisions for planning a namespace. After completing this lesson, you will be able to:
Examine an existing network environment for factors that might affect DNS design. Determine the need for Internet access and multiple namespace considerations. Determine namespace design.
19
Multimedia: A Planning DNS Namespace Strategy
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objectives The objective of this presentation is to provide guidelines for planning a DNS namespace. You will learn how to:

Explain how to separate the internal and external namespaces. Apply the guidelines for integrating the Active Directory namespace and DNS namespace. Explain the importance of choosing a unique name for an internal namespace. Decide how the public and private namespaces will be related. Explain the importance of planning a hierarchal namespace.

Key questions
How will you integrate your internal private namespace and your external public namespace? What service must be available before you can create your first Active Directory domain controller? What are your business identity needs? What are your organizations security requirements? What do you need to do to ensure that your private namespace is unique? Why do you need to do to ensure that only one DNS server requires a root hints file?

20
Choosing a Domain Name
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction To appropriately plan a namespace, you must understand what an available domain name is, what naming conventions are, and who has authority for the domains. The Internet Corporation for Assigned Names and Numbers (ICANN) maintains authority for the root and top-level domain names of the Internet DNS namespace. ICANN assigns globally unique identifiers, including Internet domain names, IP address numbers, and protocol parameter and port numbers to organizations. A central authority for this information is necessary because these identifiers must be unique for the Internet to function without duplicate information. Note For more information about ICANN, see http://www.icann.org. Top-level domain names The following table provides information on each of the top-level Internet domains. You need to select the appropriate top-level domain name for your organizations needs.
Top-level name .com .edu Purpose Commercial organizations, such as the Microsoft Corporation Educational organizations, such as Carnegie Mellon University; recently, a decision was made to limit further registrations to four-year colleges and universities United States governmental organizations, such as the White House in Washington, D.C. International organizations, such as the North Atlantic Treaty Organization Example microsoft.com cmu.edu
ICANN
.gov .int
whitehouse.gov nato.int
Module 5: Planning a DNS Strategy (continued) Top-level name .mil .net .org Purpose United States military organizations, such as the U.S. Air Force Networking organizations, including Internet service providers (ISPs) Noncommercial organizations, such as ICANN Example af.mil psi.net ICANN.org
21
Note You can find a complete listing of top-level domains at http://www.icann.org. Obtaining top-level domain names To obtain top-level domains, request them from ICANN or another Internet naming authority. When you receive your domain names, you can connect to the Internet and use DNS servers to manage the mapping of names to IP addresses, and vice versa, for host devices contained within their portion of the namespace. After obtaining a domain name, you may choose to:
Domain options
Name the computers and network devices within the assigned domain and its subdivisions. Delegate subdomains of your domain to other users or customers.
Domain naming conventions
It is strongly recommended that you only use characters in your names that are part of the Internet standard character set permitted for use in DNS host naming. Allowed characters are defined in RFC 1123 as follows: all uppercase letters (AZ), lowercase letters (az), numbers (09), and the hyphen (-). When determining your namespace requirements, you need to decide how you plan to use DNS and your goals. Consider the following when making your decisions:
Determining your namespace requirements
Do you plan to use your namespace for internal purposes only? For an internal namespace, you can implement your own DNS root, use any domain name you want, and use characters outside of the Internet standard as defined in RFC 1123.
Do you plan to use your namespace on the Internet? If you plan to use your namespace on the Internet, or think that you might do so in the future, you should register your own unique domain name by using the Internet root servers and ensure that the name conforms to Internet naming standards.
Do you implement or plan to implement Active Directory? If you implement or plan to implement Active Directory, you need to ensure that the namespace hierarchy effectively represents the entire organization so that it can be used for the Active Directory namespace.
22
Selecting a domain name
You should choose a domain name that is meaningful and represents your entire organization, even if you do not currently plan to use this name externally. This allows you to continue to use the name in the future if you change your plans. It will also enable you to use the namespace for any future Active Directory implementation. After you have chosen a domain name that you would like to use, you need to check if it is unique. To check the uniqueness of a domain name, you can:
Checking a domain name for uniqueness
Use the Registry Whois tool at http://www.internic.net. This site allows you to see if anybody has previously registered a particular domain name. Visit http://www.domainsurfer.com to view a list of all registered domain names that contain the text you want to use in your domain name.
23
DNS Namespace Options
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction There are three options for selecting a DNS namespace: using the existing namespace, a delegated namespace (such as a subdomain), or a new unique namespace. The namespace design you choose is determined by your enterprise needs. It is important to understand that configuring hosts in separate DNS namespaces so that they can locate each other is a complicated task that requires separate devices such as proxy servers. Depending on your business requirements and the existing DNS environment, you can select one of the following options when you design your namespace:
Namespace planning requirements
Use the existing external DNS namespace of the organization as the internal namespace (for example, microsoft.com for both external and internal use). Use a delegated domain of the organizations existing internal DNS namespace as the internal namespace (for example, microsoft.com for external use and corp.microsoft.com for internal use). Use an internal namespace that is different from the existing external DNS namespace (for example, microsoft.com for external use and microsoft.net for internal use). Use a DNS child domain as the organization for the root of Active Directory instead of using the registered DNS domain name. This will allow isolation of all Active Directory data in its domain or domain tree.
Using the existing namespace
You might want to retain a single DNS domain name for both the existing DNS namespace and the internal namespace. However, you need to ensure that the internal namespace is not accessible from the Internet.
24
Guidelines for using an existing DNS namespace
A primary benefit of using an existing namespace is that you do not need to identify and register an internal name. If you decide to use your existing DNS namespace as your internal namespace, consider the following facts and guidelines:
Users can access a single domain name when they access resources both internally and externally. You do not need to register additional names with a DNS name registration authority. Additional administration is required by DNS administrators to ensure that appropriate records are stored on internal and external DNS servers.
Benefits of using a unique namespace
The benefits of a separate public and private namespace include:

Improved security because users and computers outside the organization cannot access the private namespace. Minimal impact on the existing namespace. Minimal effort on the part of the current DNS administrators.

Guidelines for using a unique namespace
You can integrate DNS into an organizations existing namespace by creating separate public and private namespaces. The existing namespace is contained within the public portion of the namespace. The DNS service in Windows Server 2003 would manage the private portion of the namespace. If you decide to use a namespace that is different from the existing DNS namespace, consider the following facts and guidelines:

Resources are easy to manage and secure. Existing DNS server content does not need to be replicated to the DNS servers for the internal namespace. Existing DNS zones and DNS topology can remain unchanged. The internal namespace is not exposed on the Internet. Internal resources are not accessible from the Internet.

Using a delegated namespace
Creating a single subdomain within the namespace is very similar to the strategy of creating separate public and private namespaces. However, in this case you do not divide the namespace into public and private portions, but instead specify that all Windows Server 2003based DNS servers reside beneath a single subdomain within the namespace. For security reasons, it is generally recommended that you enable internal clients to achieve DNS resolution of both internal and external DNS namespaces but not permit external clients to access the internal namespace. The primary benefit of using a delegated namespace is that there is minimal impact on the existing namespace. In addition, this strategy requires minimal effort on the part of the current DNS administrators.
Benefit of using a delegated namespace
25
Guidelines for using a delegated namespace
If you decide to use a delegated namespace as the internal namespace or the Active Directory root, consider the following facts and guidelines:
The contiguous namespace that is used is more easily understood by the administrative staff and users. All internal data is isolated in a domain or domain tree. A separate DNS server is required for the delegated internal domain. The internal namespace can be long.

Important Whatever name you use for your internal namespace, make sure that it is a name that you can and will register with a registrar. You want avoid a situation in which two companies merge and use the same name for their Active Directory namespace.
26
Best Practices for Namespace Planning
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction As with any planning decision, wherever possible, you should follow the established best practices when planning to implement namespaces. These best practices include the use of distinguished names, separation of internal and external namespaces, and the creation of namespaces that are compatible with Active Directory. Following these practices will help to minimize the impact on supporting the namespace. When planning your DNS namespace, it is recommended that you use a set of distinguished names that do not overlap as the basis for your internal and external DNS use. For example, assuming that your organizations parent domain name is microsoft.com, you could do the following:
Use distinguished names Examples
Make the internal domain separate and discontiguous with the external name space, using a name such as microsoft.net (or microsoft.local if you never plan to make the resources available externally). Make the internal domain separate from the external domain but contiguous with it by using a name such as corp.microsoft.com.
Separate internal and external namespaces
Separating your internal and external namespaces makes it simpler to maintain configurations such as a domain name filter or exclusion lists. If you choose to use the same namespace for internal and external resolution, you need to create a split DNS infrastructure to support decision. When planning your namespace, you need to consider whether you are implementing Active Directory now or in the future. If you plan to implement Active Directory, you must ensure that the namespace you select is compatible with an Active Directory namespace.
Create an Active Directorycompatible namespace
27
Guidelines for Planning a Namespace
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Resolving names by using DNS is central to Windows Server 2003 operation. Without proper name resolution, users cannot locate resources on the network. It is critical that you create your DNS namespace with Active Directory in mind and that the larger namespace that exists on the Internet does not conflict with your organizations internal namespace. Consider the following guidelines when planning your namespace. Identify the domain name that your organization has registered for use on the Internet (for example, contoso.com). If your company does not yet have a registered domain name, you might want to register a name on the Internet. If you choose not to register a name, make sure that the name you choose is unique. You can find out the domain names that are already in use at http://www.internic.net. For internal use, you could use a namespace, such as contoso.com, or a subdomain of the external name, such as corp.contoso.com. The subdomain structure can be useful if you already have an existing DNS namespace. To simplify administration, you can assign different locations or organizations different subdomains such as nameone.corp.contoso.com or nametwo.corp.contoso.com.
Select a DNS namespace for your domain
Use different namespaces for internal and external use
28
Maintain namespace separation on internal and external servers
External servers should include only those names that you want to be accessible from the Internet. Internal servers should contain only those names that are intended for internal use. You can set your internal DNS servers to forward requests that they cannot resolve to external servers for resolution. Different types of clients require different kinds of name resolution. For example, Web proxy clients do not require external name resolution because the proxy server resolves external names on their behalf. Overlapping internal and external namespaces are not recommended. In most cases, the end result of this type of configuration is that computers are unable to locate needed resources because of receiving incorrect IP addresses from DNS. This is of particular concern when network address translation (NAT) is involved and the external IP address is in an unreachable range for internal clients. Note Make sure that root servers are not created unintentionally. Root servers can be created by the Active Directory Installation Wizard (DCPromo.exe), resulting in internal clients being able to reach external clients or parent domains. If the . zone exists, a root server has been created. It might be necessary to remove this zone for proper name resolution.
29
Practice: Planning a DNS Namespace
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objective Instructions In this practice, you will plan a DNS namespace that is able to support your organizations existing and future plans. The objective of this practice is to plan a DNS namespace. 1. Read the scenario. 2. Prepare to discuss the challenges of this task in a post-practice discussion. Scenario The consulting company that you work for has assigned you to a new account, Contoso, Ltd to help plan their DNS namespace. Contoso, Ltd is a fast-growing custom automobile parts distributor and manufacturer. The company is quickly outgrowing its Microsoft Windows NT version 4.0 network infrastructure and is in the planning stages for a migration to Windows Server 2003. The company currently has a WINS infrastructure but no DNS infrastructure. Contoso, Ltd currently has a Web presence at http://www.contoso.com, which is hosted by its ISP, which also hosts its DNS, mail, and file transfer protocol (FTP) services. The consulting company that Contoso, Ltd was working with previously had prepared a design document for the upgrade. In this document, you found the following information:
Contoso, Ltd is paying its ISP an exorbitant fee to host its computing services. The company would like to host these services itself after it trains or hires the necessary IT professionals and completes its Windows Server 2003 migration. An Active Directory plan has not begun yet, but after the migration is finished, the company most likely will implement it. Any plans should take this eventuality into account. Client workstations should be able to resolve both intranet and Internet names and to connect to services on both.
30
Practice
Plan the DNS namespace for Contoso, Ltds new computing infrastructure. Describe the steps that you would take to ensure that the namespace meets the technical and business needs now and in the future. A possible answer could be: You could use the existing external namespace. This will be hosted on the companys externally accessible DNS server. An internal DNS server can provide services for the internal namespace. The servers should communicate to resolve external names from the internal clients but not the internal names from external (Internet) clients. Provide several possible names for the internal namespace that would be able to support future technologies, such as Active Directory, which could possibly use the new name as its namespace. For example, you might come up with names such as contoso-corp01.com, contoso.biz, and so on. Check to see that the name candidates are available and can be registered with a registrar. If they are not available, continue thinking of other names and check them for availability. Take a short list of available name candidates to the Contoso, Ltd decision makers and get an approval on the final name, and then register this name with a registrar. ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________
31
Lesson: Planning Zones
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction This lesson presents information that you will need to determine whether to use one or more zones in a DNS strategy. In addition, the lesson discusses required zone configurations. After completing this lesson, you will be able to:

Objectives
Determine zone requirements. Identify zone types. Identify zone security requirements. Specify zone configurations.
32
Selecting Zone Types
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You need to determine the zone types to use in your DNS plan and choose the appropriate storage locations for the zones. The DNS zone types you choose will influence the placement of DNS servers in a name resolution design because each zone type solves a specific requirement within a DNS plan. Standard zone files, also known as traditional DNS zone files, are zone files that are stored as text files on the servers hard drive. To use standard zone files, you create a zone on the DNS server that you plan to use to perform DNS database administration. This server becomes the primary zone server where all updates occur, such as resource record additions or deletions. When you create a DNS server to function as a secondary zone server, you specify the name or the IP address of the primary zone server that will provide a copy of the zone file. You can use secondary zone servers to provide load balancing and a certain degree of fault tolerance. Standard DNS zones store the zone information in a file on a computer running Windows Server 2003 and DNS. Standard DNS zones:
What are standard zone files?
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 and stub zones. Allow zone transfers between primary and secondary or stub zones to occur incrementally or by transferring the entire zone contents. The DNS Server service in Windows Server 2003 supports both incremental and complete zone transfers. Function identically to Berkeley Internet Name Domain (BIND)based DNS servers. Traditional DNS zones have the same benefits and constraints as BINDbased DNS zones. You can use traditional DNS zones if high interoperability with BINDbased DNS servers is a design requirement.
33
What are Active Directoryintegrated zones?
Active Directoryintegrated zones store DNS zone information in Active Directory. Active Directoryintegrated zones are:
Multimaster, read/write copies of the zone information. The multimaster characteristic enables you to make updates to the original Active Directoryintegrated 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 Directoryintegrated zones if your DNS design includes dynamic updates to DNS. Traditional DNS zones are not multimaster, so the failure of a DNS server with a primary zone prevents dynamic updates.
Replicated by Active Directory. Because Active Directoryintegrated zones store the zone information in Active Directory, zone information is replicated along with the other Active Directory data.
Required for secured, dynamically updated DNS zones. Because Active Directoryintegrated zones store the zone information, you establish permissions for the computer, group, or user that can update the DNS zone information.
Replicated according to an administrative selectable scope. You can replicate DNS data to a DNS server within a forest, domain, or specific domain controllers in an Active Directory partition. You can also replicate Active Directoryintegrated zone information to traditional secondary zones outside the domain.
Treated as a traditional primary zone by another BINDbased DNS server. Active Directoryintegrated zones appear as traditional primary zones to a BINDbased DNS server. You can replicate DNS data to other Active Directoryintegrated zones or to traditional secondary zones.
34
DNS zone types
There are three different zone types to choose from in a DNS plan.
Primary Primary zones are read/write copies of zone information. A traditional primary zone is periodically transferred to servers hosting secondary zones to ensure that the secondary zone servers copy of the file is current. With Windows Server 2003 DNS servers, the primary zone server initially transfers a full copy of the zone file and then subsequently sends only changes to the secondary zone server. Active Directoryintegrated primary zone information is replicated by Active Directory to other servers hosting the Active Directoryintegrated zone.
Secondary Secondary zone servers provide only limited fault tolerance because they continue to respond to DNS queries and cannot perform updates because they only have a read-only copy of the zone file. Windows 2000 DNS supports incremental zone transfers (IXFR), which the primary zone server sends only changes that have occurred to the zone file since the last zone transfer. Secondary zone types cannot be stored in Active Directory.
Stub A stub zone is also a read-only copy of a zone. However, a stub zone just contains a subset of the records associated with that zone. It contains information about the name servers that are authoritative for that domain, allowing a client (or other DNS server) to go directly to an authoritative server without having to visit intermediate servers. This can increase the efficiency of the name resolution process across zones across discontiguous namespaces. Information in a stub zone may be transferred if a traditional stub zone is used or replicated by Active Directory if the stub zone is Active Directoryintegrated.
Using stub zones
Stub zones enable a DNS server to perform recursion by using the stub zones list of name servers without needing to query the Internet or internal root server for the DNS namespace. Using stub zones throughout your DNS infrastructure enables you to distribute a list of the authoritative DNS servers for a zone without using secondary zones. However, stub zones do not serve the same purpose as secondary zones and should not be considered when addressing redundancy and load sharing. Important A DNS server configured with a stub zone is not authoritative for that zone. The stub zone identifies DNS servers that are authoritative for the zone.
35
Selecting Zone Data Location
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction When planning your DNS implementation, you need to identify where the DNS zone files will be located. You can store DNS data in standard DNS zones, but in an Active Directory environment, you can choose Active Directory integrated zones or a combination of the two. Because Active Directoryintegrated zones can replicate DNS data to traditional secondary DNS zones, you can use a combination of both zone types. You might want to do this if you have DNS servers from different vendors. Comparison of zone types The following table compares Active Directoryintegrated zones with traditional DNS zones.
Active Directory integrated zones Yes Yes Yes Yes Yes
Features of DNS Adheres to current Internet Engineering Task Force (IETF) specifications. Uses a zone information replication method that is based on Active Directory replication. Improves availability because each DNS server contains a read/write copy of the zone information. Allows updates to the zone information, even with the failure of a single DNS server. Supports incremental zone transfers.
Traditional DNS zones Yes No No No Yes
36
Zone Security Considerations
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction After you have identified the zones and their storage locations, you need to consider how to secure them. You can secure DNS access from private and public networks in several ways. Your security measures will depend on how you have planned your zones. The DNS zone security considerations include:

Secured dynamic updates in Active Directory. Dynamic updates from DHCP. DNS client dynamic updates.
Secured dynamic updates in Active Directory
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 this information by using Active Directory security features. After you integrate a zone with Active Directory, you can use the access control list (ACL) editing features that are available in the DNS console to add or remove users or groups from the ACL for a specified zone or resource record. When planning to secure dynamically updated DNS zones in your plan, consider the permissions:
To update the DNS zone that are made in the DNS zone container within Active Directory. That can be assigned for the entire DNS zone or for individual resource records within the zone. That can be assigned to a computer, group, or user account.
37
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 specify the DNS zone(s) that the DHCP server is responsible for automatically updating. On the DNS server, you specify the DHCP server as the only computer that is authorized to update the DNS entries. If you use multiple Windows Server 2003 DHCP servers on your network and also configure your zones to allow secure dynamic updates only, you need to use Active Directory Users and Computers to add your DHCP servers to the built-in DnsUpdateProxyGroup. This will grant all of your DHCP servers secure rights to perform proxy updates for any of your DHCP clients. You should include dynamic DNS updates from DHCP servers if:
The DNS client operating system is not Windows 2000, Windows XP, or Windows Server 2003. Assigning the permissions that enable each computer, group, or user to update their respective DNS entries becomes unmanageable. Allowing individual DNS clients to update DNS entries presents security risks that could potentially allow unauthorized computers to impersonate authorized computers.
DNS client dynamic updates
DNS clients running Windows 2000, Windows XP, and Windows Server 2003 can directly update DNS automatically. When these clients start, the DNS client can connect to the DNS server and automatically register the DNS client with the DNS server. You should 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 DNS entries is manageable. Allowing individual DNS clients to update DNS entries poses no potential security risks. By default, the Dynamic updates setting is not configured to allow dynamic updates. This is the most secure setting because it prevents an attacker from updating DNS zones, but this setting prevents you from taking advantage of the benefits to administration that dynamic update provides. To have computers securely update DNS data, store DNS zones in Active Directory and use the secure dynamic update feature.
38
Zone permissions
The DACL on the DNS zones that is stored in Active Directory allows you to control the permissions for the Active Directory users and groups that may control the DNS zones. The following table lists the default group or user names and permissions for DNS zones that are stored in Active Directory.
Group or user names Administrators Authenticated Users Creator Owner DnsAdmins Permissions Allow: Read, Write, Create All Child objects, and Special Permissions Allow: Create All Child objects Special Permissions Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, and Special Permissions Allow: Full Control, Read, Write, Create All Child objects, and Delete Child objects Allow: Full Control, Read, Write, Create All Child objects, and Delete Child objects Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, and Special Permissions Allow: Read and Special Permissions Allow: Special Permissions Allow: Full Control, Read, Write, Create All Child objects, and Delete Child objects
Domain Admins
Enterprise Admins
Enterprise Domain Controllers Everyone Pre-Windows 2000 Compatible Access System
39
Guidelines for Planning Zones
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Determining zone type Several guidelines will assist you in planning your zones. You need to determine if you will need a primary, secondary, or stub zone. Your choice depends on whether you are running Active Directory or not. If you are not running Active Directory, you need to determine where the primary server and any secondary servers should be placed. You also need to determine if the zone will be integrated with Active Directory. You need to determine where you will store the zone data: in an Active Directoryintegrated zone, in a traditional zone, or in a combination of the two. When considering integration requirements, you need to determine if the zone will be integrated with the WINS service. This entails determining if you have a heterogeneous mix of hosts that may need to resolve each others names but cannot easily use both DNS and NetBIOS namespaces. You need to determine if your zone security requires secured dynamic updates in Active Directory, dynamic updates from DNS, or DNS client dynamic updates.
Determining zone storage location Determining zone integration requirements
Determining zone security requirements
40
Practice: Planning Zones
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objective Instructions In this practice, you will determine the zone type, zone storage location, and zone security that you will implement based on the provided scenario. The objective of this practice is to plan a DNS zone. 1. Read the scenario. 2. Prepare to discuss the challenges of this task in a post-practice discussion. Scenario You are the systems engineer for Contoso, Ltd, a rapidly growing custom automobile parts distributor and manufacturer. The company is currently planning its DNS zones. You examine the design document and find the following information:
A new branch office is being opened that will have a local Active Directory domain controller. The branch office will have a T1 link back to the main corporate office. There will be two Active Directory domain controllers on the corporate network. The internal namespace (and Active Directory root) will be Contoso-corp01.com.

41
Practice
Describe the zone that you would create for Contoso-corp01.com and what you would specify are the DNS needs for the branch office. Describe the security that your solution provides, and the nature of additional network traffic that your solution makes possible on the link to the corporate network. Create an Active Directoryintegrated zone on the corporate networks DNS servers that will replicate to all DNS servers in the domain. Install DNS on the domain controller in the branch office, which will give you a multimaster solution. This solution provides the ability to specify only secure dynamic updates. Active Directory will encrypt replicated data. DACLs on the DNS zones stored in Active Directory allow you to control permissions for Active Directory users and groups that may control the DNS zones. DNS data will be replicated as part of the Active Directory replication, taking advantage of a replication already in place. Local client queries will be handled locally and will not add traffic to the T1 line. _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________
42
Lesson: Planning Zone Replication and Delegation
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction This lesson discusses the central principles of planning zone replication. These principles include identifying server configurations, zone delegation, and faulttolerance requirements. After completing this lesson, you will be able to:

Objectives
Determine DNS server configuration. Determine if a zone should be delegated to improve performance. Identify fault-tolerance requirements.
43
When to Create a Secondary Zone
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You need to address several considerations when determining the placement of a secondary zone. Although some of these considerations might not apply to your particular environment, you will need to plan for a zone transfer and a zone replication. Adding DNS servers provides zone redundancy, enabling the resolution of DNS names in the zone for clients if a primary server for the zone stops responding. The more servers you have that are authoritative for a particular zone, the less likely it is that queries will go unanswered for resources in that zone. Carefully planned placement of additional DNS servers can significantly reduce DNS network traffic. For example, adding a DNS server to the opposite side of a low-speed WAN link can be useful in managing and reducing network traffic. If you place servers close to large client populations or close to isolated networks, you can reduce the amount of query traffic that has to flow across potentially costly and slow WAN links. You can use additional secondary servers to reduce loads on a primary server for a zone. For example, you can direct clients to secondary servers that service queries from local clients only, not clients from across the entire enterprise. Zone replication and zone transfers occur when you implement a secondary server. For security reasons, you should only allow zone transfers with hosts that you specifically configure.
Provide zone redundancy
Reduce network traffic
Reduces loads on primary server Zone transfer and replication requirements
44
Zone Transfers and Replication
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Because of the essential role that zones play in DNS, it is important that they be available from more than one DNS server on the network to provide availability and fault tolerance when resolving name queries. Your implementation of DNS zones determine if you will use zone transfer or replication. Zone transfers occur in a traditional DNS zone. Zone replication occurs in an Active Directoryintegrated zone. Zone transfers are always initiated at a zones secondary server and then sent to the configured master servers that act as their zones source. Master servers can be any other DNS server that loads the zone, such as the primary server for the zone or another secondary server. When the master server receives the request for the zone, it can reply with either a partial or full transfer of the zone to the secondary server. In earlier DNS implementations, any request for an update of zone data required a full transfer of the entire zone database. In current DNS implementations, an incremental transfer allows the secondary server to pull only those zone changes it needs to synchronize its copy of the zone with its source, which is either a primary or secondary copy of the zone maintained by another DNS server. When incremental transfers are supported by both a DNS server acting as the source for a zone and any servers that copy the zone from it, it provides a more efficient method of propagating zone changes and updates. Because the incremental transfer process requires substantially less network traffic, zone transfers are completed much more quickly.
Zone transfers for traditional DNS zones
45
Replication for Active Directoryintegrated zones
Active Directory replication provides an advantage over standard DNS replication. With standard DNS replication, only the primary server for a zone can modify the zone. With Active Directory replication, all domain controllers for the domain can modify the zone and then replicate the changes to other domain controllers. This replication process is known as multimaster replication because multiple domain controllers, or masters, can update the zone. Replication processing is performed on a per-property basis, which means that only relevant changes are propagated. Replication processing differs from DNS full zone transfers, in which the entire zone is propagated. Replication processing also differs from incremental zone transfers, in which the server transfers all changes made since the last change. With Active Directory replication, however, only the final result of all changes to a record is sent. The DNS zones that are used to support an Active Directory domain are stored in the domain or application directory partitions of the Active Directory.
46
Zone Transfer Security Measures
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction After you have identified the replication process that you will use, you must secure the zone transfers. You can secure your zone transfers in several different ways. By default, the Windows Server 2003 DNS Server service only allows zone information to be transferred to servers listed in a zones NS resource records. Although this is a secure configuration, for increased security you should change this setting to allow zone transfers to specified IP addresses. Your network security specialists still need to protect your network against IP spoofing, in case an attacker attempts to impersonate one of your specified IP addresses. Be aware that changing this setting to allow zone transfers to any server might expose your DNS data to an attacker who is attempting to footprint your network. With the increasing use of virtual private networks (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 IP Security (IPSec), VPN tunnels, or Active Directory. For your security, you need to encrypt all replication traffic that is sent over public networks. If you encrypt replication traffic by using IPSec or VPN tunnels, you should consider using:

Restricting zone transfers
Zone replication security
Encryption using IPSec and VPN tunnels
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.
47
Encryption and authentication using Active Directory
You can protect replication traffic by using Active Directoryintegrated zones. Because these zones are based on Active Directory, they provide inherent security by:
Exclusively replicating between DNS servers that have Active Directory integrated zones. Requiring all DNS servers that have Active Directoryintegrated zones to be registered with Active Directory. Encrypting all replication traffic between DNS servers.
Reducing the impact of replication
You can reduce the impact of DNS replication traffic on overused network segments to improve 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. Note that older versions of BIND do not 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. The Windows NT 4.0 DNS service performs only complete zone transfers.
48
Zone Delegation
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Defining zone delegation After you have created multiple zones in your DNS database, you might want to consider delegating the zones. In the context of DNS, delegation is the process of assigning responsibility for a portion of a DNS namespace to a separate entity. This entity could be another organization, department, or workgroup within your enterprise. In technical terms, delegation means assigning authority over portions of your DNS namespace to other zones. The NS resource record that specifies the delegated zone and DNS name of the server that is authoritative for that zone represents such delegation. The following are the main reasons for the delegation of zones:
Why delegate zones?
A need to delegate management of a DNS domain to a number of organizations or departments within your enterprise. A need to distribute the load of maintaining one large DNS database among multiple name servers to improve the name resolution performance and create a DNS fault-tolerant environment. A need to extend the namespace by adding numerous subdomains at the same time: for example, to accommodate the opening of a new branch office or site.
The NS resource records facilitate delegation by identifying DNS servers for each zone. These records appear in all forward and reverse lookup zones. Whenever a DNS server needs to resolve a name in a delegated zone, it will refer to the NS resource records for DNS servers in the target zone. Note If multiple NS records exist for a delegated zone that identify multiple DNS servers that are available for querying, the Windows Server 2003 DNS server is able to select the closest DNS server based on the round-trip intervals measured over a period of time for every DNS server.
49
Delegation records across zones
When delegating zones within your namespace, be aware that for each new zone that you create, you need delegation records in other zones that point to the authoritative DNS servers for the new zone. This is necessary both to transfer authority and to provide correct references to other DNS servers and clients of the new servers being made authoritative for the new zone. Note When zone delegations are correctly configured, normal zone referral behavior can sometimes be circumvented if you are using a forwarders list in your DNS server configuration.
50
Guidelines for Planning Zone Replication and Delegation
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Identify when to create additional zones The following are the recommended guidelines for planning zone replication and delegation. You may have the need for additional secondary zones. There are two primary reasons why you would create an additional zone; they are:

To achieve zone redundancy. To reduce network traffic and the load on the primary server.
Determine replication methodology Determine replication security requirements Determine the need for delegating a zone
If you use Active Directory, you must use zone replication. If you use the traditional DNS zone structure, you must use zone transfers. You can use a variety of methods to implement security. Your choice of which method to employ depends on your replication requirements of your environment. You need to determine if you will need to delegate the management of one or more of your zones. Reasons to do so include extending the namespace, distributing the load among several servers, and delegating zone management to another individual or group.
51
Practice: Planning Zone Replication and Delegation
. *****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objective Instructions In this practice, you will plan the zone replication and delegation for a newly acquired company. The objective of this practice is to plan zone replication and delegation. 1. Read the scenario. 2. Prepare to discuss the challenges of this task in a post-practice discussion. Scenario You are a systems engineer for Contoso, Ltd, a rapidly growing custom automobile parts distributor and manufacturer that has recently acquired a research and development firm, Fabrikam, Inc. Fabrikam, Inc. has five BIND version 8.3.3 departmental DNS servers in its primarily UNIX network environment. Contoso, Ltd plans to place a Windows Server 2003 domain controller with DNS installed in the Fabrikam, Inc. environment and establish a VPN between the two companies to share data and begin merging the two data infrastructures. There will be a large number of file shares on the Windows Server 2003 computer, and client/server traffic between the two companies will steadily increase. Fabrikam, Inc. wants to reduce the DNS load on the Windows Server 2003 server by using the existing BIND servers.
52
Practice
How can you use the BIND servers to reduce the load on the Windows Server 2003 server for queries for names in the Contoso, Ltd zone? You can create secondary zones on the BIND servers to allow each of the departmental DNS servers to resolve names in the Contoso, Ltd zone. ________________________________________________________________ ________________________________________________________________ What should you do to allow zone transfers between the Windows Server 2003 DNS server and the departmental BIND servers? The IP address of each of the BIND secondary servers should be specified to allow for zone transfer with the Windows Server 2003 DNS server. ________________________________________________________________ ________________________________________________________________ In the future, Fabrikam, Inc. might adopt the Contoso, Ltd name. What can you do with the Fabrikam, Inc. namespace to allow Fabrikam, Inc. to maintain some degree of autonomy over the DNS data in its organization? A Fabrikam, Inc. subdomain can be created in the Contoso, Ltd zone and delegated to the Fabrikam, Inc. DNS servers so that Fabrikam, Inc. can administer its own zone information. ________________________________________________________________ ________________________________________________________________
53
Lesson: Integrating DNS and WINS
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Enabling objectives This lesson discusses the integration of DNS and WINS in an environment that uses NetBIOS and host name resolution. After completing this lesson, you will be able to:
Determine when to configure DNS servers to use WINS for host name resolution. Explain how to designate a subdomain for WINS resolution.
54
Multimedia: Integrating DNS and WINS
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objectives The objective of this presentation is to explain the name resolution process when a DNS zone is configured for WINS forward lookup. You will learn how to:

Explain how a DNS server can use WINS to resolve host names. Explain why the authoritative DNS server requires WINS records.
Key questions

Can a DNS server resolve NetBIOS names? Which DNS server needs to be configured for WINS lookup?
55
WINS Integration
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction The DNS Server service provides you the ability to use WINS servers to look up names not found in the DNS domain namespace by checking the NetBIOS namespace managed by WINS. Two special resource record types, the WINS and WINS-R records, are used to integrate DNS and WINS. A typical reason to use this feature would be in a heterogeneous computing environment in which you have hosts that do not have the ability to query and register with WINS themselves (for example, a UNIX host) combined with hosts that can only dynamically register NetBIOS names with WINS (for example, Windows NT 4.0 or Windows 95 hosts). Using WINS integration, the UNIX hosts would be able to resolve the Windows hosts names by using DNS. You use a WINS forward lookup resource record to provide further resolution of DNS queries for names that were not found in a zone by using a name query to WINS servers configured and listed with this record. If used, the WINS record applies only to the topmost level within a zone and not for subdomains used in the zone.
WINS resource records
56
The following table describes the various fields that are used with the WINS resource record.
Field Owner Description Indicates the owner domain for this record. This field should always be set to @ to indicate that the current domain is the same as the zone origin. Indicates the class for this record. This field should always be set to IN because the Internet class is the only supported class for DNS servers running Windows Server 2003. Indicates that the WINS resource record is only to be used locally at the DNS server and is not to be included during zone replication with other DNS servers. This field corresponds to the Do not replicate this record check box that is selected or cleared during the process of configuring WINS lookup in the DNS console. If the check box was cleared, this field will not be included when the record is written to the zone. Is the timeout value that is applied for this record. Is the cache timeout value that is applied for this record. Is used to specify one or more IP addresses of WINS servers. At least one IP address of a valid WINS server is required.
Class
Local
lookup_timeout Cache_timeout Wins_ip_addresses
Syntax Examples
owner class WINS [LOCAL] [Lookup_timeout] [Cache_timeout] wins_ip _addresses

@ IN WINS 10.0.0.1
@ IN WINS LOCAL L1 C10 10.10.10.1 10.10.10.2 10.10.10.3
Note In the provided WINS resource record examples, the zone root is assumed to be the current origin. WINS-R resource records You use a WINS-R resource record in a reverse lookup zone to provide further resolution for reverse queries that were not found in the zone. When using this record, you need to specify the parent domain to be appended to a NetBIOS computer name when a successful reverse lookup occurs. Other fields used in the WINS-R resource record have a similar description and purpose, as previously described for their use in the WINS forward lookup record. WINS-R resource record syntax owner class WINS [LOCAL] [Lookup_timeout] [Cache_timeout] Domain _to_append_to_returned_NetBIOS_names
57
WINS-R resource record examples
@ IN @ IN
WINS-R LOCAL L1 C10 example.microsoft.com. WINS-R wins.example.microsoft.com.
Note In the provided WINS-R resource record examples, the zone root is assumed to be the current origin. WINS reverse lookup Because the WINS database is not indexed by IP address, the DNS service cannot send a reverse name lookup to the WINS service to get the name of a computer based on its IP address. The DNS service instead sends a node adapter status request directly to the IP address implied in the DNS reverse query. When the DNS server gets the NetBIOS name from the node status response, it appends the DNS domain name back onto the NetBIOS name provided in the node status response and forwards the result to the requesting client.
58
Modifying Cache Timeout Settings
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction DNS servers cache all information they receive for a time period specified in the returned data. This amount of time is referred to as the Time to Live (TTL). As the name server administrator of the zone, you decide the length of the TTL for the data. Smaller TTL values will help to ensure that data about your domain is more consistent across the network, if this data changes often. However, you should be aware that this will also increase the load on your name server. Cache timeout settings indicate to a DNS server how long it should cache any of the information returned in a WINS lookup. By default, this value is set to 15 minutes. After a DNS server caches the data, it must start decreasing the length of the TTL from its original value so that it knows when to flush the data from its cache. If a query arrives that can be satisfied by this cached data, the TTL that is returned with the data is the current amount of time left before the data is flushed from the DNS server cache. Client resolvers also have data caches and honor the TTL value so that they know when the data should expire. You configure the Cache timeout parameter by using the Advanced button in the Zone Properties dialog box when you configure the zone. This button appears on either the WINS or WINSR tab, depending on whether the zone you are configuring is being used for forward or reverse lookup.
Cache timeout settings
59
Why change cache timeout settings?
If you are using either a WINS or WINS Reverse Lookup resource record, be aware that the minimum TTL set in the start of authority record for the zone is not the default TTL used with these records. Instead, when either an IP address or a host name gets resolved with WINS lookup, the information is cached on the DNS server for the amount of time configured for the WINS cache timeout value. If this address is subsequently forwarded to another DNS server, it will be sent with the WINS cache timeout value TTL. If you have data in WINS that rarely changes, you might be able to lengthen the amount time this data is cached to more than the default 15 minutes. This reduces the number of queries between a DNS server and a WINS server because the DNS server is able to answer queries out of its cache more often.
60
WINS Integration Best Practices
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You can allow DNS clients to resolve host names found in the WINS service. This eliminates the need to create DNS zone entries for all of the computers in your organization. You can resolve host names found in the WINS service by forwarding unresolved DNS queries to a WINS server. You can establish the forwarding of these queries on a zone-by-zone basis. To integrate a WINS resolution into your DNS design, you designate a subdomain within the organizations namespace that you will use as a placeholder for the WINS names. You need to specify that the subdomain contains no entries except for the WINS and WINS-R resource records. For organizations that have separate private and public namespaces, you create the subdomain for WINS under the private namespace. For organizations that have the same namespace for private and public name resolution, you create the subdomain for WINS at a level beneath the root of the organization. Delegate unresolved DNS queries to a subdomain For domain names that are within the organizations namespace, if you want to:
Designate a subdomain for WINS resolution
Resolve names within the WINS service 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 resolving them within WINS, specify that the DNS queries be forwarded to a delegated subdomain for WINS last.
61
Specify 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 addresses of the WINS servers in the order in which the servers are to be contacted. To improve the availability of your DNS solution, you should include more than one WINS server in the list. Your organization might not replicate all WINS records among all of its WINS servers. If the WINS database is shared among multiple WINS servers, you can create a unique DNS zone for each WINS server.
Integration example
For example, consider an organization that has one WINS server that includes WINS records for Paris only and another WINS server that includes WINS records for London only. You can create separate DNS zones for Paris and London so that you can create different subdomain names for the Paris and London WINS servers. Conversely, you can create one DNS zone that lists both WINS servers so that the WINS resolution occurs beneath a single subdomain name.
62
Lab A: Planning a DNS Strategy
*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Objective Scenario In this lab, you will plan a DNS strategy. After completing this lab, you will be able to plan the configuration of DNS servers to support an internal and external namespace. You are a systems engineer for Northwind Traders. You have been asked to plan the configuration of DNS servers for the public Web presence and the internal namespace used in the corporate offices. Northwind Traders maintains eight separate Web servers that are used for Internet-based access by customers. The Web servers are configured as:
Two Network Load Balancing clusters of three servers, each supporting http://www.nwtraders.com by using round-robin DNS records. A single Network Load Balancing cluster of two servers supporting b2b.nwtraders.com.
The internal namespace, corp.nwtraders.com, uses Active Directoryintegrated zones configured on the domain controllers. The external public namespaces are hosted on geographically dispersed BIND based DNS servers provided by an ISP for improved reliability.
63
Estimated time to complete this lab: 60 minutes
64
Exercise 1 Planning DNS Configuration for Internal and External Namespaces

Introduction
In this exercise, you will plan the configuration of the DNS servers. The provided design document shows the placement of the DNS servers in the internal network and the screened subnet used for the public Web servers. Because your configuration suggestions require approval by the corporate network services group before implementation, you must document your suggestions adequately.
Scenario
The original design document specifies the following DNS-related requirements:
The public namespace must be maintained internally so that the IP addresses of public servers can be changed. There should be no requirement to contact the ISP to update the public namespace records. All DNS requests originating from clients on the private network should use a single path for resolution of external Internet names. Internal DNS servers must not be accessible from the Internet and must make no requests to the Internet.
Tasks
1.
Special instructions
Describe and/or create a diagram of the DNS infrastructure configuration that meets the requirements specified in the design document. Describe any other configuration settings that you would make to ensure the best security and performance of the DNS infrastructure.
Make sure that you draw or describe how the DNS server should be configured, including primary/secondary zones, delegated zones, stub zones, and forwarders.
2.

Module 5: Planning A DNS Strategy

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Module 5: Planning A DNS Strategy

Caricato da

Copyright:

Formati disponibili

Module 5: Planning a DNS Strategy