Tài liệu Module 2: Designing an Active Directory Naming Strategy pdf

Contents
Overview 1
Identifying Business Needs 2
DNS and Active Directory 3
Planning Active Directory Domain Names 7
Designing a DNS Naming Strategy for
Active Directory 11
Lab A: Designing an Active Directory
Naming Strategy 22
Review 31

Module 2: Designing an
A
ctive Directory Naming
Strategy


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

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.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows NT, Active Directory, BackOffice, PowerPoint, Visual Basic, and
Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the
U.S.A. and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Project Lead: Andy Sweet (S&T OnSite)
Instructional Designers: Andy Sweet (S&T OnSite), Ravi Acharya (NIIT), Sid Benavente,
Richard Rose, Kathleen Norton
Instructional Design Consultants: Paul Howard, Susan Greenberg
Program Managers: Lorrin Smith-Bates (Volt), Megan Camp (Independent Contractor)
Technical Contributors: Angie Fultz, Lyle Curry, Brian Komar (3947018 Manitoba, Inc.), Jim
Clark (Infotec Commercial Systems), Bill Wade (Excell Data Corporation), David Stern, Steve
Tate, Greg Bulette (Independent Contractor), Kathleen Cole (S&T OnSite)
Graphic Artist: Kirsten Larson (S&T OnSite)
Editing Manager: Lynette Skinner
Editor: Jeffrey Gilbert (Wasser)
Copy Editor: Patti Neff (S&T Consulting)
Online Program Manager: Debbi Conger
Online Publications Manager: Arlo Emerson (Aditi)

Online Support: Eric Brandt (S&T Consulting)
Multimedia Development: Kelly Renner (Entex)
Testing Leads: Sid Benavente, Keith Cotton
Testing Developer: Greg Stemp (S&T OnSite)
Courseware Testing: Testing Testing 123
Production Support: Ed Casper (S&T Consulting)
Manufacturing Manager: Rick Terek (S&T OnSite)
Manufacturing Support: Laura King (S&T OnSite)
Lead Product Manager, Development Services: Bo Galford
Lead Product Managers: Dean Murray, Ken Rosen
Group Product Manager: Robert Stewart


Module 2: Designing an Active Directory Naming Strategy iii


Instructor Notes
Microsoft
®
Windows
®
2000 Active Directory
™
directory service contains
information about all objects in an organization’s network. The goal is to
provide clients access to this information. This module provides students with
the ability to successfully plan and implement Microsoft Windows NT
®
version
5.0 Active Directory naming. It starts by looking at how Domain Name System

(DNS) naming is done. This sets the foundation for Active Directory naming. It
is important to note that DNS as a topic may be new to many students. Stress
that this module is not intended to cover DNS in detail, but rather provides
sufficient information for them to be successful in planning for DNS and Active
Directory.
At the end of this module, students will be able to:
!
Identify business needs that impact the selection of Active Directory names.
!
Describe how Active Directory is integrated with DNS.
!
Plan Active Directory names within the Active Directory hierarchy.
!
Design a DNS naming strategy for Active Directory root domains.

Lab A, Designing an Active Directory Naming Strategy, is a scenario-based
planning lab. The students will examine business criteria that affect the design
of an Active Directory naming strategy. They will then use this information to
design an Active Directory naming strategy.
Materials and Preparation
This section provides you with the materials and preparation tasks that are
needed to teach this module.
Required Materials
To teach this module, you need Microsoft PowerPoint
®
file 1561b_02.ppt.

Preparation Tasks
To prepare for this module, you should:
!

Read all of the materials for this module.
!
Complete the lab.
!
Read the following technical white paper located on the Trainer Materials
compact disc:
• Windows 2000 DNS

Presentation:
60 Minutes

Lab:
60 Minutes
iv Module 2: Designing an Active Directory Naming Strategy


Instructor Setup for a Lab
This section provides setup instructions that are required to prepare the
instructor computer or classroom configuration for a lab.
Lab A: Designing an Active Directory Naming Strategy
No special setup is necessary.
This planning lab in three exercises describes three organizations of different
sizes that will use Active Directory. The students will create a naming design
for the Active Directory, using their knowledge of DNS naming and Active
Directory design.
In the first exercise the students will determine the best name for an Active
Directory root domain and justify their answers based on the criteria given.
In exercises two and three the students will use the decision tree flow chart to
make their decisions on how to name the domains to best meet the needs of the
organizations as given in the criteria for the lab.

Module Strategy
Use the following strategy to present this module:
!
Identifying Business Needs
This section introduces the naming structure of Active Directory. Begin by
explaining the directory naming needs of an organization. Discuss the
intended scope of Active Directory for an organization and explain the
importance of determining whether the organization is planning an Internet
presence, if it has not done so already.
!
DNS and Active Directory
The section presents the relationship of DNS with Active Directory. Explain
that although Active Directory and DNS share common names, each of
them is used for a different purpose. Also explain that Berkeley Internet
Name Domain (BIND) DNS servers can be used to interoperate with Active
Directory.
!
Planning Active Directory Domain Names
This section illustrates the factors that may determine the naming strategy of
Active Directory. Explain that determining the scope of Active Directory is
the first step in planning Active Directory domain names. The next step
includes designing the naming strategy of the Active Directory hierarchy.
Then, describe the guidelines that should be considered while choosing
Active Directory domain names.
!
Designing a DNS Naming Strategy for Active Directory
This section describes the design of naming strategies for the internal and
the external network of an organization. Explain the initial naming decisions
that include activities such as registering the DNS root names and

determining internal and external naming strategies. Discuss the various
scenarios of naming public and private networks in an Active Directory
structure. Explain how a DNS solution is integrated with BIND. Finally
summarize the process of designing an Active Directory naming strategy.

Module 2: Designing an Active Directory Naming Strategy v


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 a paper-based planning lab, and as a result, there are
no lab setup requirements or configuration changes that affect replication or
customization.


Module 2: Designing an Active Directory Naming Strategy 1


Overview
! Identifying Business Needs
! DNS and Active Directory
! Planning Active Directory Domain Names
! Designing a DNS Naming Strategy for Active Directory


Resolution of unique names is the cornerstone of identifying and accessing
objects in Microsoft

®
Windows
®
2000 Active Directory
™
directory service.
Active Directory uses the Domain Name System (DNS) as a basis for naming
domains. The hierarchical structure of Active Directory is derived from the root
domain, which is the first domain created. Carefully selecting an inclusive DNS
name for the root domain is crucial because an inclusive name may make it
easier for users to access the network over the Internet and also enable network
flexibility.
At the end of this module, you will be able to:
!
Identify business needs that impact the selection of Active Directory names.
!
Describe how Active Directory is integrated with DNS.
!
Plan Active Directory names within the Active Directory hierarchy.
!
Design a DNS naming strategy for Active Directory root domains.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in

In this module, you will learn
about naming strategies for

Active Directory.
2 Module 2: Designing an Active Directory Naming Strategy


Identifying Business Needs
! Main Business Needs that Impact a Naming Strategy:
#
Intended Scope of Active Directory
#
Internet Presence


The initial root domain name will influence the structure of the Active
Directory hierarchy. A properly selected name should accommodate the current
and future planned business needs of an organization. The two primary business
considerations that affect the naming of an Active Directory structure are how
much of the organization Active Directory should include, and whether or not
the organization plans to make some or all of its resources available on the
Internet.
Intended Scope of Active Directory
When assessing business needs, you need to determine the scope of the planned
Active Directory structure. Before you implement Active Directory, you must
first determine how the Active Directory structure will meet the business
requirements of the organization. Thus, the design of the Active Directory
structure should accommodate one or more of the following possibilities,
depending on the business requirements:
!
Will the Active Directory structure include the entire organization,
including subsidiaries?
!

Will the Active Directory incorporate partners or customers in the future?
!
Are you anticipating any mergers or acquisitions in the next two to five
years?

Internet Presence
You must consider whether or not the organization's Active Directory will ever
be available on the Internet. If so, you must choose a name for the Active
Directory root that adheres to Internet standards. You must also choose a DNS
strategy to support the Active Directory.
Slide Objective
To identify the main
business needs that impact
the naming strategy for
Active Directory.
Lead-in
The scope of the business
will help determine the root
domain name of Active
Directory.
Module 2: Designing an Active Directory Naming Strategy 3


$
$$
$

DNS and Active Directory
! Distinguishing Between DNS and Active Directory
! Interoperability with BIND

Active Directory follows DNS standards for naming domains, servers, and
services. Active Directory also uses DNS as the domain locator service. You
can use DNS for name resolution of both intranet (internal) and Internet
(external) resources in your organization. There are special considerations you
must take into account if your organization uses a Berkeley Internet Name
Domain (BIND) DNS server and insists on maintaining it.
Slide Objective
To describe the relationship
between Active Directory
and DNS.
Lead-in
Active Directory closely
follows DNS standards for
naming.
4 Module 2: Designing an Active Directory Naming Strategy


Distinguishing Between DNS and Active Directory
Domain Name System
(DNS)
Domain Name System
Domain Name System
(DNS)
(DNS)
contoso.msft
contoso.msft
! DNS Servers Store Resource Records
! Active Directory Servers Store Domain Objects

Active Directory can consist of one or more domains. You identify Active
Directory domains by the DNS names you assign them.
The Active Directory domain and the corresponding DNS domain have the
same name, yet each has a distinct role. These two domains store different
information and manage different objects.
DNS servers store and manage resource records within a zone database file. A
DNS zone database file contains all resource records for a single DNS domain,
or a discreet portion of a DNS domain tree.
Active Directory stores and manages domain objects. Objects in the Active
Directory include users, computers, printers, servers, workstations, services and
shares. All objects are stored within Active Directory and managed either by
scripting, or by tools within Microsoft Management Console (MMC).
Because Active Directory and DNS domain names are identical and DNS is the
mechanism for performing name resolution, each Active Directory domain
requires a corresponding DNS domain. However, each DNS domain does not
require a corresponding Active Directory domain.
Slide Objective
To illustrate how DNS
interacts with Active
Directory.
Lead-in
DNS and Active Directory
share common names for
their respective domains,
but each is used for a
different purpose.
Key Points
DNS and Active Directory

share domain names but
store and manage different
information.
Module 2: Designing an Active Directory Naming Strategy 5


Interoperability with BIND
! Windows 2000 DNS Server Service Offers Maximum
Compatibility
! BIND DNS Servers Can Be Integrated with Active
Directory
#
BIND 8.2.1 or later recommended


Windows 2000 DNS Server service is fully compatible with Active Directory.
However, some organizations may use BIND DNS servers and insist on
maintaining their use.
Certain versions of BIND can be integrated with Active Directory. If a business
need requires that the existing BIND servers be kept in place, you can make one
of four choices:
!
Use BIND for external access and Windows 2000 DNS for internal access.
!
Use BIND for both Internet (external) and intranet (internal) access.
!
Use BIND for internal and external access, but place the Active Directory
domain on the Windows 2000 DNS server.
!
Use Windows 2000 DNS for both external and internal access.

If a BIND server is used for external resources and a Windows 2000 DNS
server for Active Directory, you will need to delegate the Active Directory
subdomains to the Windows 2000 DNS server. These are the subdomains that
are used by client computers to gain access to services in Active Directory.
While some earlier versions of BIND will function with Active Directory,
BIND 8.2.1 is the minimum recommended version. BIND 8.2.1 supports the
SRV (service) resource records, dynamic updates, negative caching, and
incremental zone transfers.
Slide Objective
To discuss how BIND DNS
servers can be used with
Active Directory.
Lead-in
Some organizations may
insist on maintaining BIND
servers for their existing
DNS service.
Delivery Tip
There are no technical
reasons to use a BIND DNS
implementation with Active
Directory.
6 Module 2: Designing an Active Directory Naming Strategy


The following table compares the features supported in Windows 2000 DNS
and BIND:
Feature Windows 2000 BIND 8.2.1 BIND 4.9.7

SRV records Yes Yes Yes
Dynamic Update Yes Yes No
Secure Dynamic
Update
Yes No No
WINS & WINS-R
records
Yes No No
Fast zone transfer Yes Yes Yes
Incremental zone
transfer
Yes Yes No
UTF-8 character
encoding
Yes No No


For more information on SRV resource records and dynamic DNS, see
RFC 2052 and RFC 2136.

Note
Module 2: Designing an Active Directory Naming Strategy 7


$
$$
$

Planning Active Directory Domain Names
! Determining the Scope of Active Directory

! Designing the Naming Hierarchy
! Choosing Active Directory Domain Names


Because Active Directory is tightly integrated with DNS, you should adhere to
DNS standards when planning the naming strategy for Active Directory. Your
Active Directory design should include:
!
Determining the scope of Active Directory within your organization.
!
Designing a hierarchical DNS name.
!
Choosing Active Directory domain names by using a naming strategy.

Slide Objective
To describe how Active
Directory names are
influenced by a chosen
hierarchy.
Lead-in
To plan Active Directory
domain names, you must
first determine the scope of
Active Directory within your
organization.
8 Module 2: Designing an Active Directory Naming Strategy


Determining the Scope of Active Directory
! DNS Name Should Represent Entire Organization

#
Headquarters
#
Branch Locations
#
Business Partners
! Active Directory Name Can Be Internet Name
#
Register Name with ICANN


When you determine the scope of Active Directory, make it as broad as
possible to avoid having to restructure it later. When considering the scope for
naming, you should consider not just the internal organization, but whether the
organization will have an Internet presence.
Your DNS Name Should Represent Your Entire
Organization
Because Active Directory can accommodate only one DNS root name, you
should choose a name that represents the entire organization. This name will
allow all users within the organization to access all information and resources
within the organization.
There are instances, however, when the organization may require more than one
root name. For example, if the organization has acquired a company that
already has a well-established identity on the Internet, you might want to retain
the DNS name of the newly acquired company.
The Active Directory Name Can Be Your Internet Name
Active Directory can exist within the scope of the Internet DNS structure. In
this case, you must register the DNS root name with the Internet Corporation
for Assigned Names and Numbers (ICANN). Registration ensures the global
uniqueness of all DNS names. You will have the authority to manage your own

hierarchy of child domains, zones, and hosts within the root domain.
Slide Objective
To describe how Active
Directory names are
influenced by a chosen
hierarchy.
Lead-in
To plan Active Directory
domain names, you must
first determine the scope of
Active Directory within your
organization.
Key Points
Use as broad a scope as
possible, and choose a
representative DNS name.
Module 2: Designing an Active Directory Naming Strategy 9


Designing the Naming Hierarchy
DNS Name: contoso.msft
namerica.contoso.msft
DNS Name: namerica.contoso.msft DNS Name: europe.contoso.msft
Child
Child
Child
Child
Root
Root
contoso.msft

europe.contoso.msft


Domains in Active Directory are arranged in a hierarchical structure that
reflects their relationships to each other. Within the network, each domain must
have a unique DNS name that matches the Active Directory domain name.
Client computers running Active Directory use these names to identify and
locate domain controllers for logon purposes. The goal in designing your
naming hierarchy is to reflect the organization logically.
The First Domain Is the Root Domain
The first domain created in Active Directory is the starting point, or root, of
Active Directory. All other domains are derived from the root domain. Only
one name can be used for the root domain. If you plan an Internet presence
using this root name, the name must be unique on the Internet.

You cannot change the name of the root domain in your Active
Directory forest without removing Active Directory and creating a new forest.

Domains Derived from the Root Domain Form a
Hierarchical Tree
If you have multiple domains in Active Directory, a naming hierarchy is
formed. For example, a network with a single domain might have the single
domain name, contoso.msft. If business needs require you to divide your
network into three domains, North America, Europe, and Africa, your domain
names could be namerica.contoso.msft, europe.contoso.msft, and
africa.contoso.msft. Each domain name is separate, but maintained within the
same Active Directory tree.
Slide Objective
To illustrate how domains
are named and arranged

hierarchically.
Lead-in
You need to carefully plan
the naming hierarchy for the
Active Directory.
Key Points
Active Directory domain
names are not easily
changed; base your naming
design on long-term, static
considerations.

A single domain model is
preferred to multiple
domains.
Im
p
ortan
t

10 Module 2: Designing an Active Directory Naming Strategy


Choosing Active Directory Domain Names
! Choose a Root Domain Name Unique to the Internet
! Conform to DNS Naming Regulations
! Register Your DNS Domain Name
! Choose Meaningful, Stable, Scalable Names
! Use An Existing DNS Domain Name

Because Active Directory naming follows the standard DNS format, DNS
must be installed on your network, and Active Directory names must conform
to DNS naming guidelines. When choosing Active Directory domain names,
consider the following strategies:
!
The Active Directory root domain name must be unique in the DNS
hierarchy. If your network connects to the Internet, choose a name that is
unique on the Internet.
!
If your network connects to the Internet, the DNS name of each Active
Directory domain must conform to Internet domain naming rules.

For more information on DNS character standards, see RFC 1034,
RFC 1035, and RFC 1123.

!
You will need to register the DNS domain name you designate as the root
Active Directory domain with ICANN if you plan to use the name for both
external and internal access.
!
Choose domain names that are recognizable, meaningful, and stable, such as
geographical names. Choose a name that can last three to five years, and
that can accommodate the addition of child domains, which might occur in
the case of a reorganization or acquisition.
!
Use an existing DNS domain name within the registered DNS hierarchy for
the organization. Create a new domain name as a child domain of the
existing DNS domain namespace, such as corp.contoso.msft.

The draft that reserves .local for local domain names has expired. For
more information, see />local-names-07.txt.

Slide Objective
To identify strategies for
choosing Active Directory
domain names.
Lead-in
Active Directory and DNS
are used together to create
effective domain names.
Key Point
If the only DNS domain
registered for your
organization is contoso.msft
and in Active Directory you
need separate domains for
the United States and
Europe divisions, you would
create new DNS domains
for the additional Active
Directory domains, such as
us.contoso.msft and
eu.contoso.msft.
Note
Note
Module 2: Designing an Active Directory Naming Strategy 11

$
$$
$

Designing a DNS Naming Strategy for Active
Directory
! Making Initial Naming Decisions
! Using a Delegated Subdomain Name for the Internal
Network
! Using a Single DNS Name for Public and Private
Networks
! Using a Different DNS Name for Public and Private
Networks
! Designing a DNS Solution to Integrate with BIND
! Design Guidelines


There are several ways that you can design a DNS naming strategy for the
Active Directory root domain. Most of these choices will reflect whether the
organization has, or plans to have, an Internet presence. If the organization
chooses to have an Internet presence you must decide whether to separate your
internally accessible resources from your externally accessible resources.
Depending on your Internet strategy and existing DNS implementations, you
can use one or more of the following guidelines:
!
Use a subdomain of a registered DNS domain name as the Active Directory
root.
!
Use the same DNS root domain name for your Active Directory structure
and Internet presence.

!
Use a different DNS domain name for your Active Directory root to
maintain separation between your Active Directory structure and your
Internet presence.

Slide Objective
To describe naming
strategies for Active
Directory and DNS.
Lead-in
Choosing what kind of DNS
name you will use for Active
Directory is based largely on
whether or not you
anticipate an Internet
presence for your network.
12 Module 2: Designing an Active Directory Naming Strategy


Making Initial Naming Decisions
! Registering the DNS Root Name
! Designing with an Existing DNS Implementation
! Determining Internal and External Naming Strategies
! Meeting Requirements of the DNS Design
! Assuring Client Name Resolution


There are important initial decisions you need to make when designing a DNS
naming strategy. The impact of not considering these items could necessitate a
re-installation of Active Directory in the future.

Registering the DNS Root Name
If you choose to have an Internet presence, you must obtain a registered DNS
domain name. Even if you do not anticipate an Internet presence, it is
recommended that you still register your chosen root name with ICANN so that
a future move to the Internet will not require renaming your root.
Designing with an Existing DNS Implementation
Windows 2000 DNS server service is recommended because it supports full
functionality with Active Directory. If you use the BIND DNS server, you will
need to make design choices based on your naming strategy. You may need to
upgrade your BIND servers, or opt to convert to Windows 2000 DNS.
Determining Internal and External Naming Strategies
If your organization has an Internet presence, securing the internal resources is
a priority. How you choose to separate your internally accessible resources
from your externally accessible resources will impact the design.
Slide Objective
To describe the first steps in
determining a naming
strategy.
Lead-in
An Internet presence is a
major decision factor in
choosing a DNS name for
the Active Directory root.
Module 2: Designing an Active Directory Naming Strategy 13


Meeting Requirements of the DNS Design
When determining the naming approach for your organization, make sure the
design meets the following requirements:
!

Expose only the public part of the organization’s namespace to the Internet.
!
Enable all Active Directory client computers to resolve all of the
organization’s internal and external names.
!
Make sure that client computers requiring access to the Internet can resolve
any names from the Internet.

Assuring Client Name Resolution to the Organization’s
External Resources
The external DNS server should only have resource records for the external
hosts and services that will be exposed to users of the Internet. To allow
internal clients to gain access to your organization’s 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 will
resolve the organization’s DNS names to an external IP address, and the
internal DNS servers will resolve the organization’s DNS name to an internal IP
address.
Assuring Client Name Resolution of Internet Hosts
Additional configuration may be required for the internal hosts to access public
Internet resources. You can configure the internal DNS server to forward all
irresolvable DNS requests to an external DNS server. If a proxy server is used,
create an exclusion list for the clients. The proxy server will forward all
requests received to an external DNS server.
Considerable planning will be required for the firewall to specify exactly what
types of traffic from internal clients will be allowed through the firewall to the
external network. This can be accomplished by using either a firewall or a
combination of a firewall and a proxy server.
14 Module 2: Designing an Active Directory Naming Strategy

Using a Delegated Subdomain Name for the Internal Network
Zone 2
Zone 1
contoso.msft
ad.contoso.msft
Firewall
Firewall
Firewall
! Create a New DNS Zone in New
Domain
! Configure Authoritative DNS
Server in Existing DNS Domain
to Delegate to New Domain
! Create Active Directory Forest
Root in New Domain


Instead of using the organization’s registered DNS domain name as the root
domain of Active Directory, you can use a DNS child domain. The child
domain exists in a separate zone, and is designated as the Active Directory root
domain. You should only expose the zone containing the DNS root domain to
the Internet.
For example, the company called Contoso, Ltd. decides to use the domain
ad.contoso.msft for its Active Directory root domain. The Contoso, Ltd.
Information Technology (IT) team must first do the following:
!
Create a new DNS zone on a separate DNS server that encompasses the
ad.contoso.msft domain.
!

Configure the DNS server that is authoritative for contoso.msft with a
delegation record to the other DNS server for the ad.contoso.msft domain.
!
Create the root of the Active Directory forest in the ad.contoso.msft domain.
The name of the Active Directory root domain will be ad.contoso.msft.

The implications of using a Delegated Subdomain Name for the Internal
Network are as follows:
!
This solution allows isolation of all Active Directory data in its domain or
domain tree.
!
This solution provides a contiguous namespace, creating less confusion for
the administrative staff and clients.
!
The delegated Active Directory root domain requires its own DNS server.
However, it does not require upgrading the DNS servers that currently serve
the existing registered DNS domain.
!
Active Directory name structure is longer because naming starts at a
third-level domain.

Slide Objective
To illustrate how to
implement an environment
in which a delegated DNS
subdomain is used as the
root of Active Directory.
Lead-in
Instead of using the existing

registered DNS name as the
root of Active Directory, you
can choose to use a
delegated DNS subdomain.
Module 2: Designing an Active Directory Naming Strategy 15


Using a Single DNS Domain Name for Public and Private Networks
Private Internal
Network
Zone for contoso.msft
with internal servers
Firewall
Firewall
Firewall
Zone for contoso.msft
without internal servers
Public Internet



You may want to retain a single DNS domain name for both internal and
external use. However, you want to ensure that the internal network is kept
separate from the Internet.
Separating DNS Zones by Using a Firewall
You can create two DNS zones with the same name on either side of a firewall,
and then manage the contents of those zones so that the appropriate records are
present in each. In this scenario, the DNS server on the public network would
maintain records only for hosts to be accessed from the Internet. The DNS
server on the internal network would have the resource records that would be

exposed to all internal hosts, including all resource records related to Active
Directory.
Using the firewall to separate DNS zones requires administration of the SRV
resource records. You must ensure that only the appropriate resource records
are exposed to external requests.
The implications of using a single DNS domain name for Public and Private
Networks are as follows:
!
Users can use a single domain name whether accessing resources from the
internal network or from the Internet.
!
Additional administration by the DNS administrators is required to ensure
the appropriate records are on the internal and external DNS servers.
!
Configuration of a firewall can be more complex when protecting the
internal network from the Internet.
!
No additional names need to be registered with the ICANN.
!
If external resources are mirrored on the internal network, synchronizing the
data can be challenging.

Slide Objective
To illustrate how to
implement an environment
in which a single domain
name can be used for both
public and private networks.
Lead-in
You do not need to use a

reserved local DNS name to
keep a part of your DNS
namespace private.
However, using a single
name both internally and
externally requires careful
planning.
Delivery Tip
Be sure that you spend
adequate time on this page
and the next one. They are
critical to the successful
completion of this lab.
16 Module 2: Designing an Active Directory Naming Strategy


Using a Different DNS Name for Public and Private Networks
Public Internet
Private Internal
Network
Zone for contoso.msft
without internal servers
Firewall
Firewall
Firewall
Zone for contosoltd.msft


An alternative to creating separate views of a single domain for public and
internal clients is to use different domain names for the public and private

networks. For example, Contoso, Ltd. could use contoso.msft on the public
network, and use contosoltd.msft for the internal network. This solution makes
the division of public and private resources very simple. All public resources
use one domain name, and all internal resources on the private network use
another domain name.
Assuring Client Name Resolution
Remember that you can allow clients to resolve external names for both your
organization and other Internet hosts by configuring the internal DNS server to
forward all requests it is unable to resolve to the external DNS server. For
proxy clients, create an exclusion list.
Considerable planning will be required for the firewall to specify exactly what
types of traffic from internal clients will be allowed through the firewall to the
external network. This can be accomplished by using either a firewall or a
combination of a firewall and a proxy server.
The implications of using a different DNS name for public and private networks
are as follows:
!
Resources are more manageable and secure because there is a clear
distinction between public and private resources.
!
The internal naming hierarchy is not exposed on the Internet.
!
Internal resources are inaccessible from the Internet by using the external
domain name.
!
You will no longer need to replicate external server content to internal
servers.
!
When accessing a company resource from the Internet, some users may be
confused by the different name.

Slide Objective
To illustrate how to divide
the DNS namespace into
public and private zones.
Lead-in
Another way to maintain a
distinction between the
private and public networks
is to use different domain
names for each network.
Module 2: Designing an Active Directory Naming Strategy 17


!
It may not be necessary to register additional names with ICANN.
!
You may need to upgrade DNS servers to provide support for SRV resource
records.
!
Existing DNS infrastructure and host names can remain unchanged and will
match the Active Directory domain name.
!
Existing DNS zones and DNS topology can remain unchanged.

18 Module 2: Designing an Active Directory Naming Strategy


Designing a DNS Solution to Integrate with BIND
To Integrate BIND and Microsoft DNS You Can
! Use Existing DNS Strategy as the Root of Active

Directory
! Create a Subdomain of the Existing DNS Strategy as the
Root of Active Directory
! Keep the Existing BIND DNS Strategy, and Register
Another Domain Name for the Root of Active Directory


If your organization mandates that existing BIND DNS servers be maintained,
you must decide how to integrate them with Microsoft DNS servers.
Strategy To Integrate:

Use existing DNS strategy
as the root of Active
Directory
On the BIND DNS server, create the following subdomains:
_msdcs.domainname
_sites.domainname
_tcp. domainname
_udp. domainname.
Create a subdomain of the
existing DNS strategy as
the root of Active
Directory
On the BIND DNS server, delegate the subdomain to the
Microsoft DNS server.
On the Microsoft DNS server, create the subdomain.
On the Microsoft DNS server, enable dynamic updates.
Configure the necessary Microsoft DNS Secondary servers,
or integrate the zones with Active Directory.
Keep the existing BIND

DNS strategy, and register
another domain name for
the root of Active
Directory
Create the primary zone on the Microsoft DNS server.
Create a secondary zone for the new domain on the BIND
server.
Create a secondary zone for the existing DNS name on the
Microsoft DNS server.

Slide Objective
To review strategies for
integrating BIND with Active
Directory.
Lead-in
Here are some strategies for
designing a DNS solution to
integrate with BIND.
If students ask, tell them
they can also delegate the
Microsoft-specific
subdomains to a Microsoft
Active Directory-enabled
DNS server.
Module 2: Designing an Active Directory Naming Strategy 19


Design Guidelines
Naming Strategies Include:
! Delegated Subdomain for the Internal Network

! Single DNS Name for Public and Private Networks
! Different DNS Name for Public and Private Networks


The table summarizes DNS naming strategy design choices and their
implications. The following flow chart represents a decision tree that is useful
for determining the appropriate naming strategy for an organization.
Design Choice Implications

Delegated subdomain for
the internal network
Isolates all Active Directory data from the public resources
in its domain or domain tree.
Contiguous namespace.
The delegated Active Directory root domain requires its
own DNS server.
Does not require upgrading any existing DNS servers.
Fully qualified domain names of hosts will be longer.
Single DNS name for public
and private networks
Users can use a single domain name.
Additional administration is required.
Configuration of a firewall can be more complex.
No additional names need to be registered.
Must synchronize with mirrored external resources.

Slide Objective
To review DNS naming
guidelines for the root
domain of Active Directory.

Lead-in
Here are some implications
of choosing the different
types of Active Directory
root domain names.
Delivery Tip
Discuss the job aid provided
on the subsequent page.
Tell the students the
decision tree summarizes
much of the information in
this module and will be used
in the lab for this module.