Module 8: Designing a Name Resolution Strategy

Contents Overview Lesson: Gathering Data for a Name Resolution Strategy Lesson: Designing a DNS Strategy for Interoperability Lesson: Designing a WINS Replication Strategy Lesson: Designing a Name Resolution Strategy for Clients Lab A: Designing a Name Resolution Strategy 1 2 9 18 24 30

Information in this document, including URLs 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, Windows Server, Active Directory, BackOffice, Microsoft Press, MSDN, PowerPoint, Visio, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Module 8: Designing a Name Resolution Strategy

iii

Instructor Notes
Presentation: 120 minutes Lab: 60 minutes This module provides students with the knowledge and skills needed to design a name resolution strategy. The module begins by describing how to gather the information needed to design a name resolution strategy. Then the module explains how to design a DNS strategy for interoperability with Microsoft Active Directory directory service, BIND, WINS, and DHCP. Finally, the module discusses how to design a WINS replication strategy and a name resolution strategy for client computers. After completing this module, students will be able to:
! !

Determine the information needed to design a name resolution strategy. Design a strategy for interoperability with Active Directory, BIND, WINS, and DHCP. Design a WINS replication strategy. Design a name resolution strategy for clients.

! !

Required materials

To teach this module, you need Microsoft PowerPoint file 2282A_08.ppt. 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 features of the slides might not be displayed correctly.

Preparation tasks

To prepare for this module:

! !

Read all of the materials for this module. Complete the practices and review the assessment questions. Whenever possible, anticipate alternative answers that students might suggest and prepare responses to those answers. Complete the lab, practice discussing the answers, and become familiar with the lab environment. Read the additional reading for this module, located under Additional Reading on the Web page on the Student Materials compact disc. Document your own suggested additional readings to share with the class. Visit the Web links that are referenced in this module.

Classroom setup

The information in this section provides setup instructions that are required to prepare the instructor computer or classroom configuration for a lab. The computers in the classroom should be set up in the configuration specified in the Customization Information section at the end of the Automated Classroom Setup Guide for Course 2282A, Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure. No additional classroom setup is required to perform the lab in this module.

iv

Module 8: Designing a Name Resolution Strategy

How to Teach This Module

This section contains information that will help you to teach this module.

Lesson: Gathering Data for a Name Resolution Strategy

This section describes the instructional methods for teaching this lesson. In this lesson, students learn the types of relevant information that must be gathered in order to design an effective name resolution strategy. The lesson explores several elements that influence name resolution design decisions, including the existing network name resolution configuration, physical locations of the organization, host requirements, and NetBIOS resources. Existing Name Resolution Configuration Physical Locations When discussing the existing DNS infrastructure, consider asking students this question: If youre running Active Directory on a network, do you have an existing DNS infrastructure in place? (Answer: Yes, because Active Directory requires DNS.) Mention that creating (or adding to) a location map to document an organizations locations, the number of hosts at each location, the number of users at each location, the location of any legacy DNS servers, and so on can be helpful when gathering information for a name resolution strategy. Emphasize that the key point in this topic is determining the IP address requirements of existing hosts on the network, including the use of NetBIOS. These requirements must be considered when designing a name resolution strategy. Consider asking students this question: What applications or network components require reverse lookup? (Answer: Almost every SMTP server.) NetBIOS Resources Consider asking the class this question: If I turn off NetBIOS on the classroom network right now, which is a pure Windows Server 2003 network, what feature will no longer function? (Answer: Network Neighborhood, which is dependent on NetBIOS.) Emphasize that an organizations current network infrastructure and business requirements will drive its design decisions for a name resolution strategy.

Host Requirements

Guidelines for Gathering Data for Name Resolution Practice

There is no practice for this lesson.

Lesson: Designing a DNS Strategy for Interoperability

This section describes the instructional methods for teaching this lesson. This lesson provides students with the knowledge and skills needed to design a DNS name resolution strategy for interoperability with Active Directory, BIND, WINS, and DHCP. DNS Interoperability and Integration Explain that DNS integrates well with other network name resolution services, such as DHCP and WINS. DNS also integrates well with, and is required by, Active Directory.

Module 8: Designing a Name Resolution Strategy

Integration with Active Directory

When discussing the DNS/Active Directory integration benefit of reducing the scope of replication, call attention to the application directory partition, which is a new feature in Windows Server 2003 and can be configured to limit the scope of replication. Emphasize that if BIND is being used on an existing network, the network infrastructure, the companys IT personnel skills, and the requirements of the business will determine whether BIND will continue to be used for part or all of the companys Internet and intranet access, or whether BIND will continue to be used for now, but will gradually be replaced by Windows Server 2003 DNS. If students ask why an option to use an LMHOSTS file to provide name resolution is not mentioned, you can point out that the use of an LMHOSTS file is not a recommended solution because it must be manually built and manually updated. An LMHOSTS file can be used as a last resort, but its use is not recommended. Emphasize that Windows Server 2003 DHCP servers can be configured to perform DNS dynamic updates and secure dynamic updates for DHPC clients. These features simplify the network administrators job of managing the contents of a DNS zone. Take this opportunity to discuss with the class the strategies for creating a DNS interoperability design. Have students share their own work experiences with the class.

Options for Interoperability with BIND

Guidelines for Interoperability with WINS

Guidelines for Interoperability with DHCP Discussion

Lesson: Designing a WINS Replication Strategy

This section describes the instructional methods for teaching this lesson. In this lesson, students learn how to design a WINS replication strategy. Considerations for Designing a WINS Replication Strategy Guidelines for Designing a WINS Replication Strategy Practice Emphasize the hub-and-spoke topology. This topology is a simple and efficient design for accomplishing WINS replication.

To promote discussion, when discussing limiting WINS replication partnerships, consider asking students how many WINS servers/partners they have in their organizations. In this practice, students design a WINS replication strategy for Northwind Traders.

vi

Module 8: Designing a Name Resolution Strategy

Lesson: Designing a Name Resolution Strategy for Clients

This section describes the instructional methods for teaching this lesson. In this lesson, students explore strategies and guidelines for designing a name resolution strategy for clients. The lesson compares choices for name resolution for clients, explains how to incorporate security into a name resolution strategy, and provides a name resolution strategy for clients based on the relevant business requirements of a situation. Strategies for Resolving External DNS Names for Clients Point out that the method an organization chooses for resolving external DNS names for clients (root hints, forwarding, conditional forwarding, or stub zones) will depend on the organizations existing network, its domain structure, and its business requirements. Another way to describe a stub zone to students is A stub zone is a delegation on steroids. Secure Naming Practices Guidelines for Name Resolution for Clients Discussion Emphasize two key security guidelines for name resolution: expose only the public part of the organizations namespace to the Internet, and limit the resource records on the external DNS server. Emphasize to students that if they have NetBIOS-based applications or services on their networks, they will have to use WINS. Take this opportunity to discuss with the class name resolution strategies for client computers. Have students share their own work experiences with the class.

Lab A: Designing a Name Resolution Strategy

In this lab, students design a DNS name resolution strategy for interoperability and design a WINS replication strategy for Tailspin Toys. After completing this lab, students will be able to:
! !

Design a DNS strategy for interoperability. Design a WINS replication strategy.

Note To prevent confusion, at the start of the lab, remind students that in the practices they have been working with Northwind Traders, but in the labs they are working with Tailspin Toys. To begin the lab, open Microsoft Internet Explorer and then, on the Web page that appears, click the link for this lab. Play the video interviews for students, and then instruct students to begin the lab with their lab teams.

Module 8: Designing a Name Resolution Strategy

vii

Note that:
!

The e-mail message from Michael Alexander provides the specific tasks that must be accomplished in this lab. Students will need to view the Acquisitions document in the Network Files folder and the Company Locations page on the Intranet Web site. These documents, which are mentioned in the e-mail message from Michael Alexander, are the key company documents needed for this lab. BIND version information for Trey Research and Fabrikam, Inc. is contained in the Acquisitions document. BIND version information for Wingtip Toys is contained in the Company Locations page on the Intranet Web site.

Give students approximately 20 to 25 minutes to complete their DNS and WINS strategies. Then spend approximately 10 to 15 minutes discussing the students answers as a class. Student answers will vary because there are several possible DNS and WINS strategies and no single correct solution. After the teams develop their DNS and WINS strategies, have one member of each team present their teams DNS strategy to the class. Then, ask one person from each team to draw their teams WINS design on a whiteboard or flip chart. Then, as a class, you can discuss all of the teams strategies and designs. General lab suggestions For general lab suggestions, see the Instructor Notes for the Module 1 lab, Preparing to Design an Active Directory Infrastructure, in Course 2282A, Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure. Those notes contain detailed suggestions for facilitating the lab environment in this course.

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 dependent on the classroom configuration specified in the Customization Information section at the end of the Automated Classroom Setup Guide for Course 2282A, Designing a Microsoft Windows Server 2003 Active Directory and Network Infrastructure. Important Although no computer configuration changes occur on student computers during the labs, the information gathered and many of the solutions produced in a lab carry forward to subsequent labs in the course. Therefore, if this course is customized and all of the modules are not used, or they are presented in a different order, when the instructor begins a lab the instructor might need to provide students with a possible answer from the previous lab(s) to use as a starting point for the current lab.

Module 8: Designing a Name Resolution Strategy

Overview

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction This module describes how to design a name resolution strategy for your network. It discusses how to gather relevant data for a name resolution strategy. Then it describes how to design a Domain Name System (DNS) strategy for interoperability with Microsoft Windows Server 2003 Active Directory directory service, Berkeley Internet Name Domain (BIND), Microsoft Windows Internet Name Service (WINS), and Dynamic Host Configuration Protocol (DHCP). It also explains how to design a WINS replication strategy, with emphasis on using a hub-and-spoke topology. Finally, this module describes how to design a name resolution strategy for client computers. After completing this module, you will be able to:
! !

Objectives

Determine the information needed to design a name resolution strategy. Design a strategy for interoperability with Active Directory, BIND, WINS, and DHCP. Design a WINS replication strategy. Design a name resolution strategy for clients.

! !

Module 8: Designing a Name Resolution Strategy

Lesson: Gathering Data for a Name Resolution Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Lesson objectives In this lesson, you will learn what types of information to gather to design a name resolution strategy for your network. After completing this lesson, you will be able to:
!

Explain how the existing network configuration influences name resolution design decisions. Explain how physical locations influence name resolution design decisions. Explain how host requirements influence name resolution design decisions. Explain how Network Basic Input Output System (NetBIOS) resources influence name resolution design decisions. Identify the relevant information needed to design for name resolution.

! ! !

Module 8: Designing a Name Resolution Strategy

Existing Name Resolution Configuration

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Existing name resolution infrastructure considerations Before you can design a name resolution configuration for a network, you must first gather information about any existing name resolution infrastructure. There are several possible scenarios that might exist in your current network. As shown in the table below, your tasks for gathering data will vary, depending on the scenario that exists in your current network.
Scenario If no DNS infrastructure exists Tasks to perform Determine whether the domain root name needs to be visible, accessible through the Internet, or available only internally. Analyze your existing network topology and plan your DNS namespace while accounting for the service and administrative goals of your organization. Provide for anticipated expansion of the number of nodes in your DNS hierarchy by including domain name placeholders between the domain names that you are initially deploying. Adding domain name placeholders enables you to avoid having to redesign your DNS infrastructure to accommodate additional domain names. Anticipate the possibility of changes to your business model by assigning domain names that can be used in a modified context. For example, instead of using the domain name accounting.contoso.com, you might use finance.contoso.com, in anticipation of the possibility of expanding into additional financial services beyond accounting.

Module 8: Designing a Name Resolution Strategy (continued) Scenario If a DNS infrastructure exists and the Active Directory namespace is the same as the public DNS namespace Tasks to perform Perform the tasks listed above. Diagram your existing DNS infrastructure. If you are upgrading to Windows Server 2003, rolling out a new DNS deployment, or integrating Windows Server 2003 DNS with Active Directory, you might not need to make any changes to your existing DNS infrastructure. However, if you are migrating from a third-party DNS infrastructure or integrating Windows Server 2003 DNS with an existing third-party DNS infrastructure, create a diagram of your existing DNS infrastructure, including domains, servers, and clients. Use this diagram to assist you in deciding whether to make changes to your current DNS infrastructure when you deploy Windows Server 2003 DNS. Identify and document your organizations security policies before you begin to design your DNS infrastructure. In this way, you can ensure that the DNS servers, zones, and resource records you specify in your design support these policies. If a DNS infrastructure exists and the Active Directory namespace does not overlap with the public DNS namespace Perform the tasks listed above. Diagram your existing DNS infrastructure. If you are upgrading to Windows Server 2003, rolling out a new DNS deployment, or integrating Windows Server 2003 DNS with Active Directory, you might not need to make any changes to your existing DNS infrastructure. However, if you are migrating from a third-party DNS infrastructure or integrating Windows Server 2003 DNS with an existing third-party DNS infrastructure, create a diagram of your existing DNS infrastructure, including domains, servers, and clients. Use this diagram to assist you in deciding whether to make changes to your current DNS infrastructure when you deploy Windows Server 2003 DNS. Identify and document your organizations security policies before you begin to design your DNS infrastructure. In this way, you can ensure that the DNS servers, zones, and resource records you specify in your design support these policies.

In addition to gathering information about the existing name resolution configuration of your network, you must also determine if NetBIOS name resolution services, such as WINS, are used on the network. Additional reading For more information about how an existing network configuration influences design decisions for a name resolution strategy, see Deploying DNS under Additional Reading on the Web page on the Student Materials compact disc.

Module 8: Designing a Name Resolution Strategy

Physical Locations

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Physical location considerations in name resolution design Physical locations influence your DNS design decisions. Make sure to gather information about your organizations physical locations before you begin your namespace design. Gather the following physical location information:
!

The number of locations. Each location typically has at least one DNS server. The number of hosts at each location. The number of hosts at each location determines the number of DNS clients each location must support. The existence of any legacy DNS servers, such as BIND servers or Microsoft Windows NT 4.0 DNS servers. Existing legacy DNS servers might limit the use of DNS features such as incremental zone transfers. The existence of or plans to include an Active Directory directory service infrastructure. Active Directory provides the option of including Active Directory-integrated zones in your DNS design. Location of the clients in relation to a WINS server. You will need to identify if the clients are located in the same broadcast domain or in different broadcast domains. If clients are in separate broadcast domains, Microsoft recommends using WINS.

Module 8: Designing a Name Resolution Strategy

Host Requirements

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Host considerations for name resolution design Host requirements influence your design decisions for name resolution. Before you can design a name resolution strategy, you must first gather information about host requirements on your network. Make sure to consider the following:
!

Do hosts that obtain an Internet Protocol (IP) address by using DHCP or Bootstrap Protocol (BOOTP) run IP-based applications, such as Web services, that need to be accessed by other computers on the network? If so, consider including DHCP integration with DNS into your design. Do hosts run applications that require the ability to determine a hosts name from its IP address? If so, you should include reverse DNS lookup zones in your design. For example, many Simple Mail Transfer Protocol (SMTP) servers are configured to perform a reverse lookup of the IP address of each client computer that sends outgoing e-mail to it. The SMTP server can be configured to use this information to reject or refuse to forward e-mail from any computer whose name it is not able to resolve.

Do hosts run applications or services that use NetBIOS? If there are NetBIOS applications on your network, you should include a NetBIOS name resolution method, such as WINS, in your design.

Do hosts need to access network resources by using NetBIOS? If you are sharing files or printers by using NetBIOS, you should include a NetBIOS name resolution method, such as WINS, in your design.

Are any of the client computers that use NetBIOS configured to resolve NetBIOS names only by using broadcasts? If there are client computers that do not support WINS and only use NetBIOS broadcasts for name resolution, consider specifying the use of a WINS proxy on each subnet that contains this type of client computer.

Module 8: Designing a Name Resolution Strategy

NetBIOS Resources

*****************************ILLEGAL FOR NON-TRAINER USE****************************** NetBIOS considerations Before designing your name resolution strategy, you should gather information about the resources currently being used on your network that require NetBIOS.
!

Identify systems and applications that rely on NetBIOS for name resolution. Although DNS is the default name resolution method for Windows Server 2003, NetBIOS over TCP/IP (NetBT) is still used as a method of providing name resolution for older clients, including clients that run versions of Windows that are earlier than Microsoft Windows 2000, and for Windows 2003 workgroups that do not implement Active Directory. Certain applications, such as Microsoft BackOffice client/server mail configurations using Microsoft Exchange Server, require NetBIOS naming. Some services require NetBIOS. For example, a common service that uses a NetBIOS name is the File and Printer Sharing for Microsoft Networks service on a computer running Windows Server 2003. At startup, File and Printer Sharing for Microsoft Networks registers a unique NetBIOS name based on the name of the computer.

! !

Determine the impact of removing NetBIOS. If you find that a critical application relies on NetBIOS, and there is no suitable alternative application available (or acceptable) to the organization, use WINS to provide NetBIOS name resolution.

Additional reading

For more information on this topic, see Deploying WINS under Additional Reading on the Web page on the Student Materials compact disc.

Module 8: Designing a Name Resolution Strategy

Guidelines for Gathering Data for Name Resolution

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Guidelines When gathering data for name resolution, use the following guidelines:
!

Determine the current infrastructure of the organization. Gather information about the physical and administrative structure of the organization and its business needs.

Gather information about the organizations network. Analyze the existing network topology, and diagram any existing DNS infrastructure. Determine whether the network is currently or will be connected to the Internet, and whether the organization has any registered DNS domain names. Identify whether DNS data will be hosted on the organizations internal DNS servers or on an external server provided by an Internet service provider (ISP). Determine whether there are any specific client requirements or any other information that might affect your name resolution design.

Identify the security policies of the organization. Document the organizations security policies before you design your name resolution strategy to ensure that all components in your design will support these security policies.

Identify the constraints of the organization. Gather information that will help you understand the constraints of the organization, such as hardware or budget constraints.

Identify the future requirements of the organization. It is important to gather information about the future requirements of the organization. For example, it is useful to collect information such as whether the number of users or computers is likely to change due to mergers, acquisitions, reorganizations, or growth.

Module 8: Designing a Name Resolution Strategy

Lesson: Designing a DNS Strategy for Interoperability

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Lesson objectives In this lesson, you will learn how to design a DNS strategy for interoperability with Active Directory, BIND, WINS, and DHCP. After completing this lesson, you will be able to:
! !

Discuss DNS interoperability. Design a strategy for interoperability with Active Directory based on the relevant business requirements. Design a strategy for interoperability with BIND based on the relevant business requirements. Design a strategy for interoperability with WINS based on the relevant business requirements. Design a strategy for interoperability with DHCP based on the relevant business requirements.

10

Module 8: Designing a Name Resolution Strategy

DNS Interoperability and Integration

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Interoperability When designing a name resolution strategy by using DNS, make sure to plan for DNS interoperability and integration with the existing network services. DNS servers running Windows Server 2003 are compliant with most of the Request for Comments (RFC) specifications used to define the DNS protocol. This allows you to use DNS servers in mixed or heterogeneous environments. DNS integrates with other networking services to take advantage of their features. These features require you to include additional specifications in the design, such as forwarding name resolution queries to a WINS server. The following table describes the benefits of integrating DNS with other networking services.
DNS integrates with DHCP WINS Benefits Can be configured to automatically update DNS entries when DHCP addresses are assigned to DHCP client computers Can be configured to resolve DNS queries by forwarding the queries to a WINS server and resolving the queries from the WINS database entries Can be configured to provide multiple master DNS zones, secured zone updates, and encrypted DNS replication

Integration

Active Directory

Additional reading

For a list of Windows Server 2003 features that are not supported by some DNS implementations, see Table 3.5, Feature Support in Different Implementations of DNS, in Deploying DNS under Additional Reading on the Web page on the Student Materials compact disc.

Module 8: Designing a Name Resolution Strategy

11

Integration with Active Directory

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Active Directory is designed to enable easy integration of the Active Directory namespace into an existing DNS namespace. The integration of the DNS service with Active Directory enhances a DNS design by:
!

Reducing network management. Network management is reduced because DNS uses Active Directory replication to replicate DNS zone databases.

Providing secured and automatic maintenance of DNS zone databases by using dynamically updated DNS.

Benefits of Active Directory-integrated zones

Specify the use of Active Directory-integrated zones in your DNS design if your DNS topology includes Active Directory. Active Directory-integrated zones enable you to store zone data in the Active Directory database. Zone information on any primary DNS server within an Active Directory-integrated zone is always replicated. Active Directory-integrated zones:
!

Enable you to secure zones by using secure dynamic update. You can configure Active Directory-integrated zones for secure dynamic update. Secure dynamic update resolves the security risks associated with using dynamic update. Because dynamic update allows any computer to modify any record, an attacker can modify zone data, and then impersonate existing servers. By using secure dynamic update, only the computers and users specified in an access control list (ACL) can modify objects within a zone.

12

Module 8: Designing a Name Resolution Strategy

!

Provide increased fault tolerance. Because DNS replication is single-master, a primary DNS server in a standard primary DNS zone can be a single point of failure. In an Active Directory-integrated zone, a primary DNS server is not a single point of failure because Active Directory uses multimaster replication. Updates that are made to any domain controller are replicated to all domain controllers and the zone information on any primary DNS server within an Active Directory-integrated zone is always replicated.

Can be configured to reduce the scope of replication. Windows Server 2003 Active Directory enables you to configure an application directory partition that limits the scope of replication. Data stored in an application directory partition is replicated to a subset of domain controllers. This subset is determined by the replication scope of the data. In the default configuration of Windows Server 2003 Active Directory, DNS application directory partitions are present only on the domain controllers that run the DNS server service. By storing Active Directoryintegrated zones in an application directory partition, you can reduce the number of objects that are stored in the global catalog, and you can reduce the amount of replication traffic within a domain. In contrast, Active Directory-integrated zones that are stored in domain directory partitions are replicated to all domain controllers in the domain. Storing Active Directory-integrated zones in an application directory partition allows replication of DNS data to domain controllers anywhere in the same Active Directory forest.

Module 8: Designing a Name Resolution Strategy

13

Options for Interoperability with BIND

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Using BIND with Active Directory Depending on the Active Directory and DNS features that you need to support, you can integrate some versions of BIND with Active Directory. Although some earlier versions of BIND will function with Active Directory, BIND 8.2.1 is the minimum recommended version. To incorporate existing BIND servers in your design, choose one of the following strategies:
!

Use BIND for Internet access and Windows Server 2003 DNS for intranet access. Use BIND for both Internet and intranet access. Use BIND for Internet and intranet access, but place the Active Directory domain on the Windows Server 2003 DNS server. Use Windows Server 2003 DNS for both Internet and intranet access.

! !

The strategy you choose will depend on your current network. For example, if your current network has DNS BIND installed throughout, you might choose to keep the BIND servers and not use Windows Server 2003 DNS. Alternatively, you might choose to use 50 percent BIND DNS and 50 percent Windows Server 2003 DNS, or to begin with 100 percent BIND DNS and slowly migrate to Windows Server 2003 DNS. Business factors such as investment in current infrastructure and IT personnel skills with specific DNS or BIND versions might influence your design decision. If a BIND server is used for access to external resources on the Internet and a Windows Server 2003 DNS server for Active Directory, you will need to delegate the Active Directory subdomains to the Windows Server 2003 DNS server. These are the subdomains that are used by client computers to gain access to services in Active Directory. Additional reading For more information on BIND, see the Web page at http://www.isc.org. For a list of Windows Server 2003 features that are supported by various BIND implementations, see Table 3.5, Feature Support in Different Implementations of DNS, in Deploying DNS under Additional Reading on the Web page on the Student Materials compact disc.

14

Module 8: Designing a Name Resolution Strategy

Guidelines for Interoperability with WINS

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Guidelines When designing for DNS interoperability with WINS, use the following guidelines:
!

Do not use extended characters in NetBIOS names, such as the underscore (_) and the period (.). The underscore character, for example, is converted to a dash in DNS host names. In other words, use NetBIOS names that are also DNS compliant. Consider upgrading older WINS clients and establishing DNS as your only method of name resolution. Support issues involving network name service are simplified by using a single naming and resource locator service (such as WINS and DNS) on your network. Specify multiple WINS servers for clients to provide server redundancy. WINS client support allows you to specify up to 12 WINS servers for redundancy, and includes support for multiple NetBIOS node types. WINS servers communicate with other WINS servers to fully replicate their databases with each other. This ensures that a name registered with one WINS server is replicated to all other WINS servers within the intranet, providing a consistent enterprise-wide database. When a network uses multiple WINS servers, each WINS server is configured as a pull partner or a push partner of at least one other WINS server.

Module 8: Designing a Name Resolution Strategy

!

15

Configure DNS server for WINS Lookup and WINS Reverse Lookup. By configuring your DNS server for WINS lookup, you can direct DNS to query WINS for name resolution, so that DNS clients can look up the names and IP addresses of WINS clients. To direct DNS to query WINS for name resolution, add a WINS lookup record to the authoritative zone. An authoritative DNS server checks that zone when it receives a query for a name. If the DNS server does not find the name in the authoritative zone, but the zone contains a WINS lookup record, the DNS server queries the WINS server. If the name is registered with WINS, the WINS server returns the associated record to the DNS server. The DNS server then compiles and returns the corresponding DNS record in response to the original DNS request. DNS clients do not need to know whether a client is registered with WINS or DNS, and they do not need to query the WINS server. You can also configure your DNS server for WINS reverse lookups. Reverse lookups work slightly differently. When an authoritative DNS server is queried for a nonexistent PTR record, and the authoritative zone contains the WINS-R record, the DNS server uses a NetBIOS node adapter status lookup.

16

Module 8: Designing a Name Resolution Strategy

Guidelines for Interoperability with DHCP

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Key points Windows Server 2003 DNS supports DHCP through the dynamic update of DNS zones. By integrating DNS and DHCP, you can provide your network resources with dynamic addressing information that is stored in DNS. When designing for DNS interoperability with DHCP, use the following guidelines:
!

Configure the DHCP server to perform DNS dynamic updates and secure dynamic updates for DHCP clients. A DHCP server can enable dynamic updates in the DNS database for any DHCP clients that do not support these updates. DHCP servers can register A and PTR resource records on behalf of DHCP clients. This reduces the time needed to manually add those records and provides support for DHCP clients that cannot perform dynamic updates.

Use secure dynamic updates for all Active Directory-integrated zones. By enabling secure dynamic updates, you can restrict updates to only a specific set of authorized users or systems. When a secure update policy is enabled for the zone, only users, systems, or groups authorized through Active Directory and included in the ACL for each directory-integrated zone are permitted to update the zone or specific resource records used in it.

Specify which DHCP servers to authorize. Authorizing DHCP servers can prevent unauthorized DHCP servers from joining an existing DHCP network in which Windows 2003 Server and Active Directory are deployed.

Additional reading

For more information about designing for interoperability with DHCP, see Deploying DHCP under Additional Reading on the Web page on the Student Materials compact disc.

Module 8: Designing a Name Resolution Strategy

17

Discussion: Designing a DNS Strategy for Interoperability

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Discussion Discuss as a class the strategies for creating a DNS interoperability design. Use the following questions to guide your discussion: 1. Does your organization use any DNS servers that do not run Microsoft Windows 2000 or Windows Server 2003 DNS? If so, which ones? 2. Does your organization use DNS implementations from more than one vendor? If so, how do you integrate them? 3. Does your organization use only Windows-based DNS servers? If so, do you plan on upgrading them all to Windows Server 2003? Answers may vary based on the work experience of the students who are participating in the class.

18

Module 8: Designing a Name Resolution Strategy

Lesson: Designing a WINS Replication Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction WINS provides the preferred dynamic solution for NetBIOS name resolution for enterprise networks. In this lesson, you will explore considerations and guidelines for designing a WINS replication strategy. After completing this lesson, you will be able to:
! !

Lesson objectives

Explain the considerations for designing WINS replication. Design a WINS replication strategy based on the relevant business requirements.

Module 8: Designing a Name Resolution Strategy

19

Considerations for Designing a WINS Replication Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction If your WINS design calls for more than one WINS server, you need to design for WINS replication. Replicating WINS databases ensures that a name that is registered with one WINS server is replicated to all other WINS servers on the network. As a result, a WINS client can resolve any NetBIOS name in the network regardless of the WINS server on which the name was registered. When designing a WINS replication strategy, consider the following:
!

Considerations

The applicability of the hub-and-spoke design Using a hub-and-spoke design for WINS replication and convergence provides a simple and effective design for organizations that require complete convergence with minimal administrative intervention. For example, a hub-and-spoke design works well for organizations with centralized headquarters or a corporate data center (the hub) and several branch offices (the spokes). Also, a second or redundant hub (a second WINS server in the central location) can increase the fault tolerance for WINS. For very large WINS implementations, a hub-and-spoke design with multiple hubs should be used. Two WINS servers should be used at each hub site for redundancy and load balancing.

The replication rate of the WINS server database As in wide area network (WAN) replication planning, the WINS server database should replicate frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications should not be so small that it interferes with network throughput.

20

Module 8: Designing a Name Resolution Strategy

Because the speed of the underlying network links for local area networks (LANs) are much greater than for WANs, it might be acceptable to increase the frequency of WINS database replication by optimizing push and pull parameters for LAN-based replication partners. For example, between LAN-based replication partners, it often works to enable WINS to use a persistent connection between the servers. Without a persistent connection, the normal update count threshold defaults to a minimum of 20. You can specify a smaller update count with a persistent connection.
!

Automatic partner configuration Because periodic multicast announcements between WINS servers can add traffic to your network, automatic partner configuration is recommended only if you have a small number of installed WINS servers (typically, three or fewer).

The option of configuring WINS replication between one or more WINS servers in domains that do not have a trust relationship You can do this without a valid user account in the untrusting domains. To configure replication, an administrator for each WINS server must use the WINS console or Netsh commands to manually configure that server to permit this replication.

Additional reading

For more information about considerations for designing a WINS replication strategy, see Deploying WINS under Additional Reading on the Web page on the Student Materials compact disc.

Module 8: Designing a Name Resolution Strategy

21

Guidelines for Designing a WINS Replication Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Guidelines When designing a WINS replication strategy, use the following guidelines:
!

Determine the number of WINS servers needed. The number of WINS servers needed depends on the size of the network environment, the required degree of availability, the redundancy need, the location of routers and the distribution of clients in each subnet, and the speed of WAN links. Use the minimum number of WINS servers that will service the needs of your organization. If you use too many WINS servers, WINS replication might not be able to keep the WINS database synchronized.

Determine the level of fault tolerance required. Any design that requires high availability must include more than one WINS server. If your organization has identified a need for fault tolerance, you must ensure that your WINS design provides for redundancy. You can accomplish this by designing for multiple WINS servers that are configured as primary and secondary WINS servers or by using a clustering solution. When designing for fault tolerance, consider all possible points of failure, including servers, WAN links, and routers. Select push/pull when designing replication partners. In general, push/pull is a simple and effective way to ensure full WINS replication between partners. For most WINS installations, you should avoid the use of limited replication partnerships (push only or pull only) between WINS servers. In some larger enterprise WINS networks, limited replication partnering can effectively support replication over slow WAN links. Assess the impact of WINS traffic on slow WAN links. Network topology can influence your decision on replication frequency. For example, if your network has multiple hubs connected by relatively slow WAN links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the LAN or on fast WAN links. This reduces traffic across the slow WAN links and reduces contention between replication traffic and WINS client name queries.

22

Module 8: Designing a Name Resolution Strategy

Practice: Designing a WINS Replication Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction Scenario In this practice, you will design a WINS replication strategy for Northwind Traders. Discuss your results as a class. Northwind Traders has decided to include WINS as part of its Windows Server 2003 Active Directory design. Northwind Traders current network infrastructure is illustrated in the diagram on the PowerPoint slide. The IT management team wants to see a proposal for an effective WINS replication scheme to ensure the smooth implementation of WINS. Specifically, the proposed WINS design must address the issue of fault tolerance.

Module 8: Designing a Name Resolution Strategy

23

Practice

Based on the scenario, what would you propose as a WINS replication strategy for Northwind Traders? Draw your solution in the space below. Be sure to include the number of WINS servers that will be placed in each site and all of the replication partnerships that must be created.

Answers may vary. However, this is the best solution based on the scenario.

24

Module 8: Designing a Name Resolution Strategy

Lesson: Designing a Name Resolution Strategy for Clients

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction In this lesson, you will learn about strategies for resolving external DNS names for clients by using root hints, forwarding, conditional forwarding, or stub zones. You will also explore secure DNS naming practices, as well as guidelines for designing a name resolution strategy for clients. After completing this lesson, you will be able to:
! ! !

Lesson objectives

Compare choices for name resolution for clients. Explain how to incorporate security into a name resolution strategy. Design a name resolution strategy for clients based on the relevant business requirements.

Module 8: Designing a Name Resolution Strategy

25

Strategies for Resolving External DNS Names for Clients

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Introduction You can enable clients to resolve external names for both your organization and other Internet hosts by configuring the internal DNS server to use root hints, forwarding, conditional forwarding, or stub zones to resolve name resolution requests that it is unable to resolve locally. When designing recursive name resolution for clients, use one of the following strategies:
!

Strategies

Root hints A root hint is used to prepare servers authoritative at non-root zones so that they can learn and discover authoritative servers that manage domains that are located at a higher level or in other subtrees of the DNS domain namespace. These hints are essential for servers authoritative at lower levels of the namespace when locating and finding servers in other domains.

Forwarding A forwarder is a DNS server to which other DNS servers in the network forward the queries that they cannot resolve locally. Forwarders are often desirable when access to remote DNS servers requires use of a slow link, such as a fast-speed internal network linked to the Internet over a relatively low-speed connection.

Conditional forwarding A conditional forwarder is a DNS server used to forward queries according to domain names contained in each query. Rather than having a DNS server forward all queries it cannot resolve locally to a forwarder, DNS servers can be configured to forward queries to different forwarders according to the specific domain names contained in the queries. Forwarding according to domain names improves conventional forwarding by adding a name-based condition to the forwarding process.

26

Module 8: Designing a Name Resolution Strategy

!

Stub zones A stub zone is a copy of a zone that contains only those resource records necessary to identify the authoritative DNS servers for that zone. A stub zone is used to keep a DNS server hosting a parent zone aware of the authoritative DNS servers for its child zone and thereby maintain DNS name resolution efficiency. A stub zone consists of: The start of authority (SOA) resource record, name server (NS) resource records, and the glue A resource records for the delegated zone. The IP address of one or more master servers that can be used to update the stub zone. The master servers for a stub zone, one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary zone for the delegated domain name.

Module 8: Designing a Name Resolution Strategy

27

Secure Naming Practices

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Best practices To incorporate security into your name resolution design, make sure that your naming approach:
! !

Exposes only the public part of the organizations namespace to the Internet. Enables all Active Directory client computers to resolve all of the organizations internal and external names. Enables client computers requiring access to the Internet to resolve all names from the Internet. Ensures that the external DNS server has resource records for only the external hosts and services that will be exposed to users of the Internet.

Note To allow internal clients to gain access to your organizations Internet data, you can place servers with duplicate content on the internal network, using the same DNS names as the servers on the Internet. Therefore, the external DNS servers resolve the organizations DNS names to an external IP address, and the internal DNS servers resolve the organizations DNS name to an internal IP address.

28

Module 8: Designing a Name Resolution Strategy

Guidelines for Name Resolution for Clients

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Guidelines When designing name resolution for clients, use the following guidelines:
!

When working with an existing DNS structure: Use default computer naming. When a client computer joins a domain, the computer assigns itself a primary DNS name comprised of the host name of the computer and the name of the domain. Do not change the resolver configuration for existing clients. Windows 2003 clients do not need to point directly to a Windows 2003 DNS server and can use any DNS server on the network.

When creating a new DNS structure: Use default computer naming. Configure clients with the addresses of at least two of the closest DNS servers that contain the proper SOA records for the domain.

Use WINS if you have NetBIOS-based applications or services on your network. Place the MSDCS zone for the forest root domain in a forest-wide application partition so that all domain controllers in the forest that are also DNS servers can locate the root domain controllers. Place domain zones in the domain-wide application partition. Use stub zones instead of delegations for managing large domain tree delegations. Use conditional forwarding to resolve disjointed trees within the same organization to save the extra traffic caused by using root hints.

! !

Module 8: Designing a Name Resolution Strategy

29

Discussion: Designing a Name Resolution Strategy for Clients

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Discussion Each organization handles name resolution differently. Share with the class your experiences with name resolution. Use the following questions to guide your discussion: 1. How does your organization protect its internal namespace from the Internet? 2. Do you use different DNS servers for internal and external name resolution? 3. Do you use forwarders, stub zones, or conditional forwarders in your DNS strategy? 4. How is WINS replication configured in your organization? Answers may vary based on the work experience of the students who are participating in the class.

30

Module 8: Designing a Name Resolution Strategy

Lab A: Designing a Name Resolution Strategy

*****************************ILLEGAL FOR NON-TRAINER USE****************************** Objectives After completing this lab, you will be able to:
! !

Design a DNS strategy for interoperability. Design a WINS replication strategy.

Scenario

You are a consultant who has been hired to create a name resolution strategy for Tailspin Toys. The lab uses an interactive application to convey scenario-based information. To begin a lab, open Internet Explorer, and then on the Web page that appears, click the link for this lab. Your instructor will break the class into groups to do the lab. Each group should be prepared to present their design to the class at the end of the lab.

Estimated time to complete this lab: 60 minutes

Module 8: Designing a Name Resolution Strategy

31

Exercise 1 Designing a DNS Strategy for Interoperability

In this exercise, you will use the lab browser to gather name resolution requirements and information for the Tailspin Toys organization. Then you will use this information and the facts that you have gathered in previous labs to answer the following DNS interoperability questions. 1. How will you integrate Windows Server 2003 DNS with the BIND implementations at the Wicklow, Monterrey, and Istanbul locations? Answers may vary. The following is one possible solution: In the Wicklow location, because BIND is being used only for Internet name resolution, it will continue to be used for that purpose. However, because BIND version 4.9.7 does not support dynamic DNS, Windows Server 2003 DNS will be used for Active Directory and for all other internal DNS name resolution. In the Monterrey and Istanbul locations, because BIND is being used for all name resolution, and because the versions of BIND in use in those locations support SRV records and Dynamic DNS, BIND will continue to be used in those locations for all DNS name resolution services. ____________________________________________________________ ____________________________________________________________ 2. How you will ensure that the _MSDCS subdomain for the root domain of each forest is highly available? Answers may vary. The preferred answer is to make the _MSDCS subdomain for the root domain of each forest highly available in that forest. To accomplish this, you must delete the _MSDCS subdomain for the root domain in the forest and then re-create it as a separate zone. You must then place the _MSDCS zone in the ForestDnsZones application directory partition so that it will be distributed to all domain controllers in the forest that are also DNS servers. ____________________________________________________________ ____________________________________________________________

32

Module 8: Designing a Name Resolution Strategy

Exercise 2 Designing a WINS Replication Strategy

In this exercise, you need to design a WINS solution for Tailspin Toys. Tailspin Toys wants to use WINS at all of their locations worldwide for NetBIOS name resolution. Use the information you have gathered in previous labs and the new information presented in the scenario to answer the following questions. In the space below, draw your design for the placement of WINS servers at Tailspin Toys. Include information on replication partners and type (push, pull, or push/pull). As you create your design, ensure that the following requirements are met:
!

Ensure that WINS servers can resolve any NetBIOS name from any location. Provide for local WINS server fault tolerance at each location.

Answers may vary; the graphic provided is one possible solution. Other solutions can be created and justified. In this solution, which is based on the hub-and-spoke design, New York functions as the hub location for all WINS replication. Each of the companys locations has two WINS servers that are configured as push/pull partners. In addition, one WINS server at each location is configured as a push/pull partner with one of the WINS servers in New York. In this design, the WINS data is kept up to date in all locations with a minimum of WAN traffic, and any user can resolve any NetBIOS name from any location. Placing two WINS servers in each location provides the required fault tolerance.