Contents
Overview 1
Lesson: Planning DNS Servers 2
Multimedia: How DNS Clients Resolve
Names 3 Multimedia: Resolving Names with a DNS
Server 8
Lesson: Planning a Namespace 18
Multimedia: A Planning DNS Namespace
Strategy 19
Lesson: Planning Zones 31
Lesson: Planning Zone Replication and
Delegation 42 Lesson: Integrating DNS and WINS 53
Multimedia: Integrating DNS and WINS 54 Lab A: Planning a DNS Strategy 62
Module 5: Planning a
DNS Strategy
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.
Instructor Notes
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.
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
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. 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.
Presentation: 2 hours, 30 minutes Lab: 60 minutes Required materials Important Preparation tasks
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.
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.
Lesson: Planning DNS Servers
This section describes the instructional methods for teaching this lesson. 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.
How To pages Guidelines pages Practices Labs Overview Determining DNS Server Placement
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. 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. 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.
Lesson: Planning Zone Replication and Delegation
This section describes the instructional methods for teaching this lesson. Emphasize that in an exclusive Active Directory environment, if the students use Active Directory–integrated 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. 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.”
DNS Server Roles Levels of Securing Microsoft DNS Servers
DNS Namespace Options
Selecting Zone Types
Selecting Zone Data Location When to Create a Secondary Zone Zone Delegation Overview Modifying Cache Timeout Settings
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****************************** 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.
Introduction Module objectives
Lesson:
Planning DNS Servers
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
Introduction Enabling objectives
Multimedia: How DNS Clients Resolve Names
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
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?
Introduction Objectives
Determining DNS Server Requirements
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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 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 server’s connected subnets.
Define the total number of client DNS query requests that a DNS server is expected to receive and service.
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 server–related 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.
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.
Planning server capacity
DNS server system requirements
Determining DNS Server Placement
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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:
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.
Introduction
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. 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.
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.
How many servers should you have?
DNS server placement example
Multimedia: Resolving Names with a DNS Server
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
When viewing this presentation, you should consider the following 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?
Introduction Objectives
DNS Server Roles
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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:
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.
Introduction
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.
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 non-recursive 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.
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.
Non-recursive servers
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.
Levels of Securing Microsoft DNS Servers
*****************************ILLEGAL FOR NON-TRAINER USE****************************** There are three levels of DNS security. You need to determine the appropriate security level for your network based on your organization’s needs. The following three levels of DNS security will help you understand your current DNS configuration and enable you to increase your organization’s 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:
Your organization’s 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.
Introduction
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 organization’s 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 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 organization’s 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.
Medium-level security
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.
For additional information about DNS security threats, see the following topic in the DNS help files: “Security Information for DNS.”
Guidelines for Planning a DNS Server
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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. Introduction Determine server requirements Determine DNS server placement Determine server functionality
Determine the level of security to implement
Practice: Planning DNS Server Security
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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. 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, Ltd’s 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.
Introduction Objective Instructions
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 forward-only 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. _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ Practice
Lesson:
Planning a Namespace
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
Introduction Objectives
Multimedia: A Planning DNS Namespace Strategy
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
When viewing this presentation, you should consider the following 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 organization’s 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?
Introduction Objectives
Choosing a Domain Name
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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.
For more information about ICANN, see http://www.icann.org. 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 organization’s needs.
Top-level name Purpose Example
.com Commercial organizations, such as the Microsoft Corporation
microsoft.com .edu Educational organizations, such as Carnegie
Mellon University; recently, a decision was made to limit further registrations to four-year colleges and universities
cmu.edu
.gov United States governmental organizations, such as the White House in Washington, D.C.
whitehouse.gov .int International organizations, such as the North
Atlantic Treaty Organization
nato.int Introduction
ICANN
Note Top-level domain names
(continued)
Top-level name Purpose Example
.mil United States military organizations, such as the U.S. Air Force
af.mil .net Networking organizations, including Internet
service providers (ISPs)
psi.net .org Noncommercial organizations, such as
ICANN
ICANN.org
You can find a complete listing of top-level domains at http://www.icann.org.
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:
Name the computers and network devices within the assigned domain and its subdivisions.
Delegate subdomains of your domain to other users or customers.
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 (A–Z), lowercase letters (a–z), numbers (0–9), 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:
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.
Note Obtaining top-level domain names Domain options Domain naming conventions Determining your namespace requirements
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: 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.
Selecting a domain name
Checking a domain name for uniqueness
DNS Namespace Options
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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: 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 organization’s 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.
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.
Introduction
Namespace planning requirements
Using the existing 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. 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.
You can integrate DNS into an organization’s 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.
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 2003–based 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.
Guidelines for using an existing DNS
namespace
Benefits of using a unique namespace
Guidelines for using a unique namespace
Using a delegated namespace
Benefit of 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.
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.
Guidelines for using a delegated namespace
Best Practices for Namespace Planning
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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 organization’s parent domain name is microsoft.com, you could do the following:
Make the internal domain separate and discontiguous with the external name space, using a name such as microsoft.net(ormicrosoft.localif 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.
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.
Introduction
Use distinguished names
Examples
Separate internal and external namespaces
Create an Active Directory–compatible namespace
Guidelines for Planning a Namespace
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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 organization’s 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.
Introduction
Select a DNS namespace for your domain
Use different
namespaces for internal and external use
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.
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.
Maintain namespace separation on internal and external servers
Practice: Planning a DNS Namespace
*****************************ILLEGAL FOR NON-TRAINER USE****************************** In this practice, you will plan a DNS namespace that is able to support your organization’s 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. 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.
Introduction Objective Instructions
Plan the DNS namespace for Contoso, Ltd’s 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 company’s 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. ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Practice
Lesson: Planning Zones
*****************************ILLEGAL FOR NON-TRAINER USE******************************
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: Determine zone requirements.
Identify zone types.
Identify zone security requirements. Specify zone configurations.
Introduction
Selecting Zone Types
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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 server’s 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:
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 BIND–based DNS zones. You can use traditional DNS zones if high interoperability with BIND–based DNS servers is a design requirement.
Introduction
What are standard zone files?
Active Directory–integrated zones store DNS zone information in Active Directory. Active Directory–integrated zones are:
Multimaster, read/write copies of the zone information.
The multimaster characteristic enables you to make updates to the original Active Directory–integrated zone or make replicated copies of the zone. It ensures that you can always perform updates to the DNS zone information. As a best practice, select Active Directory–integrated zones if your DNS design includes dynamic updates to DNS. Traditional DNS zones are not multimaster, so the failure of a DNS server with a primary zone prevents dynamic updates.
Replicated by Active Directory.
Because Active Directory–integrated zones store the zone information in Active Directory, zone information is replicated along with the other Active Directory data.
Required for secured, dynamically updated DNS zones.
Because Active Directory–integrated 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 Directory–integrated zone information to traditional secondary zones outside the domain.
Treated as a traditional primary zone by another BIND–based DNS server. Active Directory–integrated zones appear as traditional primary zones to a BIND–based DNS server. You can replicate DNS data to other Active Directory–integrated zones or to traditional secondary zones.
What are Active Directory–integrated zones?
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 server’s 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 Directory–integrated primary zone information is replicated by Active Directory to other servers hosting the Active Directory–integrated 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 Directory–integrated.
Stub zones enable a DNS server to perform recursion by using the stub zone’s 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.
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.
DNS zone types
Using stub zones
Selecting Zone Data Location
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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 Directory–integrated 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.
The following table compares Active Directory–integrated zones with traditional DNS zones. Features of DNS Active Directory– integrated zones Traditional DNS zones
Adheres to current Internet Engineering Task Force (IETF) specifications.
Yes Yes Uses a zone information replication method that is
based on Active Directory replication.
Yes No Improves availability because each DNS server
contains a read/write copy of the zone information.
Yes No Allows updates to the zone information, even with
the failure of a single DNS server.
Yes No Supports incremental zone transfers. Yes Yes
Introduction
Comparison of zone types
Zone Security Considerations
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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 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.
Introduction
Secured dynamic updates in Active Directory
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 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.
Dynamic DNS updates from DHCP
DNS client dynamic updates
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 Permissions
Administrators Allow: Read, Write, Create All Child objects, and Special Permissions Authenticated Users Allow: Create All Child objects Creator Owner Special Permissions
DnsAdmins
Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, and Special Permissions
Domain Admins
Allow: Full Control, Read, Write, Create All Child objects, and Delete Child objects
Enterprise Admins
Allow: Full Control, Read, Write, Create All Child objects, and Delete Child objects
Enterprise Domain Controllers
Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, and Special Permissions
Everyone Allow: Read and Special Permissions Pre-Windows 2000 Compatible Access Allow: Special Permissions
System
Allow: Full Control, Read, Write, Create All Child objects, and Delete Child objects
Guidelines for Planning Zones
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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
Directory–integrated 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.
Introduction
Determining zone type
Determining zone storage location Determining zone integration requirements Determining zone security requirements
Practice: Planning Zones
*****************************ILLEGAL FOR NON-TRAINER USE****************************** 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. 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.
Introduction Objective Instructions
