Module 5: Planning a DNS Strategy

Transcription

1 Module 5: Planning a DNS Strategy 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

2 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, addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, 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 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.

3 Module 5: Planning a DNS Strategy 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.

4 iv Module 5: Planning a DNS Strategy 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 How To pages Guidelines pages Practices Labs Lesson: Planning DNS Servers Overview Determining DNS Server Placement 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. 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.

5 Module 5: Planning a DNS Strategy v 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 DNS Namespace Options Lesson: Planning Zones Selecting Zone Types Selecting Zone Data Location 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. 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 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 When to Create a Secondary Zone Zone 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 Overview Modifying Cache Timeout Settings 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.

6 vi Module 5: Planning a DNS Strategy Lab A: Planning a DNS Strategy Customization Information 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. 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 Lab Results There are no lab setup requirements that affect replication or customization. There are no configuration changes on student computers that affect replication or customization.

7 Module 5: Planning a DNS Strategy 1 Overview 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.

8 2 Module 5: Planning a DNS Strategy Lesson: Planning DNS Servers 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.

9 Multimedia: How DNS Clients Resolve Names Module 5: Planning a DNS Strategy 3 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?

10 4 Module 5: Planning a DNS Strategy Determining DNS Server Requirements 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.

11 Module 5: Planning a DNS Strategy 5 Planning server capacity DNS server system requirements 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. Important The preceding recommendations are not intended to indicate the maximum performance or limitations for DNS servers that are running Windows Server 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.

12 6 Module 5: Planning a DNS Strategy Determining DNS Server Placement DNS server placement 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.

13 Module 5: Planning a DNS Strategy 7 How many servers should you have? DNS server placement example 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. 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.

14 8 Module 5: Planning a DNS Strategy Multimedia: Resolving Names with a DNS Server 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 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?

15 Module 5: Planning a DNS Strategy 9 DNS Server Roles Caching-only servers 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.

16 10 Module 5: Planning a DNS Strategy 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 Forward-only 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. 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.

17 Module 5: Planning a DNS Strategy 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.

18 12 Module 5: Planning a DNS Strategy Levels of Securing Microsoft DNS Servers Low-level security 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.

19 Module 5: Planning a DNS Strategy 13 Medium-level security High-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 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.

20 14 Module 5: Planning a DNS Strategy 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.

21 Module 5: Planning a DNS Strategy 15 Guidelines for Planning a DNS Server Determine server requirements Determine DNS server placement Determine server functionality Determine the level of security to implement 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.

22 16 Module 5: Planning a DNS Strategy Practice: Planning DNS Server Security Objective Instructions Scenario 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.

23 Module 5: Planning a DNS Strategy 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.

24 18 Module 5: Planning a DNS Strategy Lesson: Planning a Namespace 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.

25 Module 5: Planning a DNS Strategy 19 Multimedia: A Planning DNS Namespace Strategy 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 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?

26 20 Module 5: Planning a DNS Strategy Choosing a Domain Name ICANN 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 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 organization s needs. Top-level name Purpose Example.com.edu.gov.int 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 microsoft.com cmu.edu whitehouse.gov nato.int

27 Module 5: Planning a DNS Strategy 21 (continued) Top-level name Purpose Example.mil.net.org United States military organizations, such as the U.S. Air Force Networking organizations, including Internet service providers (ISPs) Noncommercial organizations, such as ICANN af.mil psi.net ICANN.org Note You can find a complete listing of top-level domains at Obtaining top-level domain names Domain options Domain naming conventions Determining your namespace requirements 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 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.

28 22 Module 5: Planning a DNS Strategy Selecting a domain name Checking a domain name for uniqueness 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 This site allows you to see if anybody has previously registered a particular domain name. Visit to view a list of all registered domain names that contain the text you want to use in your domain name.

29 Module 5: Planning a DNS Strategy 23 DNS Namespace Options Namespace planning requirements Using the existing namespace 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.

30 24 Module 5: Planning a DNS Strategy 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 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.

31 Module 5: Planning a DNS Strategy 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.

32 26 Module 5: Planning a DNS Strategy Best Practices for Namespace Planning Use distinguished names Examples Separate internal and external namespaces Create an Active Directory compatible namespace 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 (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. 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.

33 Module 5: Planning a DNS Strategy 27 Guidelines for Planning a Namespace Select a DNS namespace for your domain Use different namespaces for internal and external 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 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.

34 28 Module 5: Planning a DNS Strategy 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.

35 Module 5: Planning a DNS Strategy 29 Practice: Planning a DNS Namespace Objective Instructions Scenario 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 The company currently has a WINS infrastructure but no DNS infrastructure. Contoso, Ltd currently has a Web presence at 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.

36 30 Module 5: Planning a DNS Strategy Practice 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.