© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents
1. INTRODUCTION TO ORGANISATION-WIDE ACTIVE DIRECTORY PLAN............................................... ......................2 1.1. BACKGROUND INFORMATION........................................................................................... .........................2 1.2. ORGANISATION-WIDE ACTIVE DIRECTORY PLAN OBJECTIVES.......................................................... ................2 1.3. ORGANISATION-WIDE ACTIVE DIRECTORY PLAN SCOPE............................................................................. ....2 1.4. ORGANISATION-WIDE ACTIVE DIRECTORY PLAN PROCESSES...................................................... ....................3 1.5. DELIVERABLES OF ORGANISATION-WIDE ACTIVE DIRECTORY PLAN PROCESSES..................................................3 1.6. INTER-PROCESS DEPENDENCIES...................................................................................... ........................3 1.7. PROCESS TO CREATE THE ORGANISATION-WIDE ACTIVE DIRECTORY PLAN..................................... ...................4 2. DETERMINATION OF THE NUMBER OF FORESTS REQUIRED.......................................................................... .......5 2.1. PROCESS OBJECTIVES.................................................................................................................. .........5 2.2. BACKGROUND INFORMATION........................................................................................... .........................5 2.3. PROCESS APPROACH........................................................................................................................... ..5 2.4. PROCESS COMPONENTS.................................................................................................................... .....6 2.5. DELIVERABLES OF PROCESS COMPONENTS....................................................................................... ..........6 2.6. INTER-COMPONENT DEPENDENCIES........................................................................................................... 6 2.7. PROCESS TO DETERMINE THE NUMBER OF FORESTS REQUIRED................................................... ...................7 2.8. PROCESS CONSIDERATIONS..................................................................................................................... 7 3. DETERMINATION OF THE BOUNDARIES AND CONTENT OF EACH FOREST...................................... .......................26 3.1. PROCESS OBJECTIVES................................................................................................................ .........26 3.2. BACKGROUND INFORMATION........................................................................................ ..........................26 3.3. PROCESS APPROACH........................................................................................................................ ...27 3.4. PROCESS COMPONENTS.................................................................................................................. .....28 3.5. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........28 3.6. INTER-COMPONENT DEPENDENCIES........................................................................................................ .28 3.7. PROCESS TO DETERMINE THE BOUNDARIES AND CONTENTS OF EACH FOREST............................................... ...29 3.8. PROCESS CONSIDERATIONS.................................................................................................................. .29 4. DESIGN OF FEDERATED FOREST INFRASTRUCTURES.................................................................................. .....37 4.1. PROCESS OBJECTIVES............................................................................................................... .........37 4.2. PROCESS SCOPE...................................................................................................... .........................37 4.3. BACKGROUND INFORMATION........................................................................................ ..........................37 4.4. PROCESS APPROACH....................................................................................................................... ...41 4.5. PROCESS COMPONENTS.................................................................................................................. .....42 4.6. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........42 4.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .43 4.8. PROCESS TO DESIGN FEDERATED FOREST INFRASTRUCTURES................................................................... ....43 4.9. PROCESS CONSIDERATIONS.................................................................................................................. .43 5. DESIGN OF A DNS INFRASTRUCTURE................................................................................... .....................61 5.1. PROCESS PREREQUISITES..................................................................................................................... 61 5.2. PROCESS OBJECTIVES................................................................................................................ .........61 5.3. BACKGROUND INFORMATION........................................................................................ ..........................62 5.4. PROCESS APPROACH........................................................................................................................ ...64 5.5. PROCESS COMPONENTS.................................................................................................................. .....75 5.6. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........76 5.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .79 5.8. PROCESS TO DESIGN A DNS INFRASTRUCTURE................................................................... .....................79 5.9. PROCESS CONSIDERATIONS.................................................................................................................. .83 6. DESIGN OF OBJECT-NAMING MODELS............................................................................. ........................382 6.1. PROCESS OBJECTIVE............................................................................................... .........................382 6.2. PROCESS SCOPE................................................................................................... .........................382 6.3. BACKGROUND INFORMATION...................................................................................... ..........................383 6.4. PROCESS APPROACH...................................................................................................................... ...385 6.5. PROCESS COMPONENTS................................................................................................................ .....386 6.6. DELIVERABLES OF PROCESS COMPONENTS................................................................................... ..........386 6.7. INTER-COMPONENT DEPENDENCIES...................................................................................................... .386 6.8. PROCESS TO DESIGN OBJECT-NAMING MODELS................................................................................... ...387 6.9. PROCESS CONSIDERATIONS................................................................................................................ .387

Page 1 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

1.

Introduction to Organisation-Wide Active Directory Plan
Every organisation that wishes to design and deploy a Windows Server 2003 Active Directory infrastructure is required to create an “Organisation-Wide Active Directory Plan”. For definitions of the terms “Organisation” and “Windows Server 2003 Active Directory Infrastructure”, which may be confusing and open to misinterpretation, see the “Background Information” section of this introduction to the Organisation-Wide Active Directory Plan.

1.1.

Background Information The term “Organisation” refers to either an entire organisation or the largest singular structure within an organisation that wishes to design and deploy a Windows Server 2003 Active Directory infrastructure. Within some organisations, there may hence be several Active Directory infrastructures, designed and deployed by multiple divisional structures of an organisation. The term “Active Directory infrastructure” is a collective term that refers to all of the forests that the “organisation” is to design and deploy.

1.2.

Organisation-Wide Active Directory Plan Objectives Hence, based upon these definitions of “organisation” and “Active Directory infrastructure”, the objective of this organisation-wide plan is to assist an organisation in the design of the top-level components of an Active Directory infrastructure. These top-level components require design for application to all of the individual sub-components of an Active Directory infrastructure (such as the forest, site, and domain infrastructures). The following illustration depicts the relationship between the Organisation-Wide AD Plan and the other plans (forest, site, domain, and migration) within this design methodology:
MIGRATION PLAN DOMAIN PLAN FOREST PLAN ORGANISATION-WIDE AD PLAN
© 2004 MUSTANSHI
R

SITE PLAN

BHARMAL

Figure 2.1: Illustration of the Relationships between the Design Methodology Plans Each of the other plans for implementation of an Active Directory infrastructure build upon the results of the processes of each other as depicted above. In the above illustration, it is possible to see how this Organisation-Wide Active Directory plan provides the foundation for all of the other plans for implementation of an Active Directory infrastructure. 1.3. Organisation-Wide Active Directory Plan Scope The scope of this plan is to assist an organisation in defining and designing the following components of an Active Directory infrastructure for the organisation: • The definition of the scope and scale of the Active Directory infrastructure for an organisation via the determination of the number of forests required, and the boundaries and content of each required forest • The design of one or more intranet or extranet federated forest infrastructures for an organisation

Page 2 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• The design of one or more DNS infrastructures to support the Windows Server 2003 Active Directory infrastructure for an organisation • The design of a set of consistent, organisation-wide, object-naming models for Active Directory components and objects within the entire Active Directory infrastructure for an organisation Note that there was an intention to include the process to create a design for the security of the Active Directory and DNS infrastructures within an organisation. However, there is currently a plethora of excellent whitepapers and methodologies on securing Active Directory and DNS infrastructures, and hence these processes are out of scope of this design methodology. However, the specific absence of these processes from this design methodology for a Windows Server 2003 Active Directory infrastructure does not preclude the requirement for their execution. Thus, strongly recommend that all organisations investigate all of the factors and their considerations that will influence the design for a secure Active Directory and DNS infrastructure, and produce such a design as appropriate. 1.4. Organisation-Wide Active Directory Plan Processes Based upon the objectives and scope of this plan defined above, the creation of an organisation-wide Active Directory plan involves the creation of the following five components: 1. 2. Determination of the requirement for the design and deployment of a multiple forest infrastructure for the organisation Where the requirement to design and deploy a multiple forest infrastructure is identified, then there will be the requirement to: a. Determine the number of forests that are required for an organisation, at the time of design of this Active Directory infrastructure b. Determine the boundaries and content of each forest that is identified for design and creation within this organisation 3. 4. 5. Design of federated forest infrastructures for an organisation Design of one or more DNS infrastructures for an organisation Design of a set of consistent, organisation-wide, object-naming models for all Active Directory components and objects that have to be named at the time of creation within the entire Active Directory infrastructure for an organisation

1.5.

Deliverables of Organisation-Wide Active Directory Plan Processes The Organisation-Wide Active Directory plan will have the following deliverables: • The determination of the scope for the Active Directory infrastructure of this organisation based upon the number of forests required and the boundary and content of each forest that is required • The design of federated forest infrastructures for an organisation • The design of one or more DNS infrastructures for an organisation • The design of an organisation-wide object naming convention strategy for the Active Directory infrastructure of an organisation

1.6.

Inter-Process Dependencies Each process within the organisation-wide Active Directory plan will have the following interprocess dependencies:

Page 3 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Organisation-Wide AD Plan – Inter-Process Dependencies for Organisation-Wide AD Plan START
Determination of the number of forests required Determination of the boundaries and contents of each forest

Design of federated forest infrastructures

Design of a DNS Infrastructure

Design of object naming models
© 2004 MUSTANSHI
R

BHAR

MAL

1.7.

Process to Create the Organisation-Wide Active Directory Plan
Organisation-Wide AD Plan – Process to Create the Organisation-Wide AD Plan

START

Execute process “determination of the number of forests required” Execute process “design of object naming models”

Execute process “determination of the boundaries and contents of each forest” Execute process “design of DNS infrastructure”

Execute process “design of federated forest infrastructures”

END

© 2004 MUSTANSHI

R

BHAR

MAL

Page 4 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

2.

Determination of the Number of Forests Required
This process requires execution by all organisations planning the design and implementation of a Windows Server 2003 Active Directory infrastructure. It is important to supplement any pre-conceptions about the number of forests required for the organisation with the consideration of all the factors presented within this process before making a decision on the actual number of forests to design and deploy.

2.1.

Process Objectives The objectives of this process are to: • Allow an organisation planning a Windows Server 2003 Active Directory infrastructure to consider the factors that will influence the requirement for the design and deployment of a multiple forest infrastructure within the organisation. • Allow an organisation to determine the number of forests that are required to be design and deployed.

2.2.

Background Information A multiple forest infrastructure can provide many advantages and disadvantages to an organisation. It is hence important to make the decision to proceed with a multiple forest infrastructure only after careful evaluation of all of the associated advantages and disadvantages. This process will provide the factors that require consideration when determining the number of forests required. The advantages or disadvantages associated with the considerations for these factors are for the organisation to determine and input into the decision to proceed with a multiple forest infrastructure. This process introduces the concept of “federated” forests to an organisation considering a multiple forest infrastructure. A new feature of Windows Server 2003 Active Directory, the transitive forest trust relationship, provides the foundation for the concept of federated forests. A subsequent process (design of federated forest infrastructures) discusses the pre-requisites and design considerations for this new feature of Windows Server 2003 Active Directory.

2.3.

Process Approach When executing the process to determine the requirement for a multiple forest Active Directory infrastructure, the recommended approach is to “keep it simple”. This approach considers the administrative, operational, and financial connotations associated with a multiple forest infrastructure and hence implies the consideration of only a single forest, or a minimal number of forests. To support this recommendation, this design methodology states the following null hypothesis: “A single forest for an organisation can adequately meet all the Active Directory-related requirements for the organisation without the requirement to create a multiple forest infrastructure”. To determine the number of forests required for an organisation, it is necessary to execute an analysis to identify opportunities to disprove this null hypothesis. To support the above recommendations and null hypothesis for this process, this design methodology proposes execution of the following approach to determine the number of forests required for an organisation:

Page 5 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

1.

Understand the factors influential in supporting or disproving the null hypothesis for this process, and hence in the determination of the number of forests an organisation will require Execute an analysis to identify all applicable factors and determine the potential number of forests required Where it is possible to identify the potential requirements for the design and implementation of two or more forests, then execute the following: a. Define the criteria to qualify the requirements for two or more Active Directory forests b. Where applicable, identify the primary production forest for the organisation, and evaluate all other potential forest requirements against the defined criteria and determine the requirements for their design and implementation c. Determine the final number of forests required for the Active Directory infrastructure of an organisation

2. 3.

4.

Where it is possible to identify the requirement for the design and implementation of only one forest, then proceed to the next process, “determination of the boundaries and content of each forest”.

2.4.

Process Components Based upon the above approach, the process to determine the number of forests required for an organisation is composed of the following three components: • Understanding the factors influential in the determination of the number of forests required • Determination of the number of forests required for the organisation • Generation of the design for the number of forests required

2.5.

Deliverables of Process Components The process to determine the number of forests required will have the following deliverables: • An understanding of the factors influential in the determination of the number of forests required for the organisation • Definition of the criteria to qualify all requirements for the design and implementation of two or more forests • Evaluation of all potential multiple forest requirements against the defined criteria to determine the final number of forests required • Generation of the design for the number of forests required, and the identification of the function and role of each required forest within the organisation

2.6.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:

Organisation-Wide AD Plan – Inter-Component Dependencies for Process to Determine the Number of Forests Required START
Understanding the factors influential in determination of the number of forests required Determination of the number of forests required Generation of the design for the number of forests required
© 200 4 MUSTANSHI
R

BHAR

MAL

Page 6 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

2.7.

Process to Determine the Number of Forests Required
Organisation-Wide AD Plan – Process to Determine the Number of Forests Required
Execute B1 – B7 Execute A1 Is there a requirement for one or more additional forests? YES Execute D1

START

NO

END

Execute A2
© 2004 MUSTANSHI
R

BHAR

MAL

2.8.

Process Considerations Consider the following information when executing this process to determine the number of forests that are required for an organisation. Presented within the following three sections are the considerations for this process: 1. 2. 3. Understanding the factors influential in determination of the number of forests required within an organisation Considerations for the determination of the number of forests required Considerations for the generation of a design for the number of forests required

2.8.1.

Understanding Factors Influential in Determination of the Number of Forests Required Consider the following when attempting to understand the factors influential in the determination of the number of forests required for an organisation: • Factor B1: Understanding the approach to evaluate the factors influential in the determination of the number of forests required for the organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the required approach to evaluate the factors influential in the determination of the number of forests required ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology recognises two categories of factors influential in the determination of the number of forests required. These categories are:  Factors that support the opportunity to disprove the null hypothesis for this process, and hence the determination of the requirements for a multiple forest Active Directory infrastructure, and  Factors that support the null hypothesis for this process, and hence the design and implementation of only one forest, or a minimal number of forests within the Active Directory infrastructure This design methodology recognises the following factors as influential in the design and implementation of a multiple Active Directory forest infrastructure:  Requirements for service isolation  Requirements for service autonomy  Requirements for data isolation from service owners

Page 7 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

There are subtle but definite boundaries between these requirements. Discussed within the following sections of this process are the considerations for each of the above generic requirements. Note that the concept of a federated forest infrastructure aligns with the above requirements and is hence influential in the determination of the number of forests required. Hence, the factors discussed within each of the following sections of this process also represent the considerations for the Organisation-Wide Active Directory Plan process “design of a federated forest infrastructure” (see later for details). This design methodology recognises the following factors as influential in supporting the null hypothesis for this process:  The administrative overheads associated with a multiple forest infrastructure  The financial overheads associated with a multiple forest infrastructure • Factor B2: Understanding the influence of requirements for service isolation, on the number of forests required for an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of requirements for service isolation on the determination of the number of forests required for an organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The interpretation of service isolation can take the context of one of two possible scenarios:  Isolation of a forest component of the directory service (Active Directory) from other forest components of the directory service infrastructure within an organisation  Isolation of a forest component of the directory service (Active Directory) for an organisation from service administrators of the directory service The primary goal however, for both of these scenarios, is the prevention of service compromise to a component of the directory service infrastructure, from within the organisation. The nature of the compromise may take many forms, and each may prove a valid reason for an organisation to create and implement a separate forest. This design methodology recognises the following service isolation scenarios that may influence the requirements for multiple discrete forests:  Service isolation to support the retention of an existing service-isolated directory service infrastructure, during the migration to Windows Server 2003 Active Directory  Service isolation to support operational requirements  Service isolation to support financial and legal liability compliance requirements  Service isolation to support security requirements When attempting to understand the requirements to retain the service-isolated status of an existing legacy directory service, during migration to Windows Server 2003 Active Directory, consider the following:  The majority of migration projects from legacy Windows NT 4.0 or Windows 2000 directory service infrastructures, to a Windows Server 2003 Active Directory infrastructure, involve domain and (where applicable) forest consolidation. However,

Page 8 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

where organisations support one or more legacy directory service infrastructures (such as a Windows NT 4.0 or Windows 2000 Active Directory), and the foundations for their existence may reflect business and / or technical requirements for service isolation, then there may be the requirement to create multiple Windows Server 2003 Active Directory forests.  When determining the requirements to retain one or more existing legacy directory service infrastructures, as “service-isolated” Windows Server 2003 Active Directory forests during the migration, consider the following:  The existing legacy directory service infrastructures must demonstrate the requirements for service isolation to support either or both of the following: • Isolation of one or more components of the directory service infrastructure from all other directory service implementations within the organisation / production network infrastructure • Isolation of one or more components of the directory service infrastructure from service owners and administrators of other directory service implementations within the organisation  Where the existing legacy directory service infrastructure is unable to demonstrate compliance with the above criteria, then it is necessary to execute one of the following tasks for this infrastructure: • Consolidation, during migration, to one or more other directory service infrastructures within the organisation • Retention to support other business and / or technical requirements not related to service isolation • Decommissioning  Retention of the existing directory service infrastructure, to support service isolation, still requires compliance with the criteria to qualify the design and implementation of two or more Windows Server 2003 Active Directory forests (see later for details). When attempting to understand the influence of service isolation to support operational requirements, on the number of Windows Server 2003 Active Directory forests required, consider the following:  Service isolation permits a forest owner to manage all aspects of the forest discretely from other service administrators or processes within an organisation.  Independence in forest operation management places the onus on ensuring the operational continuity of the forest with the forest owner. This may be beneficial or even required where the operational continuity of an Active Directory forest has a direct influence on the business continuity of an aspect of the organisation represented by the boundary of this forest.  Consider the isolation of mission-critical directory-enabled applications from the network operating system directory service requirements of an organisation, to prevent disruption in the operation of these applications. A separate forest would permit this requirement via:  Generation of a discrete security boundary for the application to prevent a security breach where, for example, an administrator of a forest (coerced or maliciously) compromises the correct operation of a domain controller / directory service component or configuration within a forest. This may hence cause a disruption to normal directory service operation that will affect any directoryenabled applications, services, or processes that reply upon the directory

Page 9 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

service, and hence cause a disruption to business continuity. A separate forest for mission-critical directory-enabled applications permits a security barrier to prevent such disruptions to a dependent directory service.  Generating a service barrier to prevent, for example, the execution of poorly designed / unplanned / unmanaged configuration changes to critical components of the directory service or member servers within an organisation. For example, implementation of a change to the Active Directory Schema, if not carefully evaluated and tested, or merely inappropriate, may disrupt the operation of mission-critical directory-enabled applications that rely upon certain object classes and attributes within the Schema for correct operation. This may hence have a direct impact on business continuity.  Consider the design and deployment of a separate forest within an organisation to mimic a live, production forest for the organisation. As an essential component of an Active Directory change control infrastructure for an organisation, the serviceisolated, parallel, non-production forest permits an organisation to develop and test all planned changes to the production forest prior to rollout.  Note that for such a parallel forest to be effective, it must exactly emulate all aspects and components of the production forest. Consider the use of a metadirectory solution to synchronise all changes between the forests (only in the direction from the production to the test forest). Examples of changes to an Active Directory infrastructure that should be tested include:  The deployment of new directory-enabled applications that modify the Schema for the forest  The deployment of new Group Policy Objects at the Site, domain, or OU level  The moving of objects within and between domains When attempting to understand the influence of service isolation to support financial and legal liability compliance requirements, on the number of Windows Server 2003 Active Directory forests required, consider the following:  Isolating forests from security and service level compromises within an organisation can ensure compliance with financial and legal liability requirements. Where an Active Directory forest infrastructure directly supports business applications or processes, which require internal or external auditing for operational efficiency, it may be imperative to ensure the continuity of the forest.  Presented below are examples of the application of this factor to warrant the creation of multiple forests to meet service isolation requirements:  A hosting organisation with several clients can design and deploy a separate forest for each client. The financial and legal liabilities for the hosting organisation can be limited where a security or service level compromise occurs within one of these forests. Note that either the hosting organisation or the client the forest supports may be the source for the security or service level compromise.  An organisation has recently merged with / acquired another organisation and the integration of the operations for the two organisations is to occur over a long period. Until the integration is complete, both organisations must operate as separate legal and financial entities. The creation of separate forests for these two organisations permits the isolation of the financial and legal liabilities of these two organisations from a service level or security compromise within a forest for either organisation.

Page 10 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When attempting to understand the influence of service isolation to support security requirements, on the number of Windows Server 2003 Active Directory forests required, consider the following:  The requirement for one or more service-isolated forests naturally implies that the aspect or component of the organisation that the forest(s) require isolation from must not have access to the domain controllers for the isolated forest(s).  It is hence imperative that a separate forest, created specifically for service isolation, be complimented with the following security precautions:  All domain controllers for a service-isolated forest must hence be network and physically secured from all other aspects or components of the organisation.  The use of networking security technologies such as Internet Protocol Security (IPSEC) and firewalls can isolate domain controllers for a forest on a shared network.  The use of access controlled physically secured server rooms for these domain controllers can isolate them from other administrators within an organisation.  Consider the creation of separate forests for service isolation to enforce an effective security barrier between the forests. The compromise of a domain controller configured as a Global Catalog server for a forest can directly compromise the service integrity of all of the domains within the entire forest and all data and resources controlled by the forest.  Separate forests with physically isolated and secured domain controllers create a security barrier that can protect the integrity of the entire forest and the organisation. For example, consider separate forests for physical locations within an organisation that are potentially vulnerable to attack and compromise. As an example, a military Navy vessel could represent a “physical location” (within the context of resident users) that is highly vulnerable to attack and compromise (falling into the control of an enemy of a country). Limiting the boundary for compromise to the Navy vessel via the use of separate forests per vessel is an effective approach for protecting the entire military organisation from a compromise incident. When considering the requirements for design and implementation of a service-isolated Windows Server 2003 Active Directory forest, and one or more intranet or extranet federated forest infrastructures, consider the following:  As discussed above, requirements for service isolation demand either:  Isolation of a forest against a service and security breach in the operation of that forest within an organisation, or  Isolation of a forest to contain and limit the use and exposure of that forest within an organisation  The concept of federated forests contradicts the isolation of a forest to contain and limit the use and exposure of that forest within an organisation by publishing the presence, operation, and content of that forest to other forests within an organisation.  However, a service isolation forest, created to protect a forest from a service or security breach within an organisation, is able to participate within a federated multiple-forest infrastructure. A service-isolated forest does not imply a data-isolated forest, and hence where inter-forest data and resource sharing is required, this forest can participate in such infrastructures. However, a primary consideration prior to participation must be compliance with the security and service boundaries of this forest.

Page 11 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 It is possible to design the security infrastructure associated with forest trust relationships to comply with the security and service boundary requirements of a service-isolated forest. For example, the use of selective authentication for a trustrelationship and the prevention of the authentication of specific name suffixes both comply with the security requirements of a service-isolated forest. • Factor B3: Understanding the influence of requirements for service autonomy, on the number of forests required for an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of requirements for service autonomy on the determination of the number of forests required for an organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Service autonomy implies the ability to allow administrators within an organisation to be independently responsible for the management of all or part of the components of the directory service. To allow the application of this management model it is possible to apply service autonomy at the domain-level or at the forest-level of an Active Directory infrastructure, thus requiring the generation of multiple domains within a forest or multiple forests within an organisation. This design methodology recognises the following service autonomy scenarios that may influence the requirements for multiple discrete forests:  Service autonomy to support the retention of an existing service-autonomous directory service infrastructure, during the migration to Windows Server 2003 Active Directory  Service autonomy to support technical requirements  Service autonomy to support business requirements When attempting to understand the requirements to retain the service-autonomous status of an existing legacy directory service, during migration to Windows Server 2003 Active Directory, consider the following:  Where an organisation currently supports one or more autonomous departments or other divisional structures, and one or more of these divisions currently have their own service-autonomous directory service infrastructure, there may be a requirement to retain the status of this infrastructure during migration to Windows Server 2003 Active Directory.  When determining the requirements to retain one or more existing legacy directory service infrastructures, as “service-autonomous” Windows Server 2003 Active Directory forests during the migration, consider the following:  The existing directory service infrastructures must demonstrate the requirements for service autonomy. For example, there must be a requirement to isolate the management of forest-level components of a Windows Server 2003 Active Directory infrastructure from service owners and administrators of other directory service implementations within the organisation.  Where the existing legacy directory service infrastructure is unable to demonstrate compliance with the above criteria, then it is necessary to execute one of the following tasks for this infrastructure:

Page 12 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Consolidation, during migration, to one or more other directory service infrastructures within the organisation • Retention to support other business and / or technical requirements not related to service autonomy • Decommissioning  Retention of the existing directory service infrastructure, to support service autonomy, still requires compliance with the criteria to qualify the design and implementation of two or more Windows Server 2003 Active Directory forests (see later for details). When attempting to understand the influence of technical requirements for service autonomy on the number of Windows Server 2003 Active Directory forests required, consider the following:  Forest-level service autonomy allows independent management of the following forest-level components of an Active Directory infrastructure:  The Schema partition  The Configuration partition  Forest-level activities, such as the creation, modification, and management of domains, domain trees, and so on  Where an organisation can identify the following technical requirements for autonomous management of forest-level components, then a separate forest may be warranted:  Autonomous management of the Schema partition: • The Schema partition of a forest can be updated (with new object classes and attributes) or modified (to, for example, deactivate object classes and attributes, and modify the publication of attributes to the Global Catalog for the forest). • It is feasible to implement a separate forest where there is a requirement to limit the scope of updates or modifications to the Schema within an organisation. • Also, consider separate forests where there is a requirement to limit the scope of use of a mission-critical directory-enabled application (that modifies the Schema with new object classes / attributes) to specific users / divisions within an organisation.  Autonomous management of the Configuration partition: • The configuration partition for a forest stores forest-wide data that is essential to the operation of a forest. • The only aspects of a configuration partition for a forest that may require any management and possible limitation in scope within an organisation via a separate forest may be the design and management of display specifiers for the Active Directory Schema of a forest. • Display specifiers control the graphical user interface for the Active Directory MMC management snap-ins, are stored within the Configuration partition, and hence have a forest-wide application.

Page 13 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Autonomous management of naming contexts within a forest: • A Windows Server 2003 Active Directory forest will support five default naming contexts: ♦ The Schema partition ♦ The Configuration partition ♦ The domain partition for the forest root domain ♦ The DomainDNSZones default ADP ♦ The ForestDNSZones default ADP • A division within an organisation may require autonomy over the management of existing and new naming contexts within the forest, such as the creation of new domains and custom ADPs, and so on.  Autonomous design and management of Active Directory replication infrastructure for a forest  Differing management policies: • A division within an organisation may not agree with approval routing path, structure, and components of the change control process for Schema and Configuration partition management, as it may preclude their involvement or say. • Without unified agreement on the management of these forest-level components of an Active Directory infrastructure, separate forests may be the only feasible option.  Autonomous management of inter-forest integration requirements: • A forest owner is responsible for the management of inter-forest trust relationships. For example, divisions or sub-components of an organisation wish to implement and manage inter-forest trust-relationships. Because some trust-relationships may be a viewed as a security concern and management overhead for the rest of the organisation, these divisions / sub-components of the organisation may hence opt for a separate forest to limit the security and management scope of these trust-relationship(s). When attempting to understand the influence of business requirements for service autonomy on the number of Windows Server 2003 Active Directory forests required, consider the following:  Forest-level service autonomy allows the management of Active Directory forests to ensure compliance with specific business requirements.  Presented below are examples of business requirements that, where identified within an organisation, may warrant the creation of separate forests:  A strictly decentralised administration model for the Active Directory infrastructure of an organisation may require, in some instances, separate domains, or even separate forests. Organisations comprised of multiple independent subcompanies would struggle to accommodate all autonomy requirements for each sub-company under the umbrella of a single forest, let alone domain, or even Organizational Unit infrastructure.

Page 14 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Merged or acquired organisations may require (even after integration) a degree of service autonomy, provided by a discrete service-autonomous forest. For example, the service level agreements (SLAs) for the directory service infrastructure of a parent organisation do not meet the requirements of the merged or acquired organisation. The identification of this scenario allows the consideration of a discretely designed, deployed, and managed forest tailored to comply with specific SLA requirements of the merged or acquired organisation.  Requirements to support spin-offs and divestitures within an organisation may support the requirements for the design of discrete, service-autonomous, forests. For example, within some organisations, it may be possible to identify certain departments or divisions, limited by the boundaries of the organisation that can thrive in an autonomous environment. The design, deployment, and management of a separate forest would support these requirements. When considering the requirements for design and implementation of a serviceautonomous Windows Server 2003 Active Directory forest, and one or more intranet or extranet federated forest infrastructures, consider the following:  Forests created to meet requirements for service autonomy require the definition of a boundary for operation and management of the forest within an organisation. This boundary hence does not imply an extension for inter-forest data and resource sharing.  Service-autonomous forests are hence able to participate within a federated forest infrastructure. However, a primary consideration prior to participation must be compliance with the boundaries for operational autonomy of this forest.  As stated earlier, the associated security infrastructure for a forest trust relationship can assist in ensuring the integrity of the autonomous operation of such a forest by allowing the careful screening of authentication from within the federated forest infrastructure. • Factor B4: Understanding the influence of requirements for data isolation from service owners, on the number of forests required for an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of requirements for data isolation from service owners on the determination of the number of forests required for an organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: There is a myth that a Windows Server 2003 Active Directory domain represents a security barrier for data protection from other domains within a forest. The reality is that the design of the Windows Server 2003 Active Directory infrastructure permits forest and domain owners to access all data and resources controlled by any component of the forest. Consider the following prior to understanding the influence of the requirements for data isolation from service owners on the number of forests required:  Due to the distributed replication topology of an Active Directory forest, domain controllers from one domain within the forest cannot be isolated from others in the forest. It is hence necessary to ensure they are both network and physically secured.  A forest owner (a member of the Domain Admins group in the forest root domain) can gain access to any data held on any member computer within the forest. For example, a domain owner could explicitly deny access for the forest Enterprise

Page 15 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Admins group to their domain. However, via membership of the Schema Admins group, the forest owner could modify the default security descriptor on an object class to grant the Enterprise Admins group full control over all newly created objects of that class within the forest. The completion of this operation prior to the population of the forest with objects of that class, such as computer accounts and so on, permits the forest owner absolute undeniable access.  A domain owner can gain access to any data held on member computers within other domains. A modification to the system software on a domain controller to interfere in the correct operation of any domain in the forest can accomplish this, thus allowing the domain owner to view or manipulate data stored on any computer joined to the forest. This design methodology recognises the following scenarios for data isolation from service owners, which may influence the requirements for multiple discrete forests:  Data isolation from service owners to support the retention of an existing restricted access directory service infrastructure, during the migration to Windows Server 2003 Active Directory  Data isolation from service owners to support access control to highly sensitive data within an organisation  Data isolation from service owners to support legal and strategic requirements for data isolation When attempting to understand the requirements to retain the restricted access status of an existing legacy directory service, during migration to Windows Server 2003 Active Directory, consider the following:  Where the current data isolation requirements arose due to mistrust between the current service owners within an organisation, and there is to be a re-organisation of the administration model for the new Active Directory infrastructure, then it is important to attempt to re-establish this trust.  If it is impossible to re-establish the trust between the service owners due to, for example, previous incidences, political differences, or compliance with legal requirements, then it is necessary to determine the current data isolation requirements of the sub-component of the organisation.  Where no alternative component of an Active Directory infrastructure (domain or OU) can provide the same level of data isolation currently required, then it may be necessary to retain the current model via the creation of a separate forest. For example, a sub-company within an organisation currently has a legacy (Windows NT 4.0) multiple domain infrastructure catering for their requirements for data isolation from the parent organisation. Where no alternative is suitable, it is feasible to upgrade this legacy infrastructure to a separate Windows Server 2003 Active Directory forest within the organisation. When attempting to understand the influence of requirements to control access to highly sensitive data within an organisation, on the number of Windows Server 2003 Active Directory forests required, consider the following:  Within most organisations supporting centralised IT and / or security departments, the forest and domain owners within an Active Directory infrastructure are typically not the directors of an organisation, as they cannot be involved in the routine management tasks for these roles. Instead, the forest and domain owners are usually senior members of an IT or security department.  Departments within an organisation that generate and manage highly sensitive information relating to the function of the organisation, the clients, and partners of

Page 16 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

the organisation, or the employees of the organisation, may or may not trust the forest and domain owners within the IT department. The mistrust may be due to previous incidences, new or unknown IT administrators and internal proposals to generate a decentralised administration model, and so on.  Regardless of the cause of the mistrust, where it exists, then the department / division of the organisation may have concerns over the security of the sensitive data they generate and manage. These concerns, if validated at the organisationallevel, may justify the creation of a separate forest to provide a secure barrier for the data or resources.  For example, the Human Resources department of an organisation typically creates and manages remuneration data for employees of the organisation. A separate forest to host the servers for the HR department may allow the secure management of this data within the organisation. When attempting to understand the influence of legal requirements for data isolation within an organisation, on the number of Windows Server 2003 Active Directory forests required, consider the following:  Depending upon the nature and function of an organisation, the organisation may be required to comply with externally enforced data security requirements or face legal consequences for security breaches.  For example, a law firm, which manages the legal requirements for several businesses, either received sensitive data from their clients, or generates and manages sensitive data about their clients. The law firm is under legal obligation to ensure the security of this data on behalf of their clients. The law firm intends to hold the data on servers within their internal Active Directory forest. However, to ensure compliance with legal obligations, the clients may require the creation of a separate forest for the servers to hold this data to prevent any security breaches from within the law firm. In some scenarios, clients may even require the use of a trusted third party managed services organisation to manage the separate forest, a secure network infrastructure for the forest, and physical security for the domain controllers and file servers in the forest.  The creation of a separate forest may support the strategic safeguard of certain resources within the organisation from other forest and domain owners. For example, the organisation provides various services to sub-companies and controls their use and billing. The organisation might strategically place the resources used to provide these controls within a separate forest to prevent their tampering or intrusion by forest or domain owners. When considering the requirements for design and implementation of an access restricted Windows Server 2003 Active Directory forest to support data isolation from service owners, and one or more intranet or extranet federated forest infrastructures, consider the following:  Forests created to meet requirements for data isolation from service owners demand strict isolation of an entire forest from non-trusted service owners within an organisation. This may hence preclude these forests from an organisation-wide federated forest infrastructure.  This does not totally exclude, however, the potential for these forests to participate within a federated forest infrastructure where the trusted service owners manage the other member forests.  For example, a large division within an organisation has identified the requirement for two forests to service the Active Directory requirements of just that division. These two forests could hence participate within a federated forest infrastructure,

Page 17 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

within this component of the organisation, where the forest owners either are the same or implicitly trust each other. • Factor B5: Understanding the influence of administrative overheads for multiple forests, on the number of forests required for an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of administrative overheads for multiple forests on the determination of the number of forests required for an organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Each forest that requires design and implementation is associated with a significant number of management overheads that require consideration. The management overheads associated with a multiple forest infrastructure depend upon the current and required administration model of an organisation. Where an organisation currently has (and wishes to retain) a decentralised administration model and the boundaries of each component of the current administration model will map to the boundaries of each required forest, there will not be any noticeable overall increase in administrative overheads. However, where an organisation wishes to move to, or currently has (and wishes to retain), a strictly centralised administration model, the overheads for forest management will noticeably increase with each forest to be designed and deployed within the organisation, as the single administration team will have to manage all of the forests. For each forest created within an organisation, this design methodology anticipates the requirements for discrete management of the following:  Forest-level components such as the Schema and Configuration partitions, and the Global Catalog service  Other directory partition of the forest (such as domain and application directory partitions)  Change control infrastructure, and so on Where multiple Windows Server 2003 Active Directory forests within an organisation participate within a federated forest infrastructure, this infrastructure will also require design, monitoring, and management. Management issues may arise where an organisation wishes to use, for example, an organisation-wide directory-enabled application (for example, Microsoft Exchange 2000 or Exchange Server 2003) that will store data within a directory partition of a forest, but the organisation has a multiple forest infrastructure. As the boundary for an Exchange 2000 or Exchange Server 2003 infrastructure is the forest, the Global Address List (GAL) for the messaging infrastructure will only reflect objects within the forest. Where an organisation requires the design and implementation of multiple forests, then several GALs may be required. To support the generation of a single GAL, there may be a requirement to design and implement a directory synchronisation solution. The product, “Microsoft Identity Integration Feature Pack for Microsoft Active Directory”, is suitable to synchronise multiple Windows Server 2003 Active Directory forests and GALs.

Page 18 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Note that there may hence be overheads associated with the design and support of the access and authorisation model, which will support this application, the application data, and the clients of the application distributed across a multiple forest infrastructure. The design and deployment of a multiple forest infrastructure within an organisation may generate operational issues that will directly affect the user community of an organisation. Presented below are example scenarios of such issues. Scenario 1: An organisation has two Windows Server 2003 Active Directory forests (“Forest A” and “Forest B”), integrated via a forest trust relationship. Users within the organisation wish to be able to roam within the organisation and the computers they can use to logon with frequently cross the logical boundaries of the two forests. Hence, for example, a user has a user account in a domain in “Forest A”, and wishes to logon using a computer that is a member of a domain in “Forest B”. At the logon dialog box, the user does not see their domain because “Forest B” has no knowledge of the existence of their domain in “Forest A”. Hence, the user will have to use their user principal name (UPN) to logon on. To support such a scenario, functional levels for both forests must be at the “Windows Server 2003” level, and the UPNs must be unique within both forests of the organisation. Scenario 2: An organisation has two Windows Server 2003 Active Directory forests not integrated via a forest trust relationship or any external trust-relationships. Users that require access to resources within both forests may hence require multiple user accounts and passwords. The use of cloning tools can assist in allowing a user account within both forests to retain the same user name (providing there are no conflicts) but the domain names will differ. Hence, each time a user logs on, depending upon the forest account the user is using, the domain name will have to be changed, and then may confuse the user, thus generating support requests. Scenario 3: An organisation has two Windows Server 2003 forests and a single Microsoft Exchange 5.5 organisation that requires upgrading. The single Microsoft Exchange 5.5 organisation holds the mailboxes for all of the users represented within both Windows Server 2003 forests. This scenario hence presents the organisation with many challenging issues to resolve, to facilitate the continued operation of an upgraded Microsoft Exchange infrastructure. Where an organisation can identify the requirement to ensure data / resource access between components of an organisation, potentially separated by forest boundaries, consider the following:  There will be significant financial, management, and operational overheads and issues associated with the design, deployment, and management of a forestintegration strategy to permit inter-forest data and resource access.  There will be a lost opportunity to implement a single and simple organisation-wide authentication and authorisation model due to the creation of a multiple forest infrastructure. • Factor B6: Understanding the influence of financial overheads for multiple forests, on the number of forests required for an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of financial overheads for multiple forests on the determination of the number of forests required for an organisation

Page 19 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Each forest that requires design and implementation is associated with significant financial overheads, and the accumulation of each overhead generated by each forest will raise the total cost of ownership (TCO) for each forest. The financial overheads associated with each required forest reflect the total cost of ownership of the forest for its design, testing, implementation, operation, and management. Presented below are examples of where and how a forest can contribute to an increase in its total cost of ownership:  The design of a forest involves the creation of a design for multiple aspects of each forest. Hence, it is important to consider the time that will be required to produce and test each of the following four design components for each forest the organisation has identified a requirement for:  A forest plan that details the design of the forest-level components of the forest  A Site plan that details the design for the replication requirements of the forest  A domain plan (one domain plan is required for each domain to be created within each forest) that details the design for domain-level components of the forest  A migration plan that details the design for the migration to the required forest from a legacy / third party network operating system / directory service infrastructure  In order to deploy each forest, a minimum number of Windows Server 2003 domain controllers will be required. Hence, it is important to consider the server hardware, operation, licensing requirements, monitoring, physical security requirements, and management costs associated with each domain controller required. If there is the requirement to represent multiple domains from multiple forests in an organisation with multiple physical locations, this will hence increase the number of domain controllers that are required, and hence the associated financial overheads and TCO for each forest.  The operation of a multiple forest infrastructure within an organisation can have an impact on the resources shared by the forests. For example, within an organisation hosting multiple forests, the logical forests may all share common physical components of the organisation, such as:  The supporting LAN and WAN network infrastructure (where it is common to all forests)  A secure computer room for the domain controllers and servers within the forests, and so on  Where the shared resources are over utilised, then there may be the requirement to increase an aspect of the resource, which will inevitably have an associated financial overhead.  Organisations with strict centralised administration models for an Active Directory infrastructure will have increased utilisation for the human resources required to manage all the forests within the organisation. Where these resources are over utilised for the concurrent management of multiple forests, then there may be a financial overhead to increase the number of administration staff to cope with the increased management duties. In addition, it is important to consider the financial overheads for the additional training requirements for all administration resources.

Page 20 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

2.8.2.

Determination of the Number of Forests Required Consider the following information when determining the number of forests required for the Windows Server 2003 Active Directory infrastructure of an organisation: • Factor B7: Understanding the approach to determine the number of forests required for the organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the required approach to determine the number of forests required for the organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Following an evaluation of the factors discussed above as influential in determination of the number of forests required, it is necessary to execute an analysis to determine the forest requirements for the organisation. The organisation will require a minimum of one forest, which will typically be the primary production forest for the organisation. Hence, all investigations to disprove the null hypothesis for this process must reflect requirements for the design and implementation of one or more additional forests. This design methodology proposes execution of the following approach to determine the number of additional forests required for the organisation:  Evaluate all factors, and their considerations listed above, that support the following:  The opportunity to disprove the null hypothesis for this process, and hence the requirements for the design and implementation of a multiple forest infrastructure  The null hypothesis for this process, and hence the requirements for the design and implementation of a single Active Directory forest  Identify all factors applicable to the organisation. Where the organisation is unable to identify any applicable factors, then the null hypothesis for this process holds true, and a single Windows Server 2003 Active Directory forest is required.  Where the organisation is able to identify one or more applicable factors, then it is necessary to execute the following steps:  Document the nature and details of the requirements that reflect the applicable factors  Define criteria to qualify the requirements for the design and implementation of two or more Windows Server 2003 Active Directory forests within the organisation  Evaluate all identified requirements for additional forests, based upon applicable factors, against the defined criteria and determine the number of forests required. The following factors, within this step for this process, will assist an organisation in the execution of the above approach. • Factor A1: Determination of factors applicable to the organisation, and influential in the determination of the number of forests required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the factors applicable to the organisation, and influential in the determination of the number of forests required.

Page 21 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the factors applicable to the organisation, which may influence the number of forests required, this design methodology proposes execution of the following approach:  Evaluate all factors that support the design and implementation of two or more Windows Server 2003 Active Directory forests within the organisation  Execute an analysis within the organisation to determine the applicability of any of these factors and their considerations.  Where it is possible to identify the requirements to design and implement one or more additional Windows Server 2003 forests, then document the details of the identified requirements.  Where it is not possible to identify any factors applicable to the organisation, then it is necessary to design and implement only one Windows Server 2003 Active Directory forest for the organisation. When executing an analysis to identify the applicability of the factors within the organisation, consider the following:  As the design and implementation of Windows Server 2003 Active Directory forests is a significant step within most organisations, it is imperative that all stakeholder and affected departments and divisions are involved in the decision making process. Hence, it is necessary to present and discuss the factors influential in the determination of the number of forests to the appropriate personnel and decision makers within the organisation.  For example, within a global organisation, supporting multiple autonomous divisions, one remote division in Singapore may have a justifiable requirement to implement an Active Directory-enabled application, which modifies the Schema. As only this division will use this application, the organisation may wish to restrict the scope of the Schema modification, and hence sanction the design and implementation of a discrete forest for this division. Hence, unless this division is involved in the discussion to determine the number of forests required, the organisation may not acknowledge this requirement.  The form factor for the presentation and discussions may vary between organisations, depending upon the size of the organisation, the geographical distribution, the structure of the IT administration model, the presence of autonomous divisions within the organisation, and so on.  The ideal form factor for this presentation and discussion is an interactive analysis workshop. However, a simple questionnaire, distributed to the appropriate personnel within the organisation, may suffice within some organisations. It is important to keep all discussions centralised, with one or a few personnel managing the requirements for multiple forests, and documenting all comments and requests.  When determining the applicability of factors, it is important to assess their short, medium, and long-term applicability. For example, an organisation may have medium-term plans to divest several divisions, which may require manifestation within a few months. However, to facilitate the divestiture of these divisions from the parent organisation, and to minimise disruption to the continuity of the entire organisation, it may be necessary to design and implement discrete forests for these divisions.  It is also important to stipulate a timeframe for completion of all discussions and input into the decisions for the number of forests required.

Page 22 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Using the above information and approach, execute the following:  Identify all personnel within the organisation that may require involvement within the decision to determine the number of forests required  Organise a presentation and discussion with the identified personnel to determine the applicability of any of the listed factors and hence the requirements for the design and implementation of one or more additional forests.  Collate and document all comments, requests, and requirements that will influence the requirements for a multiple forest infrastructure • Factor A2: Definition of criteria to qualify requirements for a multiple forest infrastructure, and evaluation of requirements against these criteria ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has completed the execution of an analysis of factors influential in the determination of the requirements for a multiple forest infrastructure  Has identified the potential requirements for the design and implementation of one or more additional forests (to the mandatory primary forest for the organisation), and  Wishes to define the criteria to qualify the requirements for the design and implementation of a multiple forest infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When defining the criteria to qualify the requirements for the design and implementation of a multiple forest infrastructure, consider the following:  The criteria to qualify the requirements for a multiple forest infrastructure must reflect all identified business and technical design goals for the Windows Server 2003 Active Directory infrastructure, and the management and financial overheads associated multiple forests.  It is important to note that these criteria are to qualify the requirements for two or more forests. It is also possible to apply these criteria to determine the number of forests required for autonomous divisions within an organisation. For example, an organisation is required to support multiple autonomous divisions, and each division will be required to execute an independent migration from their legacy directory service infrastructure(s) to the new single Windows Server 2003 Active Directory infrastructure for the parent organisation. In this scenario, the parent organisation is required to define how many forests they require, as the entire organisation, via these criteria. However, the organisation may also reverse these criteria for their autonomous divisions, and state, for example, the null hypothesis: “All autonomous divisions within this organisation are required to join the single forest / specific forest for the parent organisation, unless they can demonstrate compliance with the criteria to support the design and implementation of one or more additional forests”  The onus is then with the autonomous divisions to identify any business and technical requirements, which may support the design of one or more additional forests specific to that division, via compliance with the criteria defined by the parent organisation. Note that where an autonomous division cannot provide compliance with the criteria and is hence required to join an existing or proposed forest, the parent organisation may provide flexibility to support the representation of that division as an independent domain within the forest, or representation within an

Page 23 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

existing domain in a forest. This is possible via the provision, by the parent organisation, of criteria to qualify requirements for additional domains within a forest.  Similar to the approach to determine the requirements for multiple forests, it is necessary to involve all appropriate personnel in the definition of the criteria to qualify requirements for additional forests within the organisation.  Note that the onus is with the organisation to decide which personnel to invite to assist in the definition of the criteria to qualify requirements for multiple forests. This design methodology recommends, where possible, exclusion of stakeholders in the requirements for additional forests, as they may have a stake in definition of the criteria to accept their specific requirements for one or more additional forests.  Due to significant short and long-term impact within an organisation, of the design and implementation of a multiple forest infrastructure, the criteria to qualify the requirements for multiple forests require objective, and not subjective definition.  Although the onus is with the organisation to define their specific criteria, this design methodology proposes the following examples of criteria to qualify the requirements for the design and implementation of a multiple forest infrastructure:  The requirement for an additional forest must reflect a requirement associated with the execution of this project, and not independently of this project to design and implement a Windows Server 2003 Active Directory infrastructure. (This criterion reflects the requirement for consideration and qualification of additional forest requirements authorised by the organisation, and not existing legacy or new forests, designed and implemented by autonomous divisions within the organisation).  The requirement for an additional forest must reflect one of the following factors supported by this organisation: • The requirements for service isolation from service owners, to support genuine business and technical requirements • The requirements for data isolation from service owners, to support genuine business and technical requirements • The requirements for service autonomy, to support discrete financial budgets within autonomous divisions  Any autonomous divisions that require the design and implementation of an additional forest are required to take responsibility for all financial and administrative overheads with its design, testing, implementation, operation, and management, in compliance with directives <x, y, and z>. Using the above information and approach, execute the following:  Define the criteria to qualify the requirements for the design and implementation of each additional forest, to the primary production forest for the organisation.  Evaluate all potential forest requirements, from the previous analysis, against these defined criteria, and document the results.  Determine the final number of forests required. 2.8.3. Generation of the Design for the Number of Forests Required Consider the following information when determining the viability for the design, deployment, operation, and management of each forest required within an organisation:

Page 24 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor D1: Generation of the design for the number of forests required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has executed the analysis to determine the requirements for the design of one or more Windows Server 2003 Active Directory forests, and  Wishes to generate the design for the number of forests required ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Whether the organisation has identified the opportunity to disprove or support the null hypothesis for this process, it is necessary to execute the appropriate analysis to determine these requirements, and document them within a design document. This step within this process will assist an organisation in the generation of the design for the number of forests required. This design methodology proposes the following format and content for the design of the number of forests required:  A detailed description of the process adopted by the organisation to present and discuss all factors influential in the determination of the number of forests required  A detailed description of the results of the discussions to identify applicable factors, influential in the determination of the number of forests required  Where an organisation was unable to identify any applicable factors, then include a statement to describe why.  Where an organisation identified one or more applicable factors, then the design document must detail the following:  All of the potential (and unqualified) requirements for these factors  The details of the criteria to qualify the requirements for the design and implementation of a multiple forest infrastructure  The results of the evaluation of identified requirements against the defined criteria  Where the results of the evaluation against defined criteria has identified the requirements for the design and implementation of one or more additional forests, then detail the forest requirements, identifying the following:  The criteria compliance profile for the requirement  The nominated owner(s) of the additional forests  The function and role of the additional forest within the organisation

Page 25 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

3.

Determination of the Boundaries and Content of Each Forest
This process requires execution by all organisations planning the design and implementation of a Windows Server 2003 Active Directory infrastructure, regardless of whether the organisation has identified the requirement for a single or multiple forest Windows Server 2003 Active Directory infrastructure.

3.1.

Process Objectives The process to define the boundary and content of a forest will identify all of the logical and physical components (users, computers, network infrastructure, and so on) of an organisation that will support the operation and existence of a forest, and that the forest will represent, where appropriate, as objects. This process will illustrate that the function, role, and objectives of each required forest within an organisation will influence their boundary and content. Hence, the objectives of this process are to assist an organisation in execution of the following: • The proactive determination of the logical and physical boundary and content for each forest within the organisation, identifying, for example: ♦ Boundary: The logical (departments, divisions, teams of users, network topology and so on) physical (offices, locations, network links and so on) placement of each forest within an organisation and on a supporting network infrastructure for the organisation ♦ Content: The logical and physical components of an organisation, such as directoryenabled applications and their data, the user and computer accounts and other objects (such as printer objects, File Volume Share objects and so on) that will be held and represented by each forest to be designed and implemented within the organisation • Use of the determined boundary and content information of each forest for input into complimentary process within the Site and Domain Plans for each forest

3.2.

Background Information Where an organisation has identified the requirement for a single forest, then it does not necessary assume that the boundary and content of the forest will encompass all of the appropriate physical components of an organisation, which could support the existence and operation a forest. The following examples illustrate this proposition: • Example 1: A manufacturing organisation is able to assign high-level categories to employees based upon their role within the organisation. Employees are hence categorised as either been employees assigned manufacturing duties or employees assigned administration duties within the organisation. Based upon the role of the manufacturing employees within the organisation, it may not be possible to identify the requirements for the representation of all or most of these employees within an Active Directory forest for this organisation. Hence, the boundary and content of this forest will not represent all employees of the organisation. • Example 2: An organisation wishes to design and deploy a test or parallel forest. This forest is required to logically emulate a large, geographically distributed production forest but on a fraction of the physical scale, placing the entire test forest in a single server room. The function of this forest will hence provide it with the same logical boundary and content as the production forest, with respect to the logical representation of the physical components of the organisation as objects within this forest. However, the function and scale of this forest means that it will not have the same physical boundary and content as

Page 26 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

the production forest, with respect to the physical and network infrastructure required to support this forest. • Example 3: An organisation wishes to design and deploy a Windows Server 2003 Active Directory forest specifically to support a directory-enabled application. This forest will not hold the majority of the primary user and computer accounts for employees and computers within the organisation. Hence, the server(s) that will operate the directory-enabled application, and the supporting network infrastructure for the application and the forest, represent the boundary and content of this forest. As can be illustrated by the above examples, the function, and role of a Windows Server 2003 Active Directory forest within the organisation, directly influences the boundary and content of the forest within the organisation. Note that this design methodology requires that during execution of this process, it is necessary to pair the logical and physical components of a forest to specific forests within the organisation only at the highest level possible. For example, reflect the function and role of the forests using the geographical and functional components of the organisation (such as divisions or departments), and the not individual objects within these geographic and functional components. 3.3. Process Approach This design methodology recommends the proactive determination of the boundaries and contents of each required forest, and not the passive acceptance of an undefined boundary and content. Proactive determination of the boundaries and contents of each required forest is essential to ensuring, for example, the security of the forest, and maintaining the continuity of forest operation. To reflect the objectives of this process, to determine the boundaries and contents of each required forest, it is necessary to identify all components of an organisation that require representation within an Active Directory forest, and correspondingly, do not require representation within the forest. This design methodology hence states the following null hypothesis for this process: “All logical and physical components of an organisation, which may support or be represented and supported by, a Windows Server 2003 Active Directory forest, are within the scope of each required forest”. Following statement of this null hypothesis, it is hence necessary to determine the requirements to disprove it, and, if successfully disproved, identify any components of an organisation outside of the scope of the forest. Execution of this analysis will hence define the logical and physical boundaries and contents of each required forest. To support the above recommendation and null hypothesis, this design methodology proposes the following approach for execution of this process: 1. Understand the components of an organisation, which typically support a Windows Server 2003 Active Directory forest, or are represented and supported by an Active Directory forest, and may be outside of the scope of a required forest. Define the criteria for exclusion of components from the boundary and scope of a forest Select a required forest, and execute the following: a. Execute an analysis of all potentially in-scope logical and physical components of an organisation, and evaluate all identified components against the defined exclusion criteria.

2. 3.

Page 27 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

b. Identify all components that require exclusion from the boundary and content of the required Active Directory forest for this organisation. 4. 5. 3.4. Repeat the above steps for each required forest within the Active Directory infrastructure Generate the design for the boundaries and contents of each required Active Directory forest

Process Components Based upon the above approach, the process to determine the boundaries and content of the required forests is composed of the following three components: • Understanding components of an organisation potentially outside of the scope of a forest • Determination of the boundaries and contents of each required forest • Generation of the design for the boundaries and contents of each required forest

3.5.

Deliverables of Process Components The process to determine the boundaries and content of the forests will have the following deliverables: • An understanding of the components of an organisation, typically represented and supported by an Active Directory forest, which may be outside of the scope of a forest • Definition of the criteria to qualify the exclusion of components from the scope of a forest • Identification of all components of an organisation potentially outside of the scope of a forest • Determination of the boundary and content of each required forest • Generation of a design for the high-level boundaries and contents for each required forest for an organisation

3.6.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Organisation-Wide AD Plan – Inter-Component Dependencies for Process to Determine the Boundaries and Contents of Each Forest START
Understanding components of an organisation potentially outside of the scope of a forest Determination of the boundary and contents of each forest Generation of the design for the boundary and contents of each forest
© 2 0 0 4 MU S TAN SH I
R

BHARMAL

Page 28 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

3.7.

Process to Determine the Boundaries and Contents of Each Forest

Organisation-Wide AD Plan – Process to Determine the Boundaries and Contents of Each Forest
Is it possible to identify any components that require exclusion? YES

START

Execute B1 – B2

Execute A1

NO

Execute D1

END

Execute A2
© 2004 MUSTANSHI
R

BHAR

MAL

3.8.

Process Considerations Consider the following information when determining the boundaries and content for each required forest within an organisation: • Factor B1: Understanding the components of any organisation potentially outside of the scope of a forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to design and implement one or more Active Directory forests, and  Wishes to understand the components of an organisation that may be outside of the scope of a required forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology defines “components” of an organisation, with respect to the scope of a forest, as the following:  Physical components of an organisation, such as:  Employees of an organisation  Computers running Windows NT 4.0 or later operating systems, and all resources supported by the computers  Network infrastructure components that support the operation of an Active Directory infrastructure, such as network cables, switches, hubs, firewalls, routers, and so on  Geographical locations, offices, and so on  Logical components of an organisation, such as:  Departments and divisions within the organisation  Operations and processes within the organisation  Network architecture components When attempting to understand the components of an organisation that may require exclusion from the scope of an Active Directory forest, consider the following:

Page 29 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The components of an organisation that require identification for exclusion are all physical and logical components of an organisation that:  May support the routine operation of an Active Directory forest  Require representation and support by an Active Directory forest  Are currently in existence and operation within an organisation  Are proposed for design and implementation within an organisation, within the lifetime of this project  This design methodology provides the following examples of components of an organisation that may potentially support the routine operation of an Active Directory forest:  Existing server computers within the organisation, operating as domain controllers for a legacy directory service infrastructure  A wide area network (WAN) link between two offices for an organisation that currently or potentially may support replication between domain controllers within each location  A LAN segment and subnets that may support intra-Site replication between two or more domain controllers  This design methodology provides the following examples of components of an organisation that a Windows Server 2003 Active Directory forest may potentially support and represent:  Client and server computers within an organisation  Employees of an organisation  Applications, services, processes, and resources within an organisation • Factor B2: Understanding the approach towards determination of the boundaries and contents of each required forest for an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach towards determination of the boundaries and contents of each required forest for an organisation. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When executing a proactive determination of the boundaries and contents of each required Active Directory forest, it is important to understand and consider all potential consequences of these steps on the operation of the organisation and the forest. Hence, this design methodology proposes execution of the following approach to qualify all proactive requirements to define the boundaries and contents of a required forest:  Using the information provided in factor B1 of this process, execute an analysis within the organisation to identify all components of an organisation, at a very highlevel, that may require proactive exclusion, and hence disprove the null hypothesis.  Define criteria to qualify the requirements for the proactive exclusion of identified components from the scope of an Active Directory forest

Page 30 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Evaluate all identified components against the defined criteria, and determine the boundaries and contents of each required forest • Factor A1: Identification of components of an organisation that potentially require exclusion from the scope of an Active Directory forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to identify all components of an organisation that may potentially require exclusion from the scope of an Active Directory forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When executing this step, to define the potential and initial (unqualified) boundaries and contents of each required forest, consider the following:  The objective of this process is to disprove the null hypothesis for this process. The null hypothesis for this process states that every component within an organisation, which may support or require representation within an Active Directory forest, requires inclusion within the scope of the forest. Hence, this process must proactively identify all components of an organisation that require exclusion from the scope of each or all required forests. Where it is not possible to identify the requirements for the exclusion of any components from the scope of an Active Directory forest, then execution of this process has proactively validated the null hypothesis for this process.  Where an organisation has identified the requirements for the design and implementation of a single forest, then disproving this null hypothesis is a single step process. However, where an organisation has identified the requirements for the design and implementation of two or more forests, then disproving this null hypothesis involves execution of the following two-step process:  Identification of the components of an organisation that require exclusion from the scope of all required Active Directory forests.  Identification of the components of an organisation that require exclusion from the scope of each required Active Directory forest. Note that all components of an organisation, not excluded from all forests, will logically require inclusion within at least one of the multiple required forests, and hence this step must partition in-scope components between the required forests. When identifying all potential components of an organisation that may require exclusion from the scope of an Active Directory forest, consider the following:  For the majority of components of an organisation, it is a very simple process to determine the requirements for their inclusion or exclusion from the scope of a forest. However, for some components of an organisation, there may be uncertainty as to the requirements for their proactive inclusion or exclusion from the scope of a forest. In addition, there may be a requirement to qualify the exclusion of components from an Active Directory forest.  It is important to define criteria for the identification of potential components of an organisation that require exclusion from the scope of a forest. Although the onus is within the organisation to define their criteria, this design methodology provides the following (example) criteria:  The organisation is uncertain as to the requirements for the inclusion or exclusion of the identified components

Page 31 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The identified components may be shared by two or more forests, and hence the organisation is uncertain as to the inclusion or exclusion of these components from the scope of specific required forests  Examples of components which may potentially require Active Directory forest for an organisation are:  Computers required to retain membership of existing legacy domains which cannot be upgraded or decommissioned  Computers required to operate as standalone servers, for example, to provide a service whilst logically located between firewalls at a network perimeter  Computers that operate non-Microsoft operating systems and hence will not be represented within a forest infrastructure  Logical components of a network infrastructure that will not transmit any Active Directory-related network data  Divisions and departments of users that, on the basis of their assigned roles within an organisation, do not require representation within, or use of any component or aspect of, a forest infrastructure for an organisation. Using the above information, execute the following:  Generate a high-level list of all components of an organisation, which the organisation can proactively include within the scope of one or more forests. This design methodology provides the following examples of such a list:  All users within the organisation currently represented within an existing, legacy, directory service infrastructure and within the scope of migration to the new Active Directory infrastructure.  All client and server computers currently represented within an existing, legacy, directory service infrastructure and within the scope of migration to the new Active Directory infrastructure.  All network components within buildings 1, 2, 3 and 4 of the London campus, and so on  Identify all other components within an organisation, at a high-level, that comply with the criteria for potentially residing outside of scope of all forests  Where an organisation has identified the requirements for the design and implementation of two or more Active Directory forests, then select a required forest, and determine all components that potentially require exclusion from the scope of that forest. Repeat for each required forest.  For each required forest, document all components of an organisation that potentially require exclusion from the scope of that forest. • Factor A2: Definition of criteria to qualify the exclusion of specific components of an organisation, identified as potentially outside of the scope of one or more required forests ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified one or more components of the organisation that potentially requires exclusion from the scope of one or more required forests, and

Page 32 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to define the criteria to qualify the requirements for the exclusion of specific identified components from the scope of one or more required forests ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When assessing the requirements for the exclusion of components of an organisation from the scope of an Active Directory forest, and the qualification of these requirements via criteria, consider the following:  The criteria to qualify requirements for the exclusion of components must consider the consequences that may arise from the exclusion and inclusion of these components. The targets for the consequences that require analysis include the influence of the decision on the operation and continuity of the organisation and the forest(s).  This design methodology recognises the following factors influential in the definition of the criteria to qualify the exclusion of components from the scope of an Active Directory forest:  The security implications from the exclusion / inclusion of components from the scope of an Active Directory forest  The administrative overheads from the exclusion / inclusion of components from the scope of an Active Directory forest  The financial overheads from the exclusion / inclusion of components from the scope of an Active Directory forest  The role(s) of each required forest within the organisation  The logical and physical placement of each required forest within the network infrastructure for the organisation When considering the security implications associated with the inclusion or exclusion of components of an organisation from the scope of an Active Directory forest, consider the following:  For each potential component that requires exclusion from the scope of an Active Directory forest, the criteria to qualify these requirements must reflect considerations for the security implications.  For example, the exclusion of a computer from the scope of an Active Directory forest, or all required forests within an organisation, requires this server to be a standalone server. This computer is hence vulnerable to attack and compromise, as it is not access control protected by a domain infrastructure, and associated policies, and so on. Hence, all resources supported by this server are potentially vulnerable to compromise.  It is also necessary to consider the reverse scenario. For example, the function of a server is to provide services and access to resources to clients, and as the clients of the server require access exclusively via the Internet, the organisation places the server within a partitioned firewall, or demilitarised zone (DMZ). Due to the location of the server in this network location within the organisation, it is vulnerable to attacks from the Internet, and hence inclusion of this server into the scope of an Active Directory forest may compromise the integrity of the forest. When considering the administrative overheads associated with the inclusion or exclusion of components of an organisation from the scope of an Active Directory forest, consider the following:

Page 33 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 For each component of an organisation, which requires exclusion from the scope of an Active Directory forest, it is necessary to consider any associated administrative overheads to maintain and operate these components. For example, the exclusion of a server from the scope of an Active Directory forest will require the manual management of its local SAM database, access control to resources controlled by that server, via its local SAM database, deployment of operating system and software patches, and so on.  Where or organisation requires the exclusion of one or more components from one forest, but inclusion within the scope of another required forest, and it is possible to identify requirements for inter-forest resource access, then this may generate significant administrative overheads. In conjunction with the function and role of a forest within an organisation, the design and implementation of inter-forest trust relationships between these forests may breach the security requirements of the forests. Hence, it is necessary to consider both resource and service access and inter-forest authentication and authorisation requirements, when determining the boundaries and contents of multiple forests within an organisation. When considering the financial overheads associated with the inclusion or exclusion of components of an organisation from the scope of an Active Directory forest, consider the following:  Where there is a requirement to impose the strict alignment of one or more components within an organisation to one required forest, and these components are required by other forests, then there may be a financial overhead associated with this partitioning of components. For example, an organisation has identified the requirements for the design and implementation of two forests. Within each physical location where the domain controllers for domains for the forest require representation, the organisation wishes to ensure segregation of the servers for each forest. Hence, there is a requirement to procure and implement multiple racks for the servers, to support physical segregation of domain controllers for each forest, and hence this requirement may generate significant financial overheads.  To ensure the operation continuity of an Active Directory forest, there may be a requirement to segregate the administration teams between the forests, to ensure a dedicated support infrastructure. This may hence increase the financial overheads associated with each required forest. When considering the influence of the role of a required forest on the inclusion or exclusion of components of an organisation from the scope of an Active Directory forest, consider the following:  As discussed within the process, “determination of the number of forests required”, an organisation may require one or more discrete forests to support service isolation, service autonomy, or data isolation from service owners.  The creation of a forest to comply with requirements for service isolation / service autonomy / data isolation allows the logical deduction of the following facts:  That there is a decentralised administration model within an organisation as the requirements for service isolation / service autonomy / data isolation all demand discrete forest ownership and management.  Only a sub-component of an organisation or minority representation within an organisation can request a dedicated forest to meet one or more of the requirements for service isolation / service autonomy / data isolation. Hence, it is possible that there is at least one other primary Active Directory forest for the organisation that represents the majority of the organisation.

Page 34 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where a separate, primary forest for the organisation exists, then the forest created for service isolation / service autonomy / data isolation may have a smaller boundary and scope.  Decentralised administration models within an organisation usually arise via, for example, mergers, acquisitions, and divestitures within an organisation, or widely geographically distributed components of an organisation.  A decentralised administration model within an organisation may hence imply that physical components, typically represented within a forest, are married to the boundaries of the scope of management for a component of a decentralised administration model. Note however that this may not be strictly true for all such identifiable scenarios, but it does hold true for the majority.  For example, it may be feasible to state that a forest to be owned and managed by an IT department (that is a component of a distributed administration model) will represent within its boundary and scope all physical components (users, computers, network infrastructure and so on) managed currently, or in the future, by this IT department.  Consider forests created to retain current requirements for service isolation / service autonomy / data isolation for components of an organisation. The boundaries and content of a legacy infrastructure created to support these requirements may remain the same for the new forest. When considering the requirements for the logical and physical placement of a required forest on the network infrastructure, on the inclusion or exclusion of components of an organisation from the scope of an Active Directory forest, consider the following:  The function and role of a forest within an organisation will determine the logical placement of a forest on a supporting network infrastructure. This will hence determine the network infrastructure boundaries for a forest within an organisation.  Multiple forests can be logically placed on the network infrastructure for an organisation within one of three possible environments:  A forest can be logically placed within the “complete” (non-segregated) production (or live) network infrastructure for an organisation. This environment provides unlimited network access to all resources (users, computers, applications, and so on) within the entire organisation that operate on the “complete” production environment.  Logically place a forest within a “partitioned” component of the production network infrastructure for an organisation. This environment provides resources and services the organisation depends upon for business continuity, but there is partitioned network access between other production environments within the organisation.  Logically place a forest within a network-isolated, non-production (e.g. test or development) component of the network infrastructure for an organisation. This environment provides resources and services used for research, development and testing, and hence does not directly influence the business continuity of the organisation. Using the above information, execute the following:  Define the criteria to qualify the exclusion of potential components from the boundary and scope of an Active Directory forest, to reflect the following considerations:

Page 35 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Security considerations associated with the inclusion or exclusion of components from the scope of a forest  Administrative and financial overheads associated with the inclusion or exclusion of components from the scope of a forest  The influence of the role of each required forest within an organisation, on the influence of the inclusion or exclusion of components from the scope of a forest  The influence of requirements for the physical and logical placement of each required forest within the network infrastructure, on the influence of the inclusion or exclusion of components from the scope of a forest  Evaluate all identified components, which potentially require exclusion from the scope of a forest, against the defined criteria, and hence determine the boundaries and contents of each required forest. • Factor D1: Generation of the design for the boundaries and contents of each required forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has determined the boundaries and contents of each required forest, via the identification of all components that require exclusion from each forest, and  Wishes to generate the design for the boundaries and contents of each required forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes that the design for the boundaries and contents of each required forest comprise the following format and contents:  A detailed design document detailing the following:  The physical and logical components of an organisation that require explicit inclusion within the scope of each required forest  The physical and logical components of an organisation that potential required exclusion from the scope of each required forest  The details of the criteria used to qualify the exclusion of components from the scope of one or more required forests  A diagram illustrating the logical components of an organisation that will define the boundaries and contents of each required forest  A diagram illustrating the physical components of an organisation that will define the boundaries and contents of each required forest

Page 36 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

4.

Design of Federated Forest Infrastructures
This process requires execution by all organisations planning the design and implementation of a Windows Server 2003 Active Directory infrastructure, regardless of whether the organisation has identified the requirement for a single or multiple forest Windows Server 2003 Active Directory infrastructure. Transitive forest trust relationships are a new feature of Windows Server 2003 Active Directory that permit the design and deployment of a federated forest infrastructure. A federated forest infrastructure creates the perspective of a forest as a partition of an Active Directory infrastructure that can span one or more organisations.

4.1.

Process Objectives The objective of this process is to assist an organisation in execution of the following: • Determination of the requirements for design of one or more federated forest infrastructures, either spanning forests within an organisation or forests between organisations, and • Where there is a requirement to design and implement one or more federated forest infrastructures, then determination of the design requirements, and generation of the design for each required federated forest infrastructure.

4.2.

Process Scope The number of forests the organisation has identified for design and implementation will define the scope of an intranet federated forest infrastructure. Note that the scope for this process is the creation of forest trust relationships between forests for resource and data access and sharing. Hence, this process does not cover: • The design and implementation of intra-forest (short-cut) trust-relationships (which is a component of the Forest Plan), or the process to design and implement external trust relationships between an Active Directory forest and a Windows NT 4.0 domain, and Kerberos Realm Trust relationships (which are components of the Domain Plan). • The design and implementation of a directory integration solution for the exchange and synchronisation of directory data between forests

4.3.

Background Information Prior to execution of this process, to design and implement one or more intranet or extranet federated forest infrastructures, it is necessary to understand the following concepts associated with forest trust relationships. Presented within the following three sections are the background information considerations for federated forest infrastructures: 1. 2. 3. Concept of a federated forest infrastructure Types of federated forest infrastructures Facts about Windows Server 2003 Active Directory forest trust relationships

4.3.1.

Concept of a Federated Forest Infrastructure A federated forest infrastructure is comprised of two or more forests linked together via transitive forest trust relationships. The result is an Active Directory infrastructure where the primary partitions of this infrastructure are forests, and secondary partitions are domains,

Page 37 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

custom application directory partitions, and the Schema and Configuration partitions of each member forest. The following diagram illustrates an example of a federated forest infrastructure. In this example, an organisation with six forests has decided to create two federated forest infrastructures:
Federated Forest Infrastructure 1

Bidirectional Transitive Forest Trust Relationships

Forest 1

Forest 6

Forest 2

Forest 5 Forest 3

Forest 4

Federated Forest Infrastructure 2
© 2004 MUSTANSHI BHAR

R

MAL

Figure 5.1: Example of Federated Forest Infrastructures 4.3.2. Types of Federated Forest Infrastructures This design methodology proposes the opportunity for an organisation to design and implement the following two types of federated forest infrastructures: 1. 2. An intranet federated forest infrastructure An extranet federated forest infrastructure

An intranet federated forest infrastructure will only support two or more member Windows Server 2003 forests implemented within the boundaries of an organisation. An extranet federated forest infrastructure will support member Windows Server 2003 Active Directory forests within an organisation and outside of the boundaries of an organisation. For example, an organisation may wishes to collaborate with an external partner organisation, to share resources between the organisations via an extranet federated forest infrastructure. 4.3.3. Facts about Forest Trust Relationships Prior to execution of this process, it is important to acknowledge and understand the following facts about forest trust relationships: 1. 2. 3. The pre-requisites that require compliance to create one or more forest trust relationships, and hence federated forest infrastructures The nature of forest trust relationships The concept of forest trust authentication levels

Page 38 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

4. 5. 4.3.3.1.

The concept of routing hint suffixes for forest trust relationships The concept of forest trust SID filtering Pre-requisites for Creation of Forest Trust Relationships

Prior to the design and implementation of a Windows Server 2003 Active Directory forest trust relationship, it is necessary to ensure compliance with the following strict prerequisites: • All member forests must be Windows Server 2003 Active Directory forests. It is only possible to establish forest trust relationships between the forest root domains of Windows Server 2003 Active Directory forests. • All Windows Server 2003 forests must be operating at the “Windows Server 2003” forest functional level. Forest trust relationships are available for creation only when a forest is operating at the highest functional level. It is only possible to attain this functional level for a forest when all domain controllers within the forest are operating on Windows Server 2003 (see the Forest Plan process “selecting and raising the functional level of a forest” for details). 4.3.3.2. Nature of Forest Trust Relationships A forest trust, similar to an external trust relationship, is one-way only, and hence for a bidirectional trust-relationship, two one-way trust-relationships (in opposite directions) require creation. When creating a forest trust, the trust direction options presented are: • A two-way trust relationship • A one-way (incoming) trust relationship • A one-way (outgoing) trust relationship Note that although a forest trust relationship is transitive between connected forests, the transitivity of the forest trust does not extend to other forests within the federated forest infrastructure, but just to the domains within the two forests directly connected by the forest trust. Hence, using the example illustrated in figure 5.1 above: • Resources within a domain in “Forest 1” are accessible only by users within domains in “Forest 2” and “Forest 6”, as they have forest trust relationships with “Forest 1”. • However, users in a domain in “Forest 5” cannot access resources within a domain in “Forest 1” unless the organisation establishes a one- or two-way forest trust relationship between “Forest 1” and “Forest 5”. A federated forest infrastructure does not have a single shared Schema or Global Catalog. A common, but not shared, schema will be present amongst all member forests of a federated forest infrastructure only where all forests still retain the default, unmodified, schemas. A federated forest infrastructure does not permit, by default, a shared application data configuration, and data set amongst all member forests, where the pre-defined boundary for the configuration data and data set for a directory-enabled application is a partition within the forest or the entire forest. If the boundary for the configuration data and data set of a directory-enable application is extensible to encompass multiple forests, via (for example) a client LDAP interface that can bind to multiple forests, then it is possible to share this application, its configuration and data amongst the members forests of a federated forest infrastructure.

Page 39 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

4.3.3.3.

Forest Trust Authentication Level It is possible to configure a forest trust relationship to perform either “forest-wide authentication” or perform “selective authentication”. The “forest-wide authentication” option permits Active Directory to authenticate users (from the specified forest) automatically for all resources within the local forest. This option is suitable for an intranet federated forest infrastructure for an organisation. The “selective authentication” option ensures that Active Directory will not authenticate users (from the specified forest) automatically for any resources in the local forest. Hence, it will be necessary for an organisation to grant access to each domain and server that the organisation wishes to make available to users in the specified forest. The scope of selective authentication for trust-relationships is forest wide. It is possible to set “selective authentication” differently for incoming and outgoing forest (and external) trust relationships. With “selective authentication”, access is allowed by setting the “allowed to authenticate” access control entry (ACE) on the local resource to the security principal from the specified forest / domain. The “selective authentication” option is suitable for an extranet federated forest infrastructure. The configuration of a forest trust to use selective authentication establishes an authentication firewall for the forest trust between the forests. The following diagram illustrates an example of the authentication firewall concept between two forests, forest 1 (forest root domain “F1”) and forest 2 (forest root domain “F2”). The forest owner for forest 1 has configured an incoming forest trust for Forest 1 to use selective authentication. This creates an inbound authentication firewall between forest 1 and forest 2. The forest owner of forest 1 (and domain owners within forest 1) will then assign permissions to data / resources within forest 1 to security principals pulled across the inbound forest trust from forest 2. In this example, “User1” in domain F2 (F2\User1) is added to the access control list for a shared folder published within domain “D1.F1”. However, none of the domains owners in forest 1 has granted access to resources in forest 1 to “User2” in domain “D1.F2”. This hence blocks “User2” from authenticating to domains within forest 1. Hence, the authentication firewall between forest 1 and forest 2 has “ports” open allowing inbound authentication requests only from those security principals in forest 2 selected by data / resource owners / managers in forest 1.
Forest Trust configured to use Selective Authentication
User1

Forest 1

E1.com ACL Shared Folders E2.E1.com D1\User1 User2 D2.D1.com

D1.com

Forest 2

© 2004 MUSTANSHI

R

BH

AR MAL

Figure 5.2: Example of Selective Authentication for Forest Trust Relationship 4.3.3.4. Routing Hint Suffixes A forest trust relationship supports Kerberos V5 authentication between Windows Server 2003 Active Directory forests as well as NTLM authentication. However, an organisation must establish routing hints where Kerberos V5 authentication is required across a forest trust relationship. Routing hints help direct the authentication requests to the destination forest. When an organisation creates a forest trust between two Windows Server 2003 Active Directory forests,

Page 40 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

by default the forest trust routes all unique name suffixes (a name suffix within a forest (e.g. a UPN or SPN) that is not a subordinate to any other name suffix). Name suffixes are hence configured with an asterisk (*) that prefixes the unique name suffix, such as “*.Natsum.com.”. Hence all child domains of “Natsum.com.”, such as “*.ChildA.Natusm.com.”, will be routed because the child domains are part of the “Natusm.com.” unique name suffix. Automatic updates to the unique name suffixes occur during the lifetime of the forest trust relationship. However, the “Properties” dialog box of the trust-relationship (in the “Routing Name Suffix” tabbed page) permits manual configuration of unique name suffixes. This hence permits an administrator to prevent, for example, the routing of authentication requests to certain name suffixes within the forest. Hence, it is possible for an organisation to enable name suffixes, to enable routing of authentication requests to this name suffix, or disable name suffixes, to prevent routing of authentication requests to this name suffix. Note that when a name suffix is disabled, this will also disable all children of that DNS name. The objectives for the configuration of routing name suffixes, on a forest trust relationship, are to provide granular (at the naming suffix, and hence, domain-level) control over the scope of the trust relationship. Because a forest trust relationship is transitive by default, all domains within a forest can use the trust relationship. Hence, the use of routing name suffixes permits the exclusion of domains within a trusted forest from using the forest trust relationship. Note that it is not possible to enable a name suffix that conflicts with an existing name suffix. Upon detection of duplicate name suffixes, authentication requests will continue to route only to the first recorded instance of the name suffix. Duplicate name suffixes are disabled and hence do not have authentication requests routed to them. The collision detection feature of the trust relationships will also manage conflicts in domain SIDs with a name suffix SID, and duplication of NetBIOS names currently in use. It is possible to resolve authentication issues, caused by the disabling of duplicate name suffixes by the forest trust relationships, by evaluating the requirement to retain the first name suffix registered by the forest trust and disabling it (if possible) using the “Netdom” Windows Server 2003 Server Support Tool. This would then allow the registration of the duplicate name suffix and hence allow it to receive authentication requests. Note that routing hints can only reference the trusted name suffixes for service principal names (SPNs) of resource computers. The trusted name suffixes are stored in the Trusted Domain Object (TDO) for the trust relationship (there is a unique TDO for each direction of a trust-relationship and it is stored in the domain). Note that routing hints do not verify the name suffix prior to sending the hint back to the original source computer requesting name resolution. A forest trust does not support access to NetBIOS names and Kerberos delegation. A forest trust provides full support for NTLM, and it is not possible to disable this challenge / response authentication protocol for a forest trust relationship. 4.3.3.5. Forest Trust SID Filtering All new external and forest trust relationships in Windows Server 2003 Active Directory have, by default, “SID Filtering” enabled. The function of this feature is to prevent attacks by users attempting to elevate the user rights associated with a user account. 4.4. Process Approach The design and implementation of one or more federated forest infrastructures within an organisation may be associated with financial and administrative overheads. Hence, this design methodology states the following null hypothesis for this process:

Page 41 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“Where an organisation identifies the requirements to support inter-forest access to shared resources and services, then the design and implementation of external, non-transitive trust relationships between forests will support the identified inter-forest access requirements, without the requirement for the design and implementation of one or more federated forest infrastructures”. Following statement of this null hypothesis, it is hence necessary to determine the requirements to disprove it, and, if successfully disproved, identify the requirements for the design and implementation of one or more federated forest infrastructures. To support the above recommendation and null hypothesis, this design methodology proposes the following approach for execution of this process: 1. 2. 3. 4.5. Determine the requirements for the design and implementation of one or more federated forest infrastructures Where it is possible to identify this requirement, then determine the design requirements for each required federated forest infrastructure Generate the design for each required federated forest infrastructure

Process Components The process to design an Active Directory forest integration strategy is composed of the following components: • Determination of the requirement for the design of one or more federated forest infrastructures • Determination of the design requirements for each required federated forest infrastructure • Generation of the design for each required federated forest infrastructure

4.6.

Deliverables of Process Components The process to design federated forest infrastructures will have the following deliverables: • Identification of the requirement for the design of one or more federated forest infrastructures within or between organisations • Definition of criteria to qualify: ♦ Compliance with prerequisites for the design and implementation of one or more federated forest infrastructures, and ♦ Feasibility of design and implementation of one or more federated forest infrastructures • Identification of the number and type(s) (intranet or extranet)of federated forest infrastructures required • Determination of the following design requirements for each required federated forest infrastructure: ♦ Identification of the member forests within each required federated forest infrastructure ♦ Determination of the number and direction of forest trust relationships required for each federated forest infrastructure ♦ Determination of the requirements for the configuration of routing hint suffixes for each required forest trust relationship

Page 42 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Determination of the requirements for the design of selective authentication for forest trust relationships • Generation of a design for each required federated forest infrastructure 4.7. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Organisation-Wide AD Plan – Inter-Component Dependencies for Process to Design Federated Forest Infrastructures START
Determination of the requirements for the design of one or more federated forest infrastructures Determination of the design requirements for each required federated forest infrastructure Generation of the design for each required federated forest infrastructure
© 2 0 0 4 MU S TAN SH I
R

BHARMAL

4.8.

Process to Design Federated Forest Infrastructures
Organisation-Wide AD Plan – Process to Design Federated Forest Infrastructures
Are there requirements to support interforest access? Are there any requirements for forest trusts?

START

Execute B1

Execute A1

YES

Execute A2

YES

Execute B2

Execute A3 NO NO

Execute D1

END
© 2004 MUSTANSHI R BHARMAL

4.9.

Process Considerations Consider the following information when executing this process to design one or more federated forest infrastructures for an organisation. Presented within the following three sections are the considerations for this process: 1. 2. 3. Considerations for the determination of the requirements to integrate multiple forests within and / or between organisations Considerations for the determination of the design requirements for each required federated forest infrastructure Considerations for the generation of the design for each required federated forest infrastructure

4.9.1.

Determination of the Requirement to Integrate Multiple Forests Consider the following information when determining the requirement to integrate multiple forests within an organisation and / or between organisations: • Factor B1: Understanding the approach to determine the requirements for the design and implementation of one or more federated forest infrastructures ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 43 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Has identified the requirements for the design and implementation of one or more internal Windows Server 2003 Active Directory forests, and  Wishes to understand the approach to determine the requirements for the design and implementation of one or more federated forest infrastructures ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As discussed in the background information section of this process, a federated forest infrastructure has only one function and objective, which is to support inter-forest resource and service access. A federated forest infrastructure is not a directory integration solution that consolidates and integrates multiple directories to permit attribute flow, provisioning and deprovisioning between directories and data repositories, and so on. Hence, it is necessary to execute this analysis, to determine the requirements for the design and implementation of one or more federated forest infrastructures, exclusively to identify requirements to support inter-forest access to shared resources and services. This design methodology proposes the following approach to determine the requirements for the design and implementation of one or more federated forest infrastructures:  Determine the requirements to support inter-forest access to shared resources and services  Document all identified requirements to support inter-forest access to shared resources and services  Define criteria to qualify the requirements for the design and implementation of one or more federated forest infrastructures  Evaluate all requirements to support inter-forest access to shared resources and services against the defined criteria  Determine and document the requirements for the design and implementation of one or more federated forest infrastructures • Factor A1: Determination of the requirements to support inter-forest access to shared resources and services ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements to support inter-forest access to shared resources and services ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to disproving the null hypothesis for this process, it is necessary to establish any requirements to support inter-forest access to shared resources and services. Hence, when determining the requirements to support inter-forest access to shared resources and services, consider the following:  To execute this process, it is necessary to determine requirements to support interforest access to shared resources specifically from the perspective of inter-forest trust relationships.  Prior to determination of these requirements, this design methodology requires an understanding of the following facts about function of a trust relationship:

Page 44 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 This design methodology defines the function of a trust relationship as a logical vehicle between two Windows-based domains to support frequent, high-volume, authenticated, and authorised single-sign on access, to access-controlled resources and services, between two or more domains.  Hence, there may not be any requirement to design and implement a trust relationship between two or more Windows-based domains where it is possible to identify compliance with any of the following: • Inter-forest access is executed infrequently by only a handful of clients of a shared resource or service in an external domain • Inter-forest access does not require authentication or authorisation, as the shared resource permits anonymous access • There is no requirement to support single-sign on for the security principals that require inter-forest access to shared resources and services  Hence, when determining requirements for inter-forest access to shared resources and services, it is necessary to establish compliance with the criteria that reflects the definition of the function of an inter-domain trust relationship.  Based upon this basic information, this design methodology proposes the following approach to determine the requirements to support inter-forest access to shared resources and services:  Select an Active Directory forest and execute an analysis to identify all shared resources and services, controlled by the Active Directory forest, to which large numbers of security principals will require frequent access. Qualify these requirements against the criteria outlined above.  Where it is possible to identify such requirements, then determine the following: • The nature of the shared resources and / or services • The logical and physical distribution of the shared resources and services within the directory service infrastructure(s) and the organisation • The types of clients that will require inter-forest access to shared resources and services • The logical and physical distribution of these clients within an organisation, and outside of an organisation  Repeat for each required Active Directory forest within the organisation, and outside of the organisation, where appropriate  Document all identified requirements to support inter-forest access to shared resources and services  Where it is not possible to identify any requirements to support inter-forest access to shared resources and services, then there is no requirement to design and implement a federated forest infrastructure Using the above information and approach, execute the following:  Define the criteria to qualify initial requirements to support inter-forest access to shared resources and services across a trust-relationship

Page 45 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Execute an analysis, within each required forest, to identify all shared resources and services required to support access by security principals supported by different forests.  Where it is possible to identify the requirements to support inter-forest access to shared resources and services, then determine the details of the resources and services, and their clients  Document all requirements to support inter-forest access to shared resources and services • Factor A2: Definition of criteria to qualify requirements to design and implement one or more federated forest infrastructures ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements to support inter-forest access to shared resources and services, and  Wishes to define the criteria to qualify these requirements and the opportunity to design and implement one or more federated forest infrastructures, to support interforest access to shared resources and services. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When defining criteria, to qualify requirements for the design and implementation of one or more federated forest infrastructures, consider the following:  The criteria to qualify requirements for one or more federated forest trust relationships require co-definition by the owner(s) of the forests that may potentially participate within a federated forest infrastructure.  This design methodology proposes execution of the following approach, to define criteria to qualify requirements for the design and implementation of one or more federated forest infrastructures:  Understand the differences between forest trust and external trust relationships. This is imperative when attempting to disprove the null hypothesis for this process.  Understand the factors that will favour the opportunity to disprove the null hypothesis for this process, and hence the design and implementation of one or more federated forest infrastructures  Understand the factors that will support the null hypothesis for this process, and hence the design and implementation of external trust relationships  Define the criteria to reflect the business and technical objectives and requirements to support inter-forest access to shared resources and services  Evaluate all identified requirements to support inter-forest access to shared resources and services against the defined criteria  Determine and document all qualified requirements for the design and implementation of one or more federated forest infrastructures When attempting to understand the differences between forest trust and external trust relationships, consider the following:

Page 46 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Windows Server 2003 Active Directory forest trust relationships represent the foundations for all federated forest infrastructures. Qualification of requirements for the design and implementation of a federated forest infrastructure must disprove the null hypothesis for this process, and hence the requirements for the use of Windows Server 2003 Active Directory forest trust relationships, instead of “normal” interdomain external trust relationships.  Hence, prior to determination of the requirements for forest trusts, it is necessary to understand the similarities and differences between forest and external trust relationships.  The following table summarises the similarities and differences between forest and external trust relationships, between Windows Server 2003 Active Directory domains in different forests:
Feature Transitivity Scope of Authentication SID Filtering support Domain that supports trust creation Dependency on forest functional level for trust creation Forest Trust Relationship Supported Forest-wide Supported Only forest root domain Requires the Windows Server 2003 Active Directory forest to be operating at the “Windows Server 2003” forest functional level to support implementation Must be a forest root domain in a Windows Server 2003 Active Directory forest operating at the “Windows Server 2003” forest functional level Supported Supported External Trust Relationship Not supported Domain-wide Supported Any domain within the forest May be implemented at any forest functional level for a Windows Server 2003 Active Directory forest

Target domain requirements

May be any external Windows-based domain in a Windows NT 4.0, Windows 2000, or Windows Server 2003 directory service infrastructure Supported Not supported

Support for Trusted Domain Objects (TDOs) Support for Top Level Names (TLNs) (the names of all trees and alternate UPN suffixes in the forest) Support for “DomainInfo” (information about the DNS and NetBIOS domain names, and the SID for all domains in the forest) Support for Kerberos V5 authentication across the trust Support for NTLM authentication across the trust Support for UPN logon across the trust

Supported

Not supported

Supported Supported Support for both implicit and explicit UPNs

Not supported Supported Support for implicit UPNs only

Table 5.1: Comparison between Forest Trust and External Trust Relationships  From the above table, it is possible to identify several differences between forest trust and external trust relationships. The differences between forest trust and

Page 47 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

external trust relationships provide the initial basis for the qualification of requirements for federated forest trust relationships. When attempting to understand the factors influential in supporting the opportunity to disprove the null hypothesis for this process, consider the following:  This design methodology proposes that the following factors support the design and implementation of federated forest infrastructures, and hence the use of forest trust relationships over external trust relationships:  The requirements to reduce administrative overheads associated with the design and implementation of multiple external trust relationships  The requirements to use the Kerberos V5 authentication protocol between forests, to compliment NTLM and hence improve the trustworthiness of authorisation data transferred between forests  The requirements to support the use of implicit and explicit UPNs for user logon and authentication between forests  The requirements to support migration paths to consolidate multiple Windows Server 2003 Active Directory forests  When attempting to understand the influence of requirements to reduce administrative overheads, on the design and implementation of forest trusts, consider the following:  The requirements to reduce administrative overheads associated with multiple external trust relationships, via the use of forest trusts, are a strict reflection of the number of domains within a forest that require a trust relationship with other domains in other forests. The greater the number of external trust relationships required between domains in two or more forests, the greater the administrative overheads in managing these trusts, and the security of these trusts.  Hence, when attempting to determine whether there is an opportunity to design and implement forest trusts, to reduce administrative overheads, this design methodology proposes execution of the following approach: • Select two forests and determine the number of external trust relationships required, between domains within each forest, to support all identified requirements for inter-forest access to shared resources and services. • Define a threshold value, or value range, for external trust relationships. This value is a reflection of the maximum number of inter-forest external trust relationships the forest owners will support. Although the onus is with the organisation to define their threshold value, this design methodology recommends a value range of between six and eight trust relationships. This threshold range is a reflection of the requirement by this design methodology to support the null hypothesis for this process. • Evaluate the number of external trust relationships required against the threshold value / value range, and determine the opportunity to design and implement forest trusts between the selected forests. • Repeat the above process for all inter-forest trust relationship requirements.  The following two examples illustrate the above approach, where the threshold value is set to eight external trust relationships: • Example of support for design and implementation of forest trust relationships:

Page 48 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ An organisation has two forests, with three domains in “Forest 1” and five domains in “Forest 2”, as illustrated in figure 5.3. To support inter-forest access to data and resources, as illustrated in figure 5.3, it is necessary to implement eight one-way trust-relationships. In this scenario, two one-way forest trust-relationships between the forest root domains (F1 and F2) would be simpler to implement and manage, as illustrated in figure 5.4. ♦ However, note that the use of forest trust relationships, for this scenario, without further configuration, would only permit the requirements for interforest data and resource access and sharing, but not control visibility of resources between forests. ♦ Hence, it is necessary to configure routing hint suffixes to re-establish the semblance of a non-transitive trust-relationship. See later for a discussion on the requirements for the configuration of routing hint suffixes for this scenario.
Non-transitive external trustrelationships

Forest 1

Forest 2

Print Queues F1 F2

Shared Folders D1.F1

Data D1.F2 D2.F2

Print Queues D2.D1.F1

Shared Folders D3.D1.F2 D4.D1.F2

© 2 0 0 4 MU ST AN SH I

R

BHAR

MAL

Figure 5.3: Example of External Trust-Relationships Requirements
Forest 1 Forest 2

Bidirectional Forest Trust Relationship
F1

Print Queues F2

Shared Folders D1.F1

Data D1.F2 D2.F2

Print Queues D2.D1.F1

Shared Folders D3.D1.F2 D4.D1.F2

© 2 0 0 4 MU ST AN SH I

R

BHAR

MAL

Figure 5.4: Example of Forest Trust-Relationship to Replace External Trusts • Example of lack of support for design and implementation of forest trusts: ♦ An organisation has two forests, with two domains in “Forest 1” and five domains in “Forest 2”, as illustrated in figure 5.5. Using external trustrelationships, in order to permit inter-forest access to data and resources,

Page 49 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

as illustrated in figure 5.5, two one-way (and hence bidirectional) trustrelationships would be required.
Forest 1 Forest 2

Print Queues F1 F2

Shared Folders D1.F1

Data D1.F2 D2.F2

Two one-way nontransitive external trust-relationships

Shared Folders D3.D1.F2 D4.D1.F2

© 2 0 0 4 MU ST ANS HI

R

BHAR

MAL

Figure 5.5: Example of Trust Requirement That Does Not Support Forest Trusts ♦ In this scenario, it is not necessary to establish a forest trust relationship between the two forests, as the extra management overheads for a forest trust will outweigh the management overheads for two external trustrelationships.  When attempting understand the influence of requirements for the use of Kerberos V5 authentication between forests, on the design and implementation of forest trusts, consider the following:  External trust relationships only support the NTLM authentication protocol, and not Kerberos V5.  The use of the Kerberos V5 authentication protocol supports seamless access to data and resources between forests, where servers and services can impersonate users and request authentication tickets on their behalf from domain controllers in other forests to access data / resources.  Hence, when determining the requirements for the design and implementation of forest trust relationships, to support the use of the Kerberos V5 protocol, this design methodology proposes execution of the following approach: • Use the results of the analysis to identify all inter-forest access requirements to shared resources and services between forests, to identify all clients that will rely upon the use of the Kerberos V5 authentication protocol. For example, a user connects to a server in the same domain and forest, and attempts to access a resource, via this server, in another domain and forest. This server may be delegated the right to support impersonation of the user, using Kerberos V5. • Where the use of NTLM authentication between forests, via external trusts that do not support Kerberos, does not meet all requirements for inter-forest collaboration there may be a requirement to design and implement a forest trust between the forests. • Note that this requirement assumes that the external trust requirement, which a forest trust may replace, is a qualified requirement, via compliance with the criteria defined earlier.

Page 50 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 When attempting to understand the influence of requirements to support the use of implicit and explicit User Principal Names (UPNs), on the design and implementation of forest trusts, consider the following:  The names of the current domain and the root domain are the default, implicit, UPN suffixes for user accounts. Forest owners can add additional, explicit, UPNs to provide additional security and to simplify user logon names, for example, to match e-mail address suffixes.  Inter-forest authentication relies upon the ability for an authenticating domain controller within a target domain, to locate the domain controller for a source domain supporting the security principal, which requires inter-forest access and authentication. The use of shared top level names (TLNs), such as “natsum.com” by two or more forests, can cause TLN collisions, and the occurrence of such collisions will disable a forest trust. Hence, forest owners may wish to define explicit custom UPNs for user accounts within their forest. The use of explicit UPNs across a forest trust permits the routing of authentication requests, to the correct domain controller, without collisions due to similar UPNs.  Hence, when determining the requirements for the design and implementation of forest trusts to support explicit UPNs, this design methodology proposes execution of the following approach: • Use the results of the earlier analysis to identify the appropriate forests involved in supporting inter-forest access requirements to shared resources and services. • Determine the UPNs employed within each of these forests, and the presence of any potential UPNs collisions and hence requirements for explicit UPNs. • Where it is possible to identify requirements for the design and use of explicit UPNs, then consider the design and implementation of forest trust relationships, to support the use of explicit UPNs by users.  When attempting to understand the influence of requirements for execution of forest consolidation exercises, on the design and implementation of forest trusts, consider the following:  Consolidation of two or more forests to a single or fewer numbers of forests typically requires execution of inter-forest migration path “F” (see migration plan process, “understanding supported migration paths”, for details). Execution of each instance of migration path “F”, for each domain within a source forest, requires the establishment of a trust relationship between the source and target domains.  Hence, when determining the requirements for the design and implementation of forest trusts to support the consolidation of multiple Windows Server 2003 forests, this design methodology proposes execution of the following approach: • Select a source forest that requires consolidation to one or more other target forests. • Determine the number of domains within the source forest that require consolidation • As each source domain will require a trust relationship with a target domain, evaluate the number of domains within the source forest with the threshold value for external trust relationships, defined earlier. Where the number of external trusts required to support forest consolidation exceed the threshold

Page 51 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

value, it may be necessary to design and implement a temporary forest trust relationship between the source and target forests. When attempting to understand the factors influential in supporting the null hypothesis for this process, consider the following:  This design methodology proposes that the following factors support the null hypothesis for this process:  The current or proposed function(s) and role(s) of the forests that require integration, and their current forest functional level  The physical and logical distribution of the domain controllers within the forests that require integration, and clients for inter-forest resource access  The requirements for the design of a supporting DNS infrastructure to support inter-forest authentication and authorisation  When attempting to understand the influence of the function(s) and role(s) of a forest, and the current forest functional level, on the design and implementation of forest trusts, consider the following:  As discussed in the earlier process, “determination of the number of forests required”, this design methodology recognises three generic motives and opportunities for an organisation to sanction the design and deployment of a multiple forest infrastructure. These are requirements for service isolation, service autonomy, and / or data isolation from service owners within an organisation.  The function and role of a forest created to meet one or more of these three generic reasons will influence the level and type of integration that the forest can sustain. Presented below are examples to illustrate this: • Example 1: A forest created to meet the requirements for service isolation from within an organisation. The nature of this requirement implies that the forest owners wish to place a boundary on the influence of service owners within an organisation on the operation of their forest. Hence, any proposals to integrate such a forest with another forest owned by an organisation may compromise the function and operation of the forest, depending upon the level and type of integration proposed. • Where the objective of an integration proposal is data and resource sharing between the forests, then this proposal may be permissible to a degree as long as there is no compromise to the operation of the forest, or the integration solution does not compromise the operation of other forests within an organisation. • Example 2: A forest created to meet the requirements for service autonomy from within an organisation. The nature of this requirement also implies that the forest owner wishes to limit the scope of influence of service owners within an organisation. However, the requirement for autonomous management of a forest does not imply a requirement to restrict access to data and resources controlled by the forest from other forests within an organisation. • Hence, these forests may be open to participation within an intranet or extranet federated forest infrastructure, as long as there is no compromise to the autonomy for forest management. • Example 3: A forest created to meet the requirements for data isolation from service owners within an organisation. The nature of this requirement implies

Page 52 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

the erection of a secure boundary for access to data and resources controlled by a forest created specifically to meet this requirement. This requirement also implies service isolation and autonomy to permit the maintenance of a secure data and resource access boundary. • Hence, a forest owner for such a forest would strongly resist proposals for participation within an intranet or extranet federated forest infrastructure to permit data / resource access or a single authentication model. • It may be necessary to design a selective authentication model for the incoming forest trust relationships where the participation of a forest (created for data isolation from service owners) within an intranet or extranet federated forest infrastructure is mandatory and not optional. See the next step, determination of the design requirements for each federated forest infrastructure, for more information.  An organisation may inherit multiple forests via mergers and acquisitions, or via exercises to re-establish control over all autonomous components of an organisation that have deployed their own “grassroots” forests. In these scenarios, an organisation may regard these superfluous forests as potential candidates for forest consolidation. Although a forest trust may assist in the execution of a forest consolidation exercise, this only represents a temporary requirement for forest trusts.  A technical prerequisite to the design and implementation of forest trusts is that the Windows Server 2003 forests are operating at the “Windows Server 2003” forest functional level. Where proposed or current Windows Server 2003 forests are operating at “Windows 2000”, “Windows 2000 Native”, or “Windows Server 2003 Interim”, then it is not possible to design and implement forest trust relationships.  Where one or more domains within the forest require the retention of one or more legacy (Windows NT 4.0 or Windows 2000) domain controllers, then it is not possible to raise the functional level of that domain, and hence the forest to “Windows Server 2003”. When attempting to understand the influence of the physical and logical distribution of domain controllers and clients, on the design and implementation of forest trusts, consider the following:  Requirements to support inter-forest access to shared resources and services rely upon a supporting network infrastructure.  A forest trust may be an unviable proposition in the following example scenario:  An organisation has two or more forests, with requirements to support inter-forest access, authenticated using the Kerberos V5 protocol  It is possible to identify that the clients of shared resources and services have a remote distribution (logical (on the network) and physical) profile to the authenticating and authorising domain controllers. Hence, authentication and authorisation traffic may have to cross a WAN infrastructure.  The impact on levels of available bandwidth within the supporting WAN infrastructure from remote inter-forest authentication, authorisation, and access to shared resources and services may prevent support for the design and implementation of forest trust relationships.  Hence, logical requirements for the design and implementation of forest trust relationships require support via a physical network infrastructure.

Page 53 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When attempting to understand the influence of requirements to design a supporting name resolution infrastructure for a federated forest infrastructure, on the design and implementation of forest trusts, consider the following:  To support two forests integrated via a forest trust relationship, it is necessary to design and implement a suitable DNS infrastructure, configured to route name queries, between the forests, for destination forest namespaces.  Although it is possible to identify several options to support this requirement, the selection of the most appropriate option depends upon two variables. These are:  The presence of a shared root DNS server for both forests, and / or  The presence of a Windows Server 2003 DNS server (or suitable alternative) that supports the use of conditional forwarding or secondary zones  Where either or both (depending upon the direction of an intended forest trust relationship) DNS infrastructures for the forests are not capable of supporting the routing of queries for names within a destination forest namespace (using any of the options listed), then it is not possible to design and implement forest trusts. When defining the criteria to qualify requirements to disprove the null hypothesis for this process, and hence, the design and implementation of forest trusts, consider the following:  All requirements for the design and implementation of forest trust relationships require qualification via compliance against criteria, defined by the forest owners, to reflect business and technical requirements and objectives. The criteria require definition from the perspective of supporting the null hypothesis and requiring justifications to design and implement forest trusts.  Although the onus is with the organisation to define their criteria, this design methodology proposes the following example criteria to qualify forest trust requirements:  The requirement(s) for the design and implementation of a federated forest infrastructure comply with the following criteria: • There is a requirement to support the use of the Kerberos V5 authentication protocol, between forests, and • The requirements to support authentication, authorisation, and access to shared resources and services will not be detrimental to the supporting network infrastructure  The requirements for the design and implementation of a federated forest infrastructure complies with the following criteria: • The forest trust(s) will replace alternative external trust relationships because the number of external trust relationships required to support identified interforest access requirements exceed the defined threshold value of eight trusts (this is an example criterion), and • Each requirement for an external trust, to be replaced by forest trust(s), are validated against defined criteria Using the above information and approaches, execute the following:  Understand the differences and similarities between forest and external trust relationships

Page 54 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Understand the factors influential in the design and implementation of forest trusts  Understand the factors influential in supporting the null hypothesis for this process  Define the criteria to qualify requirements for the design and implementation of forest trust relationships  Evaluate all identified requirements to support inter-forest access to shared resources and services against the defined requirements  Where it is possible to identify the requirements for the design and implementation of forest trust relationships, then execute the following:  Document the requirements for the integration of two or more Windows Server 2003 Active Directory forests  Document the criteria that support, via compliance, the requirements for the design and implementation of forest trusts.  Document the type of federated forest infrastructure(s) required (extranet and / or intranet)  Document the member forests within each required federated forest infrastructure 4.9.2. Determination of the Design Requirements for Each Federated Forest Infrastructure Consider the following where an organisation has identified the requirements for the design and implementation of one or more federated forest infrastructure, and wishes to determine the design requirements for each required infrastructure: • Factor B2: Understanding the approach to determination of the design requirements for a federated forest infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of one or more federated forest infrastructures, and  Wishes to understand the approach towards the determination of the design requirements for each required federated forest infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes determination of the following design requirements:  Determination of the minimum number of federated forest infrastructures required for an organisation  Determination of the number and direction of the forest trust relationships to be created between each member forest within each federated forest infrastructure  Determination of the design requirements for the configuration of routing hint suffixes for each required forest trust relationship  Determination of the design requirements for the configuration of selective authentication for each forest trust  Determination of the design requirements for the delegation of forest trust creation

Page 55 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The following analysis factor (A3) will assist an organisation in the determination of these design requirements, for each required federated forest infrastructure. • Factor A3: Determination of the design requirements for each required federated forest infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of one or more federated forest infrastructures, and  Wishes to determine the design requirements for each required federated forest infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the minimum number of federated forest infrastructures required for an organisation, consider the following:  This design methodology recommends that where an organisation has identified the requirements to integrate two or more Windows Server 2003 forests, using forest trust relationships, that they design and implement the minimum number of federated forest infrastructures.  When determining the minimum number of federated forest infrastructures that require design and implementation, consider the following:  Multiple forests can reside within a single federated forest infrastructure. The restricted transitivity of a forest trust relationship (see later for details) supports the secure coexistence between multiple forests.  This design methodology supports the following requirements for the generation of two or more federated forest infrastructures: • The requirements to generate discrete extranet and intranet federated forest infrastructures. Note, however, to support this recommendation, any internal forests participating within an extranet federated forest infrastructure must not participate within an intranet federated forest infrastructure, and vice versa, as this removes the logical boundaries between the infrastructures. • The requirements to generate multiple discrete intranet federated forest infrastructures to support service autonomy • The requirements to generate multiple discrete extranet federated forest infrastructures to support different sets of external forests, such as forests for different partners of an organisation  Using the above information, execute an analysis to determine the minimum number of federated forest infrastructures required for an organisation When determining the number and direction of forest trust relationships required, within each federated forest infrastructure, consider the following:  It is not possible to assume that all forests, within a federated forest infrastructure, will have a forest trust relationship (mono or bidirectional) with every other forest.  Although the transitivity of a forest trust relationship extends to all domains within each forest connected by the forest trust, does not extend to domains within other

Page 56 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

forests. The diagram (figure 5.1) in the background information section of this process, illustrates the scope of transitivity of forest trust relationships, where  The transitivity of the forest trust between “Forest 1” and “Forest 2” extends to all domains within these connected forests  The domains within “Forest 2” are not trusted by, or trust, domains within “Forest 6”, as there is no forest trust relationship between “Forest 2” and “Forest 6”, even though both of these forests have forest trusts with “Forest 1”.  Hence, when determining the number of forest trusts required within each federated forest infrastructure, this design methodology proposes execution of the following approach:  Analyse the requirements to support inter-forest access between all domains within each member forest  Determine the minimum number of forest trust relationships necessary to support all identified inter-forest access requirements  Determine the required direction of the forest trust relationships to reflect the identified requirements to support inter-forest access When determining the design requirements for the configuration of routing hint suffixes for each required forest trust relationship, consider the following:  Routing hint suffixes permit granular control over the transitive nature of a forest trust relationship, via the prevention of the routing of authentication requests from specific namespaces within the trusted forest, and hence preventing them from using the forest trust relationship.  Consider the use of routing name suffixes to control the routing of authentication requests where control can be established using complete namespaces. Where the disabling of complete namespaces does not provide the granular control required, then consider the use of selective authentication to control the scope of authentication of a forest trust relationship.  For example, an organisation has two forests, with three domains in “Forest 1” and five domains in “Forest 2”, as illustrated earlier in figure 5.3. Using external trustrelationships, in order to permit inter-forest access to data and resources, as illustrated in figure 5.3, eight one-way trust-relationships would be required. In this scenario, two one-way forest trust-relationships between the forest root domains (F1 and F2) would be simpler to implement and manage, as illustrated in figure 5.4.  However, the implementation of the transitive forest trust relationship between “Forest 1” and “Forest 2” negates the granular access control requirements achievable via selectively implemented external trust relationships. Hence, it is possible to configure the following routing hint suffixes to permit granular control over the forest trust relationships (to emulate figure 5.3 above): • Where “Forest 2” is the trusted forest, configure the forest trust relationship to disable the “*.D2.F2” and “*.D4.D1.F2” name spaces, and enable the “F2” and “D1.F2”, and “*.D3.D1.F2” namespaces. • Where “Forest 1” is the trusted forest, configure the forest trust relationship to enable the “*.F1” namespace (set by default).  When determining the requirements for the design and configuration of routing hint suffixes, this design methodology proposes execution of the following approach:

Page 57 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine the granular inter-domain access requirements, which multiple external trust relationships may support  Translate these requirements into routing hint suffixes, where required When determining the design requirements for the configuration of selective authentication for each forest trust, consider the following:  The scope and objective of the integration between the forests is an important factor in the use of selective authentication between forests.  If the scope of a forest trust relationship is permit access to data and resources to only a previously identified and select group / set of security principals from another forest, then consider using selective authentication for the forest trust.  If the objective of a forest trust relationship is to permit, for example, collaboration between organisations via an extranet federated forest infrastructure, then the organisations may be naturally mistrustful of each other’s forest owners. Hence, consider the implementation of an authentication firewall between the two forests, in the form of selective authentication for the forest trust relationships.  However, this design methodology recommends against the design and implementation of selective authentication where it is possible to identify compliance with one or more of the following criteria:  The precise authentication scope for a forest trust is either unknown at the time of creation of the forest trust, or the scope is very large and non-specific, with the requirement to grant access to security principal objects created within, and distributed amongst, various domains within the trusted forest. The management of cross-forest authentication may have a greater administrative overhead with the use of selective authentication in this scenario.  The objective of a forest trust relationship is to permit a common authentication model via an intranet federated forest infrastructure. Use forest-wide authentication for these scenarios.  A forest owner can identify, within a trusted forest, domains that hold security principal objects not permitted to cross the forest trust, and domains that hold security principal objects required or invited to cross the forest trust. This presence of strict domain / namespace boundaries for the required and unwanted security principal objects permits the use of forest-wide authentication for a forest trust and the configuration of routing name suffixes to disable authentication requests from the unwanted name spaces in the trusted forest. When determining the design requirements for the delegation of forest trust creation, consider the following:  The creation of a forest trust relationship requires the security context of a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group.  However, it is possible to delegate the creation of forest trust relationships. The scope of delegation is limited to the creation of a one-way in-bound forest trust relationship. It is possible to delegate the creation of forest trust relationships via:  Direct assignment of the permission “Create Inbound Forest Trust” to a security principal, on the forest root domain  Addition of the delegate security principal(s) to the built-in security group, in the forest root domain, “Incoming Forest Trust Builders”, which is delegated the permission “Create Inbound Forest Trust” on the forest root domain

Page 58 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Using the above information and approaches, execute the following:  Determine the minimum number and type of federated forest infrastructures required for the organisation  Determine the minimum number of forest trust relationships, and direction for the trusts, to support all identified requirements for inter-forest access to shared resources and services  Determine the design requirements for the configuration of routing hint suffixes on all or selected forest trusts  Determine the design requirements for the configuration of selective or forest-wide authentication on all or selected forest trusts  Determine the requirements for the delegation of forest trust creation 4.9.3. Design of a Federated Forest Infrastructure Consider the following information when designing any federated forest infrastructures: • Factor D1: Generation of a design for each required federated forest infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of one or more federated forest infrastructures,  Has determined all of the design requirements for each required federated forest infrastructure, and  Wishes to generate the design for each required federated forest infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes that the design for each required federated forest infrastructure comprise the following format and contents:  A detailed design document, identifying the following information:  All identified requirements to support inter-forest access to shared resources and services  All identified requirements for the design and implementation of one or more forest trust relationships, and the criterion / criteria that support the identified requirements  The design for the number of federated forests required  The design for the number of forest trusts required within each federated forest infrastructure  The design for the configuration of routing hint suffixes on all or specific forest trust relationships  The design for the configuration of selective or forest-wide authentication on all or specific forest trust relationships  The design for the delegation of forest trust creation

Page 59 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A diagram illustrating all required federated forest infrastructures, and the forest trust relationships between each member forest  Where there is a requirement to design and implement an extranet federated forest infrastructure, then include in the diagram the logical boundaries for the organisation, and the internal member forest(s).

Page 60 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

5.

Design of a DNS Infrastructure
This process requires execution by all organisations planning the design and implementation of a Windows Server 2003 Active Directory infrastructure, regardless of the presence of any current DNS infrastructure(s) in use within the organisation, or provided for the organisation by a third party service provider.

5.1.

Process Prerequisites This process requires execution only after the completion of the following processes within this design methodology: • The “Organisation-Wide Active Directory Plan” process to “determine the number of forests required” • The “Forest Plan” (for each forest within the Active Directory infrastructure) process to “determine the number of domains required” • The “Forest Plan” (for each forest within the Active Directory infrastructure) process to “determine the structure and relationships of multiple domains”. The results of these processes will provide the details of the DNS namespace requirements each DNS infrastructure may be required to support. Hence, it is only possible to generate a design for a DNS namespace strategy following completion of these dependent processes. Note, however, that it is possible to initiate and execute other components of this process, such as the analysis of existing DNS infrastructure(s), and the design for the DNS server and client infrastructures, independently of the above processes.

5.2.

Process Objectives The objectives of this process are to: • Assist an organisation in the determination of the number of DNS infrastructures required to support a Windows Server 2003 Active Directory infrastructure for an organisation • Assist an organisation in the generation of a design for each required DNS infrastructure, to support the defined scope of the Active Directory infrastructure. Each design for a required DNS infrastructure will comprise the following components: ♦ A design for a DNS namespace strategy ♦ A design for a DNS server infrastructure ♦ A design for a DNS client infrastructure The process to design a DNS infrastructure is included within the Organisation-Wide Active Directory Plan as the scope of this infrastructure should be, ideally, the entire Active Directory infrastructure for an organisation. This hence implies that a single DNS infrastructure supports an entire single or multiple forest Windows Server 2003 Active Directory infrastructure for an organisation. However, as there may be the requirement to design and deploy multiple and discrete DNS infrastructures within an organisation, the approach for this process starts with an analysis step to determine the number of DNS infrastructures required. A DNS infrastructure can have many other name resolution support functions for an organisation, such as supporting intranet and Internet web sites; service and application location and so on The design of the DNS infrastructure to support these functions is beyond the scope of this process.

Page 61 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

5.3.

Background Information A Windows Server 2003 Active Directory infrastructure relies upon a supporting DNS infrastructure. However, as stated above, because a DNS infrastructure can have multiple functions that extend beyond the scope of supporting an Active Directory infrastructure, the design and deployment of a DNS infrastructure does not rely upon a Windows Server 2003 Active Directory infrastructure. Prior to execution of this process, it is necessary to understand the relationship between DNS and Active Directory, and the definition of the term “DNS Infrastructure” by this design methodology.

5.3.1.

DNS Infrastructure and Active Directory A pre-requisite to the execution of this process is an understanding of the basic function and role of a DNS infrastructure in supporting an Active Directory infrastructure. An understanding of this relationship will assist an organisation in the definition of the business and technical objectives and requirements for a DNS infrastructure, to support the defined scope of the Active Directory infrastructure. Presented below, in a question and answer format, is basic information about the function and role of a DNS namespace and DNS server infrastructure to assist an organisation in understanding the relationships between DNS namespaces and Active Directory, and the importance of identity when designing a DNS namespace strategy: • Q1. What is the function of a DNS server infrastructure? • A1. A DNS server infrastructure provides one primary function. This is the mapping of computer host names to TCP/IP addresses within a DNS zone database. The DNS server infrastructure can then present a DNS client of the infrastructure with the stored resource records for query. Several other functions of a DNS infrastructure depend and build upon this primary function. For example, this mapping of IP address to host name can also facilitate a DNS client in the location of services, protocols, resources and applications mapped to the host names of computers offering these services and so on • Q2. What is the purpose of a DNS namespace? • A2. A DNS namespace provides one primary function. This is to permit a user of a resource, published within a DNS infrastructure, to locate that resource using the known information about the identity of the actual or logical owner of the resource. Thus, the function of a namespace is to reflect the identity of the owner / distinguish the ownership of resources published within the context of this namespace, within a DNS infrastructure, and thus facilitate the search for resources aligned with the identity represented by the DNS namespace. • The identity of the resource owner becomes an important consideration where there are multiple resource “owners” present on a common network infrastructure, such as an internal LAN / WAN infrastructure or the Internet. • Q3. How do DNS and Active Directory work together? • A3. A DNS infrastructure is required to support the access to resources controlled by an Active Directory infrastructure and services published within an Active Directory infrastructure, such as the Key Distribution Service (KDC) and LDAP protocol interfaces. Clients of an Active Directory infrastructure (via the use of a DNS client to query a DNS infrastructure that supports an Active Directory infrastructure) locate resources within an Active Directory domain based upon the ownership of that resource. • The resources could be published within an Active Directory infrastructure, in which case, the user needs to use DNS to resolve the FQDN to an IP address, or the resource could be published within an DNS infrastructure (such as a service), in which case the user

Page 62 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

needs to query the DNS infrastructure to locate the computer hosting the service. The logical owner of a resource within an Active Directory infrastructure is, for example, a domain. Hence, a resource, such as a computer, has a fully qualified domain name (FQDN) that reflects its parents and position within an Active Directory namespace hierarchy. 5.3.2. Defining the term “DNS Infrastructure” It is important, at this stage, to understand the meaning of the term “DNS infrastructure”. This design methodology and process uses this term many times and provides the following simple definition: “A “DNS infrastructure” consists of one or more DNS namespaces, such as “Natsum.com.” and “Universe.com.”, supported by one or more servers running DNS server software, which also support the DNS requirement of one or more computers running DNS client software, and supports a single name resolution strategy”. Hence, the term “DNS infrastructure” is divisible into the following three components: 1. 2. 3. A DNS namespace, which refers only to the namespace components of a DNS infrastructure A DNS server infrastructure, which refers only to the DNS server aspects of a DNS infrastructure A DNS client infrastructure, which refers only to the DNS client aspects of a DNS infrastructures

The approach to this process, discussed below, uses these three primary components of a DNS infrastructure as the largest virtual process executables. There are many other approaches to the definition of a DNS infrastructure. For example, it is possible to base the definition on the function and / or the logical and physical boundaries of the DNS infrastructure, or the scope of support of the DSN infrastructure. This can hence give rise to the identification of virtual and actual DNS infrastructures. In order to define a DNS infrastructure, it is necessary to define it based on the following logical and physical components for any DNS infrastructure: • The logical function of the DNS infrastructure • The logical and physical boundary for this infrastructure within an organisation, with respect to the logical and physical components of an organisation represented within in, and supported by, the DNS infrastructure • The logical scope of a name resolution strategy for the DNS infrastructure • The physical servers that operate the DNS server software and service within an organisation • The physical clients that operate the DNS client software to access and query the DNS servers • The physical zone files that contain resource records for a contiguous portion of a DNS namespace The ideal definition of a DNS infrastructure, using these components, would be “one or more DNS servers that: • Share a single function and contiguous logical and / or physical boundary within an organisation, and a single name resolution strategy

Page 63 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Support a set of zone files to reflect the single function of the DNS infrastructure • Represent the namespaces collectively supported by the DNS infrastructure, and • Support the DNS clients of the DNS server infrastructure”. However, in reality, for the majority of organisations that use DNS for name resolution, only a single DNS infrastructure may be present. This single DNS infrastructure will typically have the following characteristics: • The DNS infrastructure, collectively, may not have a single function, but instead, serve and support many disparate functions within an organisation • The scope of the DNS infrastructure may not have a contiguous logical and / or physical boundary within the organisation • The DNS servers within the DNS infrastructure may not be dedicated to specific functions and instead support many different requirements within the organisation, ranging (for example) from supporting intranet / Internet web sites; applications that rely upon DNS; a Windows 2000 Active Directory infrastructure; and so on • The multiple functions of a DNS infrastructure may be reflected in a variety of zone files held, used, and managed by the DNS servers Extrapolating upon the definition of the term “DNS infrastructure”, presented below is a brief discussion on the concept of actual and virtual DNS infrastructures to assist an organisation in the analysis component of this process. Where DNS servers within an organisation support many disparate name resolution functions and are not dedicated to a single function (such as supporting an Active Directory infrastructure), then it is difficult to ascertain the specific role of a server within a DNS infrastructure. However, it is possible to dedicate certain components of a DNS infrastructure to specific functions, such as DNS zones. A collection of zones, distributed across multiple DNS servers within an organisation that serve the same function and use a common name resolution strategy, can collectively be termed a virtual DNS infrastructure within an actual DNS infrastructure that represents all of the DNS servers within an organisation. However, within an organisation, where DNS servers and the zones they hosted are exclusively dedicated to specific functions, and there are multiple DNS servers supporting multiple functions, this can viewed as multiple “actual” DNS infrastructures within a collective virtual DNS infrastructure for an organisation. When executing this process to design a DNS infrastructure for an organisation to support the defined scope of the Active Directory infrastructure, it is important to establish whether this DNS infrastructure will be an actual DNS infrastructure or a virtual DNS infrastructure. For example, it is possible to view a set of DNS zones created on existing DNS servers within an existing DNS infrastructure, but dedicated to the support of a Windows Server 2003 Active Directory infrastructure, as a virtual DNS infrastructure within an actual DNS infrastructure. Recommend, wherever possible, to create the design for a DNS infrastructure to support the defined scope of the Active Directory infrastructure as an actual DNS infrastructure. An actual DNS infrastructure, that has both DNS servers and their components dedicated to specific functions, will be simpler to design, deploy, operate, manage, and troubleshoot. This may hence influence the total cost of ownership and service level agreements for a Windows Server 2003 Active Directory infrastructure. 5.4. Process Approach When executing the process to design a DNS infrastructure to support a Windows Server 2003 Active Directory infrastructure, the recommended approach is to “keep it simple”. This

Page 64 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

hence implies only a single DNS infrastructure to support the entire Windows Server 2003 Active Directory infrastructure, consisting of one or more Active Directory forests. To support this recommendation, this design methodology states the following null hypothesis for this process: “A single DNS infrastructure can support an entire Windows Server 2003 Active Directory infrastructure without the need to create a multiple DNS infrastructure for the organisation”. It is then necessary to execute an investigation to disprove this null hypothesis and hence determine the number of DNS infrastructures that are required to support the Windows Server 2003 Active Directory infrastructure. Where it is not possible to disprove this hypothesis, then it will stand true and only a single DNS infrastructure will be required. Hence, the following approach to the execution of this process depends upon: • The number of DNS infrastructures required, and hence their scope of support within the defined scope of the Active Directory infrastructure, and • The presence or absence of one or more existing DNS infrastructures within the defined scope of the Active Directory infrastructure To support the above recommendations and the null hypothesis for this process, this design methodology proposes execution of the following approach for this process, to design a DNS namespace strategy and server infrastructure for an organisation: 1. Determine the requirement for the design and deployment of: a. A single DNS infrastructure for the entire Windows Server 2003 Active Directory infrastructure for an organisation, or b. Multiple discrete DNS infrastructures to support components of the Windows Server 2003 Active Directory infrastructure, such as one or more forests or trees of domains 2. Where there is the requirement for the design and deployment of multiple DNS infrastructures within an organisation, determine the boundaries for each required DNS infrastructure. Note that the term “the defined scope of the Active Directory infrastructure” (for the required DNS infrastructure) will now refer to this defined scope throughout the rest of this process. For example, where an organisation has determined the requirement for a single DNS infrastructure, then the scope will be the entire Windows Server 2003 Active Directory infrastructure for the organisation. Within the identified boundaries for each DNS infrastructure (or the boundary of the entire Windows Server 2003 Active Directory infrastructure for a single DNS infrastructure), determine the presence of any existing DNS infrastructures, and (where present) the following: a. The details of the current DNS namespace status b. The details of the DNS server infrastructure status, and c. 4. 5. The details of the Windows DNS client infrastructure status (within the defined scope of investigation)

3.

Determine the business and technical objectives that will influence the requirements and design for the Windows Server 2003 Active Directory DNS namespace strategy Where it is possible to identify one or more existing DNS namespaces within an organisation, perform a gap analysis between the identified Windows Server 2003 Active Directory namespace requirements and the current DNS namespace strategy

Page 65 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

6.

Using the results of the DNS namespace gap analysis, determine the approach towards the DNS namespace strategy component of this process. The possible approaches that can be undertaken for the design of the DNS namespace strategy are: a. Where an organisation does not have any current DNS namespaces defined, then there will be the requirement to design a new DNS namespace strategy to support the scope of the DNS infrastructure. It is possible to also adopt the approach where there is a requirement to, for example, consolidate, or replace all current DNS namespaces with a new DNS namespace strategy. b. Where an organisation does have one or more current DNS namespaces, then the possible approaches are, based upon the results of the DNS namespace gap analysis: i. Use the existing DNS namespace(s) (without any redesign or modification) to support the scope of the DNS infrastructure, where the current namespace(s) meet all identified DNS namespace design requirements. Design modifications or extensions to existing DNS namespace(s) to extend the scope to accommodate all Windows Server 2003 Active Directory namespace requirements

ii.

iii. Design a new DNS namespace strategy for use in parallel, or in conjunction with, any existing DNS namespace(s) 7. 8. Determine the business, technical, and specific Windows Server 2003 Active Directory requirements that will influence the design of the DNS server infrastructure Where it is possible to identify one or more DNS server infrastructures within an organisation, perform a gap analysis between the identified requirements for the design of a supporting DNS server infrastructure and the design(s) of the current DNS server infrastructures Using the results of the server gap analysis, determine the approach towards the design of the DNS server infrastructure component of this process. The possible approaches that can be undertaken for the design of the DNS server infrastructure are: a. Where an organisation does not have any current DNS server infrastructure(s), then there will be a requirement to design a new (recommended) Windows Server 2003 DNS server infrastructure to support the DNS namespace strategy and the scope of the DNS infrastructure. It is possible to also adopt this approach where there is a requirement to, for example, consolidate or migrate all current DNS server infrastructures to a new single (recommended) Windows Server 2003 DNS server infrastructure. b. Where an organisation does have one or more DNS server infrastructures, then the possible approaches are, based upon the results of the DNS server gap analysis (against the design requirements for a supporting DNS server infrastructure): i. Use an existing legacy / third party DNS server infrastructure (without any modification or redesign) where it is currently able to support the defined scope of the Active Directory infrastructure. Design modifications and extensions to the scope and functionality of an existing legacy / third party DNS server infrastructure

9.

ii.

iii. Design a new (recommended) Windows Server 2003 DNS server infrastructure to support only the defined Active Directory scope for the new DNS infrastructure and operate in parallel, or in conjunction with, an existing legacy / third party DNS server infrastructure

Page 66 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

10. Determine the business, technical, and specific Windows Server 2003 Active Directory requirements that will influence the design for the Windows DNS client infrastructure 11. Whether it is possible or not to identify one or more Windows DNS client infrastructures within an organisation, it is necessary to perform a gap analysis between the identified requirements for the design of the Windows DNS infrastructure and: a. The current Windows operating system and service pack versions of the current / potential Windows clients of the DNS infrastructure b. The current configuration of the Windows DNS clients (where they exist) 12. Using the results of the Windows DNS client gap analysis, determine the approach towards the design of the Windows DNS client infrastructure component of this process. The possible approaches that can be undertaken for the design of the Windows DNS client infrastructure are: a. Where an organisation has one or more existing Windows DNS client infrastructures, then the possible approaches are, based upon the results of the Windows DNS client gap analysis (against the Windows DNS client design requirements): i. Use the existing Windows DNS client infrastructure, with the current Windows operating system(s) and configuration of the DNS client parameters where they permit compliance with all identified design requirements for the DNS client infrastructure Design the process to implement the identified configuration requirements onto new or upgraded Windows DNS clients where the current operating system does not permit support of all identified design requirements

ii.

iii. Design the process to implement modifications to the current DNS client configurations to permit compliance with all identified design requirements b. Where an organisation does not have an internal DNS infrastructure, and hence does not use the DNS client software components, then the possible approached are, based upon the results of the Windows DNS client gap analysis (against the Windows DNS client design requirements): i. Use of the existing Windows operating system(s) and service pack version(s) on the potential Windows DNS clients where they permit compliance with all identified operating system dependent design requirements Design the process to implement the identified configuration requirements onto new or upgraded Windows DNS clients where the current operating system does not permit support of all identified design requirements

ii.

Note: The proposed approach to the identification of the DNS namespace strategy and infrastructure comprises of multiple possible approaches for the DNS namespace, DNS server, and DNS client infrastructure because of potential for variances within the status and configuration of one or more current DNS infrastructures within an organisation. The considerations for this process (see later) detail the factors that require consideration when adopting any of the appropriate approaches listed above. 5.4.1. Differing Configuration Combinations for Current DNS Infrastructures There are five possible configuration combinations for a DNS infrastructure within an organisation (see below). Each of these possible DNS infrastructures, where identified within an organisation, will require mapping to a DNS namespace strategy, DNS server, and DNS client infrastructure approach, from the list of approaches detailed within the process approach. The possible DNS infrastructure configurations that can exist within an organisation are:

Page 67 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

1.

The organisation has legacy / third party DNS server software on one or more DNS servers, with one or more DNS namespaces registered for use on the Internet, and currently only used on the Internet. This scenario is possible, for example, within an organisation that internally hosts the organisation’s Internet-facing web site(s). This DNS infrastructure may or may not support internal Windows DNS clients. The organisation has legacy / third party DNS server software on one or more DNS servers, with one or more DNS namespaces registered for use on the Internet, and one or more DNS namespaces for use on the internal network for the organisation. This DNS infrastructure will support internal Windows DNS clients. The organisation has legacy / third party DNS server software on one or more DNS servers, with one or more DNS namespaces for use currently only on the internal network for the organisation, and not currently exposed to the Internet. This DNS infrastructure will support internal Windows DNS clients. The organisation does not currently operate any legacy / third party DNS server software, and hence has no DNS servers, but currently has one or more Internet-registered DNS namespaces, hosted by a third party service provider (such as an ISP) on the service provider’s DNS server infrastructure. This DNS infrastructure may not support internal Windows DNS clients. The organisation does not currently operate any legacy / third party DNS server software, and hence has no DNS servers and internal DNS namespaces, and does not currently have any DNS namespaces registered with ICANN for use on the Internet. This environment will hence not support internal Windows DNS clients.

2.

3.

4.

5.

5.4.2.

Process Tracks The process to design a DNS infrastructure to support the defined scope of the Active Directory infrastructure has five tracks. The tracks provide guidance as to the steps that require execution for the design of the DNS namespace strategy, DNS server infrastructure, and Windows DNS client infrastructure depending upon the status of these components within any existing DNS infrastructures within an organisation. Tracks 1, 2, and 3 will guide an organisation in the design of a DNS namespace and DNS server infrastructure. Tracks 4 and 5 will guide an organisation in the design of a Windows DNS client infrastructure. The following section illustrated the components and steps within each of these five tracks.

5.4.3.

Illustration of Approach to Design a DNS Namespace Strategy and Server Infrastructure The following figures illustrate the proposed approach for this process to design the DNS namespace strategy and DNS server infrastructure:

Page 68 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Organisation-Wide AD Plan - Approach for Process to Design DNS Namespace Strategy & Server Infrastructure START
Analysis of Existing DNS Infrastructure(s)

No Internal DNS Server Infrastructure + No DNS Namespace(s)

No Internal DNS Server Infrastructure + Internet Namespace(s) (ISP Hosted)

Internal DNS Server Infrastructure + Internet DNS Namespace(s) only

Internal DNS Server Infrastructure + Internet + Internal DNS Namespace(s)

Internal DNS Server Infrastructure + Internal DNS Namespace(s) only

Follow Track 1

Follow Track 2

Follow Track 3
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.1: Track Choices One to Three for DNS Namespace and Server Infrastructure Design
Organisation-Wide AD Plan - Approach for Process to Design DNS Namespace Strategy & Server Infrastructure – Track 1
Determination of the DNS Namespace Design Requirements to Support an Active Directory Infrastructure Track 1 Determination of the DNS Server Infrastructure Requirements to Support an Active Directory Infrastructure

Execution of a DNS Namespace Gap Analysis Against Legacy (NT 4.0) Domain Name(s) Only

Design of a DNS Namespace Strategy

DO NOTHING

Design of a DNS Server Infrastructure

END
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.2: “Track 1” Approach for the Design of a DNS Namespaces Strategy and Server Infrastructure Note that the DNS namespace gap analysis will consider only the differences between the Active Directory DNS namespace requirements, and the requirements to use legacy (Windows NT 4.0) domain names (where applicable). Following the execution of the DNS namespace gap analysis, there may be the requirement to either develop a design (new / modify existing) for one or more DNS namespaces, or use the existing DNS namespace(s) without modification (do nothing). The “Track 2” approach for the design of a DNS server infrastructure assumes that the analysis of any (where present) existing DNS infrastructures has not revealed any in-scope DNS servers for use to support the defined scope of the Active Directory infrastructure.

Page 69 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Analysis of AD DNS Namespace Design Requirements START
Determination of the Number of Required DNS Namespaces and their Owners

DNS Namespace Gap Analysis

DNS Namespace Design

Determination of Differences Between Existing NT 4.0 Domain Names and Identified DNS Requirements

Determination of the Requirements for the Design of a DNS Namespace Design Model

Design of a DNS Namespace Design Model

Track 1

Identification of DNS Namespace Design Tasks

Determination of the Requirement to Design a DNS Namespace Design Model

Design New DNS Namespaces and / or Domain Names Within DNS Namespaces

Determination of Requirement to Use Legacy (NT 4.0) Domain Names

END
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.3: Illustration of the Breakdown of the Components for the DNS Namespace Design Process for “Track 1” (see later for details) The gap analysis (see later for details) for “Track 1” will compare the design requirements for the Active Directory DNS namespace against the requirements to use the legacy (Windows NT 4.0) domain names (where present and applicable). Where an organisation has one or more existing Windows NT 4.0 domain infrastructures, then the first step in the DNS namespace gap analysis for “Track 1” will determine the following appropriate design tasks where: • An organisation wishes to consider the use of NetBIOS domain names within a DNS namespace, the DNS namespace gap analysis will determine the requirements to: ♦ Re-design or modify the NetBIOS domain names to comply with internet guidelines for domain naming, or ♦ Use the NetBIOS domain names without any modifications, and hence only required to design the root domain name(s) for each DNS namespace • An organisation does not wish to consider the use of NetBIOS domain names within a DNS namespace, then the DNS namespace gap analysis will determine the requirement to design all DNS root domain and child domain names, as appropriate Where an organisation does not have one or more existing Windows NT 4.0 domain infrastructures, and are hence unable to use existing NetBIOS domain names, the DNS namespace gap analysis will determine the requirement to design all DNS root domain and child domain names, as appropriate.

Page 70 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Organisation-Wide AD Plan - Approach for Process to Design DNS Namespace Strategy & Server Infrastructure – Track 2
Determination of the DNS Namespace Design Requirements to Support an Active Directory Infrastructure Track 2 Determination of the DNS Server Infrastructure Requirements to Support an Active Directory Infrastructure

Execution of a DNS Namespace Gap Analysis Against Internet DNS Namespace(s) & Legacy NT 4.0 Domain Name(s) Only

Design of a DNS Namespace Strategy

DO NOTHING

Design of a DNS Server Infrastructure

END
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.4: “Track 2” Approach for the Design of a DNS Namespace Strategy and Server Infrastructure Note that the DNS namespace gap analysis will consider only the differences between the Active Directory DNS namespace requirements, and the requirements to use legacy (Windows NT 4.0) domain names (where applicable) and any of the Internet DNS namespaces within an organisation. Following the execution of the DNS namespace gap analysis, there may be the requirement to either develop a design (new / modify existing) for one or more DNS namespaces or use the existing DNS namespace(s) without modification (do nothing). The “Track 2” approach for the design of a DNS server infrastructure assumes that the analysis of any (where present) existing DNS infrastructures has not revealed any in-scope DNS servers for use to support the defined scope of the Active Directory infrastructure.
Organisation-Wide AD Plan - Approach for Process to Design DNS Namespace Strategy & Server Infrastructure – Track 3
Determination of the DNS Namespace Design Requirements to Support an Active Directory Infrastructure Track 3 Determination of the DNS Server Infrastructure Requirements to Support an Active Directory Infrastructure

Execution of a DNS Namespace Gap Analysis Against Legacy (NT 4.0) Domain Name(s) & All DNS Namespace(s)

Execution of a DNS Server Infrastructure Gap Analysis

Design of a DNS Namespace Strategy

DO NOTHING

Design of a DNS Server Infrastructure

END
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.5: “Track 3” Approach for the Design of a DNS Namespace Strategy and Server Infrastructure Note that following the execution of the DNS namespace and server gap analysis, there may be the requirement to either develop a design (new / modify existing) for one or more DNS namespaces / DNS server infrastructures, or use the existing DNS namespace(s) / server design(s) without modification (do nothing).

Page 71 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Analysis of AD DNS Namespace Design Requirements START
Determination of the number of required DNS namespaces and their owners Determination of requirement to use legacy (NT 4.0) domain names

DNS Namespace Gap Analysis
Determination of differences between existing NT 4.0 domain names and identified DNS requirements Determination of the requirements for the design of a DNS namespace design model

DNS Namespace Design
Design of a DNS namespace design model

Track 2

Identification of DNS namespace design tasks

Determination of the requirement to design a DNS namespace design model

Design new DNS namespaces and / or domain names within DNS namespaces

Track 3

Determination of integration requirements for AD and existing DNS namespace(s)

Determination of differences between current DNS infrastructures and requirements for integration of AD DNS namespaces

Do Nothing

END

© 2004 MUSTANSHI R BHARMAL

Figure 6.6: Illustration of the Breakdown of the Components for the DNS Namespace Design Process for “Track 2” and “Track 3” (see later for details) The analysis of the current DNS infrastructure will include the determination of the requirements for the use of any legacy Windows NT 4.0 domain names, and the determination of the integration requirements between the Active Directory DNS namespaces and the existing DNS namespaces. The analysis and gap analysis for “Track 2” and “Track 3” will produce the same results and “Track 1” with respect to the presence and use of any existing Windows NT 4.0 NetBIOS domain names. Following the results of the analysis phase, the gap analysis for “Track 2” and “Track 3” will identify any differences, and thus the requirements for DNS namespace design tasks. Where the gap analysis (see later for details) has identified differences, the organisation may either: • Determine the requirement for the design of a DNS namespace design model, and thus: ♦ Determine the design requirements for the DNS namespace design model, and ♦ Design the DNS namespace design model (during the design phase), or • Execute the identified design tasks without the use of a DNS namespace design model (during the design phase) Where the gap analysis does not identify any differences, and the current DNS namespaces thus meet all the requirements for the Active Directory DNS namespaces (including integration requirements), then there is no requirement to execute any DNS namespace design tasks (“do nothing”).

Page 72 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Analysis of DNS Server Design Requirements START

DNS Server Gap Analysis
Current DNS server software can support all identified requirements without any upgrades or modifications Do Nothing

DNS Server Design END

Analysis of the current DNS server infrastructure

Current DNS server software can support all identified requirements only after an upgrade to newer version or modification of the current version

Identification of design tasks to upgrade or modify current DNS server software Identification of design tasks to replace current DNS server software Current DNS server software cannot support all identified requirements even after modifications or upgrades to newer versions

Design of a DNS Server Infrastructure via an upgrade / modification of existing DNS server software, or design of a new DNS server infrastructure

Track 3

Determination of Windows Server 2003 DNS server requirements

Determination of differences between existing DNS server infrastructure and identified DNS server requirements

© 2 00 4 MU ST AN SH I R B H AR MAL

Figure 6.7: Illustration of the Breakdown of the Components for the DNS Server Design Process for “Track 3” (see later for details) Following the results of the analysis of the current DNS server infrastructure and the determination of the design requirements for a Windows Server 2003 DNS server infrastructure, the gap analysis for “Track 3” will identify any differences, and thus the requirements for DNS server design tasks. Where the gap analysis (see later for details) has identified differences, the organisation will have to execute the following appropriate tasks: 1. 2. 3. Identify the tasks required to design upgrades or modifications to the current DNS software to permit support of all identified requirements Identify the tasks required to replace the current DNS server software with DNS server software that will meet all of the identified requirements Execute the identified design tasks to design a DNS server infrastructure via upgrades / modifications or replacement with a different DNS server software (during the design phase)

Where the gap analysis does not identify any differences and the current DNS server infrastructure thus meets all the requirements to support the defined scope of the Active Directory infrastructure, there is no requirement to execute any DNS server design tasks (“do nothing”). 5.4.4. Illustration of Approach to Design a DNS Client Infrastructure The following figures illustrate the proposed approach for this process to design the DNS client component of a DNS infrastructure:

Page 73 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Organisation-Wide AD Plan - Approach for Process to Design a DNS Client Infrastructure START
Analysis of Existing DNS Infrastructure(s)

No Internal DNS Server Infrastructure + No DNS Namespace(s)

No Internal DNS Server Infrastructure + Internet Namespace(s) (ISP Hosted)

Internal DNS Server Infrastructure + Internet DNS Namespace(s) only

Internal DNS Server Infrastructure + Internet + Internal DNS Namespace(s)

Internal DNS Server Infrastructure + Internal DNS Namespace(s) only

No existing Windows DNS clients

Existing Windows DNS clients Track 4 = Windows operating system dependent requirements

Follow Track 4

Follow Track 5

END

Track 5 = DNS client configuration requirements
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.8: Track Choices Four and Five for DNS Client Design The track choices reflect the requirement to determine compatibility of operating system (“Track 4”) and configuration of DNS clients (“Track 5”) with identified design requirements for the Windows DNS client infrastructure.
Analysis of Windows DNS Client Design Requirements START Windows DNS Client Gap Analysis
Identification of the requirement to upgrade Windows operating systems, and the minimum Windows operating system required

Windows DNS Client Design
Design of process to implement required Windows DNS client configurations on upgraded / current Windows operating systems

Current operating systems do not operate Windows DNS clients

Analysis of the current Windows DNS client infrastructure

Current Windows operating systems meet all identified operating system dependent design requirements

Track 4

Identification of the modifications to be implemented to the current configurations of the Windows DNS clients

DO NOTHING No modifications required to current Windows DNS client configurations

END

Determination of Windows DNS client design requirements

Conduction of a DNS client gap analysis against current operating system versions of Windows clients and identified DNS client design requirements

Current operating systems operate Windows DNS clients Track 5

Conduct gap analysis to determine requirement to modify current DNS client configuration

© 2004 MUSTAN SHI

R

BHARMAL

Figure 6.9: Illustration of the Breakdown of the Components for “Track 4” and “Track 5” of the Process to Design the Windows DNS Client Infrastructure (see later for details). Note that the approach for “Track 4” for the design of a DNS client infrastructure assumes the presence of current Windows clients that are either current DNS clients or potential DNS

Page 74 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

clients (Windows 95, 98, NT 4.0, Windows 2000, Windows XP Professional, and Windows Server 2003) “Track 4” of the Windows DNS client gap analysis will determine the compatibility of the current Windows operating system with all identified design requirements, and will hence reveal: • The requirement to upgrade the operating system or service pack (where appropriate) of the current Windows clients for the DNS infrastructure (whether absent or present) to a version that supports all identified operating system dependent design requirements for the Windows DNS client infrastructure, or • That the current Windows operating system and service pack (where appropriate) for the clients of the DNS infrastructure supports all identified operating system dependent design requirements for the Windows DNS client infrastructure, but requires modifications to the configuration of the DNS client software (where currently in use) to permit full compliance with design requirements. Where “Track 4” of the Windows DNS client gap analysis determines that, the current Windows operating system supports all operating system dependent design requirements, and the organisation has a current DNS client infrastructure, proceed with “Track 5” of the Windows DNS client gap analysis. If the organisation does not have an existing DNS client infrastructure, then proceed to the design of the process to implement the required Windows DNS client configurations on the upgraded / current Windows operating systems. Note that the approach for “Track 5” for the design of a DNS client infrastructure assumes: • The presence of current Windows DNS clients, and hence • The presence of current Windows clients for a DNS infrastructure (Windows 95, 98, NT 4.0, Windows 2000, Windows XP Professional, Windows Server 2003) Thus, the Windows DNS client gap analysis will consider the differences between the identified Windows DNS client design requirements, and the current configurations of Windows DNS clients. Where the Windows DNS client gap analysis identifies that the current configuration of the Windows DNS clients supports all identified design requirements, then there will be no design tasks (do nothing). 5.5. Process Components Based upon the above approach, the process to design a DNS infrastructure, to support the defined scope of the Active Directory infrastructure, is composed of the following components: • Determination of the requirements for multiple DNS infrastructures, and the boundaries for each required DNS infrastructure • Execution of a detailed analysis of each existing DNS infrastructure • Determination of the design requirements for a DNS namespace strategy • Execution of a DNS namespace gap analysis • Generation of the design for a DNS namespace strategy • Determination of the design requirements for a DNS server infrastructure • Execution of a DNS server gap analysis

Page 75 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Generation of the design for a DNS server infrastructure • Determination of the design requirements for a DNS client infrastructure • Execution of a DNS client gap analysis • Generation of the design for a DNS client infrastructure 5.6. Deliverables of Process Components This process will have the following deliverables: • The identification of the requirement for one or multiple DNS infrastructures within an organisation • The identification of the scope and boundary of a Active Directory infrastructure that each new DNS infrastructure will support • The identification of the presence or absence of any existing DNS infrastructures within each defined scope of an Active Directory infrastructure (for a new DNS infrastructure) • The identification of the details of any current DNS infrastructure(s), identifying their purpose, function, namespaces, scope and so on • The DNS namespace component of this process will have the following deliverables via the execution of the appropriate analysis, gap analysis and design tasks: ♦ The identification of the presence or absence of any internal and Internet registered DNS namespaces within each identified existing DNS infrastructure ♦ The identification of the requirement to either retain the current DNS namespace(s) to support a new Windows Server 2003 Active Directory infrastructure or to design new DNS namespaces ♦ Where there is the requirement to design new DNS namespaces, then the DNS namespace component of this process will have the following deliverables:  Identification of the number of DNS namespaces required, and the owners of each DNS namespace within an organisation  Identification of the design requirements for a DNS namespace strategy where an organisation does not have an existing DNS namespace infrastructure  Identification of the design requirements for a DNS namespace strategy where an organisation has one or more existing DNS namespace infrastructures  Identification of the design tasks for the DNS namespace strategy following execution of the DNS namespace gap analysis  Identification of the requirement to design a DNS namespace design model  The design of a DNS namespace design model  The design of a DNS namespace strategy to support the defined scope of the Active Directory infrastructure • The DNS server component of this process will have the following deliverables via the execution of the appropriate analysis, gap analysis and design tasks: ♦ The identification of any existing internal DNS servers within each identified existing DNS infrastructure

Page 76 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ The identification of the function, support, role, and configuration details for each existing internal DNS server ♦ The identification of the requirement to:  Design a new (recommended) Windows Server 2003 DNS server infrastructure to support the defined scope of the Active Directory infrastructure where the organisation does not have any existing internal DNS servers.  Use the current DNS server infrastructure(s) to support the defined scope of the Active Directory infrastructure without any upgrades or modifications where it permits support of all identified software and configuration dependent design requirements for the DNS server infrastructure. Where it is possible to identify this requirement, no design tasks are required.  Use the current DNS server infrastructure(s) to support the defined scope of the Active Directory infrastructure following the upgrade of the current DNS server software to a newer version that permits support for all identified software dependent design requirements.  Use the current DNS server infrastructure(s) to support the defined scope of the Active Directory infrastructure following the modification of the current DNS server configuration to permit compliance with all identified configuration dependent design requirements. This deliverable assumes that it is determined that the current DNS server software permits support of all software dependent design requirements for the DNS server infrastructure.  Replace the current DNS server infrastructure with a different DNS server software platform where the current DNS server software (or any currently available new versions or service packs) does not comply with all identified software dependent design requirements. • Where there is a requirement to design a new (recommended) Windows Server 2003 DNS server infrastructure, then the DNS server infrastructure component of this process will have the following deliverables: ♦ Identification of the requirements for the design of a name resolution strategy ♦ Identification of the requirements for the design of DNS zones, and replication of DNS zones between DNS servers ♦ Identification of the requirements for the design of the integration of DNS with DHCP and / or WINS infrastructures ♦ Identification of the requirements for the design of the configuration of the new DNS servers ♦ Identification of the requirements for the build, deployment, and configuration of required DNS servers ♦ The design of a process to build, deploy, and configure all new Windows Server 2003 DNS servers within the target production environment for an organisation • Where there is a requirement to upgrade existing DNS server software to a newer version that permits compliance with all software-dependent design requirements for the DNS server infrastructure, then the DNS server infrastructure component of this process will have the following deliverables: ♦ The identification of the design tasks necessary to upgrade the DNS server software on the existing DNS servers

Page 77 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ The design of a process to upgrade the existing DNS server software to a newer version • Where there is a requirement to modify the configuration of existing DNS servers to permit compliance with all configuration-dependent design requirements for the DNS server infrastructure, then the DNS server infrastructure component of this process will have the following deliverables: ♦ The identification of the design tasks necessary to modify the current configuration on the relevant DNS servers to permit compliance with all configuration-dependent design requirements for the DNS server infrastructure ♦ The design of a process to modify the configuration of the existing DNS servers • Where there is a requirement to replace (migrate) existing DNS server software with different DNS server software that permits compliance with all software-dependent design requirements for the DNS server infrastructure, then the DNS server infrastructure component of this process will have the following deliverables: ♦ The identification of the design tasks necessary to replace and migrate the current DNS servers (including DNS data and (where appropriate) DNS configuration information) from the existing DNS server software platform to a different DNS server platform. ♦ The design of a process to replace the existing DNS server software platform with a new DNS server platform • The Windows DNS client component of this process will have the following deliverables via the execution of the appropriate analysis, gap analysis and design tasks: ♦ The identification of the presence or absence of any existing Windows client infrastructure supported by an existing DNS infrastructure ♦ The identification of the operating system(s) and service pack versions for these Windows clients, and the details of the configuration of the DNS client software (where applicable) ♦ The identification of the requirement to:  Use the current Windows client infrastructure following the upgrade of the Windows operating system to a newer version that permits support for all identified operating system dependent design requirements for the Windows DNS client infrastructure.  Use the current Windows DNS client infrastructure following the modification of the current Windows DNS client configuration to permit compliance with all identified configuration dependent design requirements. This deliverable assumes it is determined that the current Windows operating system for the current / potential Windows DNS clients permits support for all operating system dependent design requirements for the Windows DNS client infrastructure.  Use the current Windows DNS client infrastructure without any upgrades to the operating system, or modifications to the configuration of the DNS client where the current Windows operating system and DNS client configuration complies with all identified operating system and configuration dependent design requirements. This deliverable will have no further associated design tasks. • Where there is a requirement to upgrade the operating system of the existing Windows DNS clients, then the Windows DNS client component of this process will have the following deliverables:

Page 78 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ The identification of the design tasks necessary to upgrade the Windows operating system on one or more existing current / potential Windows DNS clients ♦ The design of a process to upgrade the existing Windows operating system to a newer version that complies with all operating system dependent design requirements • Where there is a requirement to implement one or more modifications to the current configuration of the existing Windows DNS clients, then the Windows DNS client component of this process will have the following deliverables: ♦ The identification of the design tasks necessary to modify the current Windows DNS client configuration to comply with all configuration dependent design requirements ♦ The design of a process to implement the identified modifications to the current DNS client configuration 5.7. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies: Organisation-Wide AD Plan - Inter-Component Dependencies for Process to Design a DNS Infrastructure
Determination of the requirements for multiple DNS infrastructures

START

Analysis of existing DNS infrastructure(s)

Determination of the design requirements for a DNS server infrastructure

Determination of the design requirements for a DNS namespace strategy

Determination of the design requirements for a DNS client infrastructure

Execution of a DNS server gap analysis

Execution of a DNS namespace gap analysis

Execution of a DNS client gap analysis

Generation of design for DNS server infrastructure

Generation of design for DNS namespace strategy

Generation of design for DNS client infrastructure

END
LEGEND:

ANALYSIS

GAP ANALYSIS

DESIGN
© 2004 MUSTANSHI
R

BHAR

MAL

5.8.

Process to Design a DNS Infrastructure This design methodology has partitioned the process to design a DNS infrastructure into the three sections that collectively represent the three primary components of a DNS infrastructure (DNS namespace, servers, and clients). The following table (table 6.1) depicts the three sections for this process:

Page 79 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Part 1

Process Component Determination of the Requirement for Multiple DNS Infrastructures Analysis of Existing DNS Infrastructure(s)

Deliverables For Each Component Determination of the number of DNS infrastructures required Determination of the details of existing DNS infrastructures (where applicable) Determination of the details of the existing DNS namespace infrastructure (where applicable) Determination of the details of the existing DNS server infrastructure (where applicable) Determination of the details of the existing Windows / DNS client infrastructure

Determination of the DNS Namespace Design Requirements

Determination of the number of DNS namespaces required and their owner(s) to support the Windows Server 2003 Active Directory infrastructure Determination design requirements for a DNS namespace strategy where an organisation has no existing DNS namespace infrastructure (“Track 1” of this process) Determination of the design requirements for a DNS namespace strategy where an organisation has one or more existing DNS namespaces (“Track 2” and “Track 3” of this process)

DNS Namespace Gap Analysis

Execution of a DNS namespace gap analysis for “Track 1” of this process Execution of a DNS namespace gap analysis for “Track 2” and “Track 3” of this process Determination of the requirement to design a DNS namespace design model Determination of the design requirements for a DNS namespace design model

Design of DNS Namespace Strategy 2 Determination of the Design Requirements for a DNS Server Infrastructure

Design of DNS namespace design model (where required) Design of a DNS namespace strategy Determination of the business and technical design requirements for a DNS server infrastructure Determination of the Active Directory related design requirements for a DNS server infrastructure Execution of a DNS server gap analysis for “Track 3” of this process Design of a DNS server infrastructure Design of a process to build, deploy, and configure DNS servers Design of a process to upgrade and configure DNS servers Design of a process to modify the configuration of DNS servers Design of a process to migrate one or more existing DNS servers to a new DNS server software platform

DNS Server Gap Analysis Design of DNS Server Infrastructure

Page 80 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Part 3

Process Component Determination of the Design Requirements for DNS clients DNS Client Gap Analysis Design of a DNS Client Infrastructure

Deliverables For Each Component Determination of the design requirements for a Windows DNS client infrastructure (“Track 4” of this process) Execution of a Windows DNS client gap analysis for “Track 4” and “Track 5” of this process Design of a Windows DNS client infrastructure

Table 6.1: Sections and Components for Process to Design a DNS Infrastructure The following flow charts provided by this design methodology reflect the above three parts to this process.
Organisation-Wide AD Plan – Process to Design a DNS Infrastructure – Part 1
NO Are multiple DNS infrastructures required?

START

Execute B1 – B6

Execute A1

YES

Execute A2 – A3

Execute D1 Are there any existing DNS infrastructures remaining within each analysis scope?

Execute B7

Execute A4 – A7

Which DNS infrastructure configuration exists?

YES

Execute B8 – B12

Internal DNS Server Infrastructure + Internal DNS Namespace(s) only

Internal DNS Server Infrastructure + Internet DNS Namespace(s) only

Internal DNS Server Infrastructure + Internet + Internal DNS Namespace(s)

No Internal DNS Server Infrastructure + Internet Namespace(s) (ISP Hosted)

NO Follow Track 1

For DNS Namespace & DNS Server Design

Follow Track 3

For DNS Namespace & DNS Server Design Execute B14

Follow Track 2

For DNS Namespace & DNS Server Design Execute B15

Execute B13

Execute B15

Execute B13

Execute A8

Execute A9 – A24

Execute A8

Execute A25 – A26

Execute A34 – A47

Execute B20 – B24

Execute A28 – A29

Execute A25 – A26

Execute A27

YES

Execute B17

Execute A31 – A32

Execute B16 – B17

Is there a requirement to design business usage factors for DNS namespace design model?

YES Execute A48 – A50

Is there a requirement to design a DNS namespace design model?

Execute A33

Execute B18 – B19

Execute A30 – A31

NO

Execute D3

Go To Part 2

NO Execute D2 Execute B25
© 2 00 4 MU ST AN SHI R BHA R MAL

Page 81 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Organisation-Wide AD Plan – Process to Design a DNS Infrastructure – Part 2
From Part 1 Execute B26 – B30 Execute A51 – A66 Execute B31 – B32 Execute A67 – A69 Execute B33 Execute A70 – A84

Execute B37 – B38

Execute A88 – A92

Execute B36

Execute A85 – A87

Execute B34 – B35

Which track is organisation following?

Track 1

For DNS Namespace & DNS Server Design For DNS Namespace & DNS Server Design

Execute B41

Execute D4 – D6

Track 2 Track 3 For DNS Namespace & DNS Server Design

YES Execute B39 – B40 Execute A93 – A98 Is there a requirement to upgrade existing DNS server software? Is there a requirement to upgrade existing DNS server software?

Execute D7 – D8

NO

Is there a requirement to modify the configuration on existing DNS servers?

NO

YES

Execute D4 – D6 Execute Execute A105 – A107

YES

Execute D9 – D10 Is there a requirement to replace current DNS server software? NO YES

Execute A99 – A101

NO

B41 NO

Is there a requirement to modify the configuration on existing DNS servers?

NO

Is there a requirement to replace current DNS server software?

YES

Execute D11 – D12 Go To Part 3

YES

Execute A102 – A104
© 2004 MUSTANSH
I R

BHAR

MAL

Page 82 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Organisation-Wide AD Plan – Process to Design a DNS Infrastructure – Part 3
From Part 2 Execute B42 – B43 Execute A108 – A115 Execute B44 – B45 Execute A116 – A123 Do the current Windows clients use the DNS client software?

Execute A124 – A125

YES

Execute B46

NO

Execute D13 – D15

END
© 2004 MUSTANSH
I R

BHARMAL

5.9.

Process Considerations Consider the following information when designing a DNS namespace strategy and infrastructure for an organisation to support the defined scope of the Active Directory infrastructure. Presented within the following eleven sections are the considerations for this process: 1. 2. 3. 4. 5. 6. 7. 8. 9. Considerations for the determination of the requirements for multiple DNS infrastructures Considerations for the analysis of existing DNS infrastructure(s) within an organisation Considerations for the determination of the design requirements of a DNS namespace infrastructure Considerations for the execution of a DNS namespace gap analysis Considerations for the generation of a design for a DNS namespace strategy Considerations for the determination of the design requirements for a DNS server infrastructure Considerations for the execution of a DNS server gap analysis Considerations for the generation of a design for a DNS server infrastructure Considerations for the determination of the design requirements for a DNS client infrastructure

10. Considerations for the execution of a Windows DNS client gap analysis 11. Considerations for the generation of a design for a DNS client infrastructure 5.9.1. Determination of the Requirement for Multiple DNS Infrastructures Consider the following information when determining the requirements for the design and implementation of two or more DNS infrastructures for an organisation: • Factor B1: Understanding the approach to determine the number of DNS infrastructures required for an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the number of DNS infrastructures required.

Page 83 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology recommends all organisations design and implement a single DNS infrastructure, where possible, and hence the null hypothesis for this process reflects this recommendation. However, as it is possible to design multiple DNS infrastructure, the objective of this step within this process is to assist an organisation in determination of the opportunity to disprove the null hypothesis, and thus determine the number of DNS infrastructures required. This design methodology proposes execution of the following approach to determine the number of DNS infrastructures required, to support a Windows Server 2003 Active Directory infrastructure for an organisation:  Understand the following factors influential in disproving the null hypothesis for this process:  Requirements for service isolation of a DNS infrastructure  Requirements for service autonomy of a DNS infrastructure  Requirements for data isolation of a DNS infrastructure  Understand the following factors influential in supporting the null hypothesis for this process:  Financial overheads associated with the design, implementation, and operation of multiple DNS infrastructures  Administrative and operational overheads associated with the design, implementation, and operation of multiple DNS infrastructures  Execute an analysis to identify all applicable factors within the organisation  Define criteria to qualify requirements for the design and implementation of two or more DNS infrastructures  Evaluate all identified requirements against the defined criteria and hence determine the number of DNS infrastructures required  Where there is a requirement for the design and implementation of two or more DNS infrastructures, then determine the boundary and scope (within a Windows Server 2003 Active Directory infrastructure) for each required DNS infrastructure It is important to understand that the scope of this process, to design a DNS infrastructure, is strictly from the perspective of a DNS infrastructure to support the Windows Server 2003 Active Directory infrastructure for an organisation. Hence, all investigations to determine the requirements for multiple DNS infrastructures must reflect this perspective, and not requirements to support non-Active Directory related applications, processes, and services within an organisation. • Factor B2: Understanding the influence of requirements for service isolation on the number of DNS infrastructures required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of requirements for service isolation on the number of DNS infrastructures required.

Page 84 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Service isolation, with respect to a DNS infrastructure, can take the context of one of two possible scenarios:  Isolation of the DNS infrastructure from other DNS infrastructures within the organisation  Isolation of the DNS infrastructure from service administrators of other DNS infrastructures within the organisation Both of these scenarios have the same primary goal, to prevent a compromise to the operation of any DNS services within an organisation. As the DNS service is critical to the use and operation of an Active Directory infrastructure, compromises to this service could disrupt Active Directory operations, and hence disrupt business continuity. The nature of the compromise to the operation of a DNS infrastructure may take one of many forms, such as:  The intentional or unintentional implementation of incorrect configurations to the DNS infrastructure by service administrators of other DNS infrastructures  The failure of key DNS infrastructure components beyond the control of an autonomous division, such as internal forwarder or internal root DNS servers When considering the requirement for the design and deployment of multiple discrete DNS infrastructures, to meet requirements for service isolation, consider the following:  This design methodology proposes that an organisation consider the requirements to design and implement one or more discrete DNS infrastructures where it is possible to identify the presence of one or more mission critical and line of business (LOB) applications, processes, or services that rely upon the DNS infrastructure to:  Access and use the Windows Server 2003 Active Directory infrastructure, and  Support clients of the business applications, processes, and services  Where the compromise of a DNS infrastructure leads to a service outage, this may have a direct impact on the operation of the LOB applications or processes. However, isolation of a DNS infrastructure from potential causes of service outage within an organisation (such as other service administrators within the organisation and so on) can help to assure business continuity.  Consider the reverse perspective of this requirement as well, where the extension of the scope of support of a DNS infrastructure to other applications and service may be detrimental to the continuity of DNS support for the Windows Server 2003 Active Directory infrastructure. Hence, isolation of a DNS infrastructure can effectively isolate those other applications and services from other DNS infrastructures within the organisation. • Factor B3: Understanding the influence of requirements for service autonomy on the number of DNS infrastructures required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of requirements for service autonomy on the number of DNS infrastructures required. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 85 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Service autonomy implies the discrete design, management, and operation of a DNS infrastructure from other service owners within an organisation. Hence, an organisation may require the design and implementation of one or more discrete DNS infrastructures where it is possible to identify one or more of the following:  The presence of one or more autonomous divisions within the organisation, generated via mergers and acquisitions of other previously independent organisations  The presence of one or more autonomous divisions within the organisation, generated via divestitures / spin-offs from the parent organisation (but still related to the parent organisation)  An organisation may identify the requirement to prepare a division or department for sale, and thus the requirement to design an independent and separable DNS infrastructure. Once the parent organisation considers a division as residing outside of the scope of the organisation, then it is possible to disassociate the discrete DNS infrastructure from the parent organisation without affecting the operation of other DNS infrastructure(s) within the organisation. When determining the technical requirements for the design and deployment of a service autonomous DNS infrastructure, consider the following:  A division or department within a remote location for an organisation may have local DNS servers to cater for their specific DNS requirements. They may hence require the ability to independently define and restrict the scope of support provided by these local DNS servers to certain namespaces that only represent that division. This may assist in improving performance of the DNS servers by reducing their support workload.  A division or department within an organisation may have the requirement to extend the scope of support of a DNS infrastructure to other applications and services specific to that division and not the rest of the organisation. The management requirements to facilitate this extension of scope may require service autonomy over a discrete DNS infrastructure.  A division or department within an organisation may have the requirement to comply with service level agreements (SLAs) for the DNS service, as it may be critical to the continuity of certain Active Directory enabled applications or services. Independent management of a discrete DNS infrastructure permits compliance with SLA directives for the DNS service, as it removes the dependence upon other departments or divisions within an organisation. For example, where there is a failure of a DNS server, a centralised IT department may take longer time to restore the failed DNS server than permitted by the SLA for the DNS service. Compromises to the SLA may result in unacceptable financial and political consequences. When determining the business requirements for the design and deployment of a service autonomous DNS infrastructure, consider the following:  A division or department within an organisation may have the requirement to comply with service level agreements (SLAs) for a DNS service (as described above).  A division or department within an organisation may be financially responsible for the server and network infrastructure that will support the DNS service. Hence, there may be a requirement to extend the scope of ownership and management to the DNS service as well, thus generating the requirement for a discrete DNS infrastructure for service autonomy.  Spin-offs and divestitures will require financial autonomy from the parent organisation, and thus this may extend to a discrete DNS infrastructure.

Page 86 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor B4: Understanding the influence of requirements for data isolation from service owners, on the number of DNS infrastructures required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of requirements for data isolation from service owners, on the number of DNS infrastructures required. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Data isolation from service owners within an organisation implies the imposition of a physical and / or logical security barrier around a discrete DNS infrastructure, to control access to data held within a DNS infrastructure. This design methodology proposes that the data, held within a DNS infrastructure, which may require isolation from service owners and administrators within an organisation, includes the following:  The resource records for hosts, services, protocols and so on within a DNS zone database  The IP addresses for DNS servers within a name resolution strategy for a DNS infrastructure When determining the requirements for the design and deployment of a discrete DNS infrastructure to provide data isolation from within an organisation, consider the following:  Data isolation is only effective where there is complimentary network and physical security for the DNS servers within a DNS infrastructure.  Examples of requirements for the design and implementation of one or more discrete DNS infrastructures, to support data isolation from service owners and administrators within an organisation, include:  A division or department within an organisation may extend the scope of a DNS infrastructure to support, for example, partners and clients of that division. The partners and clients may use, for example, the DNS infrastructure to access applications or services hosted by the division. Hence, it may be necessary to isolate the details of their partner and client machines stored within appropriate DNS zone files.  A division or department may be collaborating with other organisations in projects, and use, for example, a shared root DNS server. The details of this DNS server may require isolation from other DNS infrastructures within an organisation to protect the partner infrastructure.  There may be a requirement for a discrete DNS infrastructure, to support a defined scope of an Active Directory infrastructure, where the DNS data may require exposure to the Internet to support access requirements for external clients. For example, where a front-end Exchange Server 2003 resides within a firewall partitioned perimeter network (or DMZ) and the firewall policies prevent inbound network traffic across UDP and TCP port 53, then the server cannot contact an internal DNS server. Hence, it may be necessary to implement a DNS server within the DMZ. The DNS server may hence require discrete deployment and management to an existing or proposed DNS infrastructure, and require configuration with limited resource records that unnecessarily do not expose any internal servers. • Factor B5: Understanding the influence of financial overheads on the number of DNS infrastructures required

Page 87 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of financial overheads on the number of DNS infrastructures required. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Each discrete DNS infrastructure required within an organisation will generate financial overheads, and these hence require consideration in the definition of the criteria to qualify requirements for multiple DNS infrastructures. For all requirements to design and implement discrete DNS infrastructures to support service isolation, service autonomy, and data isolation from service owners, it is necessary to consider the following examples of financial overheads associated with the design of discrete DNS infrastructures:  The overheads associated with the requirement to generate a design for each discrete DNS infrastructure  The overheads associated with the requirements to test, pilot, and implement each discrete DNS infrastructure  The overheads potentially associated with the requirements for discrete DNS server hardware, especially where the DNS infrastructure  Where there is a requirement for the design and implementation of a third-party DNS server solution, then there may be overheads associated with the costs for the solution and licences for clients of the DNS infrastructure  The overheads associated with the requirements to physically secure the DNS servers within the DNS infrastructure  The overheads associated with the management and monitoring of each discrete DNS infrastructure within the intended environment for an organisation • Factor B6: Understanding the influence of administrative and operational overheads on the number of DNS infrastructures required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of administrative and operational overheads on the number of DNS infrastructures required. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Each discrete DNS infrastructure that requires design and implementation within its intended environment for an organisation will generate management and operational overheads, and these hence require consideration in the definition of the criteria to qualify requirements for multiple DNS infrastructures. For all requirements to design and implement discrete DNS infrastructures to support service isolation, service autonomy, and data isolation from service owners, it is necessary to consider the following examples of management and operational overheads associated with the design of discrete DNS infrastructures:  The overheads associated with the execution of routine administrative tasks on a DNS infrastructure will require replication for each discrete DNS infrastructure required by an organisation. Where discrete DNS infrastructures are required to support service autonomy, then the autonomous divisions may already have DNS administrators, and hence there may not be any perceived administrative overheads for their discrete DNS infrastructure. However, where DNS infrastructures are

Page 88 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

required to support service or data isolation, and required administration by a single IT administration team, then the presence of these additional DNS infrastructures may generate significant administrative overheads for the DNS administrators.  The overheads associated with the maintenance of a logical separation of virtual DNS infrastructures. Where an organisation has identified the requirements for the design and implementation of a discrete “virtual” DNS infrastructure, and not an “actual” DNS infrastructure, then there may be significant administrative overheads associated with maintaining separation of the logical boundaries of a virtual DNS infrastructure, operating upon an actual DNS infrastructure. Note that the implementation of strict service isolation for a DNS infrastructure relies upon the design of independent components for the DNS infrastructure. This hence implies the requirements for the design of an independent name resolution strategy, where no internal components of the strategy fall within the scope of the internal DNS infrastructure and are shared with other internal DNS infrastructures. Management of independent name resolution strategies may generate significant overheads within large organisations. All DNS infrastructures, supporting requirements for service isolation, service autonomy, and data isolation, will require discrete DNS servers, with exclusive scopes for support. Note that a DNS infrastructure, to support requirements for service isolation, requires creation as an “actual” DNS infrastructure, and not a “virtual” infrastructure. A virtual DNS infrastructure in this scenario would involve the use of DNS components that are beyond the direct control of the service owners of the majority of the DNS infrastructure. For example, a DNS infrastructure may comprise of three DNS servers supporting two DNS namespaces and Windows DNS clients. However, if the design of the name resolution strategy for this DNS infrastructure relies upon, for example, forwarding name queries to an internal forwarder DNS server (that primarily supports another DNS infrastructure, or managed by discrete service administrators), then this results in a virtual DNS infrastructure. Note that independence in DNS service operation places the onus on maintenance of service levels on the owner of the DNS infrastructure. This may be beneficial to the division or department within an organisation where the operational continuity of the DNS infrastructure has a direct impact on business continuity. Discrete or autonomous divisions within an organisation that own a service isolated DNS infrastructure can design and operate their own service level agreements (SLAs). Note the following with respect to the use of virtual and actual DNS infrastructures designed to meet requirements for service autonomy:  A DNS infrastructure with an intended scope of support restricted to the defined scope of an Active Directory infrastructure will require design and deployment as an actual DNS infrastructure.  A DNS infrastructure with an intended scope of support to include other applications and services may require design and deployment as a virtual DNS infrastructure. However, the other applications and services must be within the autonomous control of the division or department that requires this service autonomous DNS infrastructure. • Factor A1: Identification of factors applicable to an organisation, to determine the number of potential DNS infrastructures required

Page 89 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the potential (unqualified) number of DNS infrastructures (virtual and actual) required via the execution of an analysis to identify all applicable factors. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes execution of the following approach to identify all applicable factors within an organisation:  Evaluate requirements for the design and implementation of one or more discrete DNS infrastructures to support service isolation via execution of the following example analyses:  Execution of an analysis within the organisation to identify line of business applications, services, and processes that require service isolation  Execution of an analysis within the organisation to identify requirements to isolate one or more secondary DNS infrastructures from one or more primary DNS infrastructures for an organisation  Evaluate requirements for the design and implementation of one or more discrete DNS infrastructures to support service autonomy via execution of the following example analyses:  Execution of an analysis within an organisation to identify requirements for service autonomy to support the presence of one or more IT autonomous divisions within the organisation  Execution of an analysis within an organisation to identify requirements for service autonomy to support the pending divestiture of one or more divisions within an organisation  Evaluate requirements for the design and implementation of one or more discrete DNS infrastructures to support data isolation via execution of the following example analyses:  Execution of an analysis within an organisation to identify requirements to secure and control access to sensitive DNS data  Execution of an analysis within an organisation to identify requirements for compliance with legal constraints to ensure the security of specific DNS data  Where an organisation is able to identify the potential requirements for the design and implementation of one or more discrete DNS infrastructures, then determine the requirements for the design and implementation of the potential discrete DNS infrastructures as virtual or actual DNS infrastructures.  Where it is not possible to identify any applicable factors that support the opportunity to disprove the null hypothesis for this process, and hence the requirements for the design of multiple DNS infrastructures, then a single actual DNS infrastructure will be required for the organisation. Using the above information and approach, execute the following:  Execute an analysis to identify and document all factors, applicable to an organisation, which support the opportunity to disprove the null hypothesis for an organisation.

Page 90 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where it is possible to identify one or more applicable factors, then determine and document the number of potential discrete DNS infrastructures required, in addition to the primary DNS infrastructure for an organisation.  For each potential discrete DNS infrastructure, determine and document the requirements for the design and implementation of that DNS infrastructure as a virtual or actual DNS infrastructure. Note that the supporting requirement for the DNS infrastructure may dictate whether the DNS infrastructure is required to be a virtual or actual DNS infrastructure. For example, it is necessary to design and implement a DNS infrastructure, to support requirements for service isolation, as an actual and not virtual DNS infrastructure.  Determine the potential owner(s) for each potentially required DNS infrastructure • Factor A2: Definition of criteria to qualify potential requirements for the design and implementation of two or more DNS infrastructures within an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the potential and unqualified requirements for the design and implementation of one or more additional DNS infrastructures, to support service isolation, service autonomy, and / or data isolation, and  Wishes to define the criteria to qualify the requirements for the design and implementation of two or more DNS infrastructures within the organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When defining the criteria to qualify the requirements for the design and implementation of multiple DNS infrastructures, consider the following:  The criteria to qualify the requirements for multiple DNS infrastructures must reflect all identified business and technical design goals for the Windows Server 2003 Active Directory infrastructure, and the management and financial overheads associated multiple DNS infrastructures.  It is important to note that these criteria are to qualify the requirements for two or more DNS infrastructures. It is also possible to apply these criteria to determine the number of DNS infrastructures required for autonomous divisions within an organisation.  For example, an organisation is required to support multiple autonomous divisions, and each division will be required to execute an independent migration from their legacy directory service infrastructure(s) to the new single Windows Server 2003 Active Directory infrastructure for the parent organisation. In this scenario, the parent organisation is required to define how many DNS infrastructures they require, as the entire organisation, via these criteria. However, the organisation may also reverse these criteria for their autonomous divisions, and state, for example, the null hypothesis: “The primary DNS infrastructure for the organisation will support all Active Directory infrastructures for autonomous divisions, unless they can demonstrate compliance with the criteria to support the design and implementation of one or more additional DNS infrastructures”  The onus is then with the autonomous divisions to identify any business and technical requirements, which may support the design of one or more additional DNS infrastructures specific to that division, via compliance with the criteria defined by the parent organisation.

Page 91 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Similar to the approach to determine the requirements for multiple forests, it is necessary to involve all appropriate personnel in the definition of the criteria to qualify requirements for additional DNS infrastructures within the organisation. Note that the onus is with the organisation to decide which personnel to invite to assist in the definition of the criteria to qualify requirements for multiple DNS infrastructures.  This design methodology recommends, where possible, exclusion of stakeholders in the requirements for additional DNS infrastructures, as they may have a stake in definition of the criteria to accept their specific requirements for one or more additional DNS infrastructures.  Due to significant short and long-term impact within an organisation, of the design and implementation of multiple DNS infrastructures, the criteria to qualify the requirements for multiple DNS infrastructures require objective, and not subjective definition.  This design methodology recommends that the criteria, to qualify requirements for the design and implementation of multiple DNS infrastructures, require definition from the perspective of supporting the null hypothesis for this process.  Although the onus is with the organisation to define their specific criteria, this design methodology proposes the following examples of criteria to qualify the requirements for the design and implementation of multiple DNS infrastructures:  The requirement for an additional DNS infrastructure must reflect a requirement associated with the execution of this project, and not independently of this project to design and implement a Windows Server 2003 Active Directory infrastructure. (This criterion reflects the requirement for consideration and qualification of additional DNS infrastructure requirements authorised by the organisation, and not existing legacy or new DNS infrastructures, designed and implemented by autonomous divisions within the organisation).  The requirement for an additional DNS infrastructure must reflect one of the following factors supported by this organisation: • The requirements for service and / or data isolation from service owners, to support genuine business and technical requirements • The requirements for service autonomy, to support discrete financial budgets within autonomous divisions  Any autonomous divisions that require the design and implementation of an additional forest are required to take responsibility for all financial and administrative overheads with its design, testing, implementation, operation, and management, in compliance with directives <x, y, and z>. This criterion is necessary to qualify requirements for a service autonomous DNS infrastructure.  All requirements for a discrete DNS infrastructure, to support service and data isolation, must have a supporting physical and network infrastructure to ensure separation of the corresponding DNS infrastructures within the organisation. Using the above information and approach, execute the following:  Define and document the criteria to qualify the requirements for the design and implementation of each required DNS infrastructure, additional to the primary production DNS infrastructure to support the Windows Server 2003 Active Directory infrastructure for the organisation.  Evaluate all potential DNS infrastructure requirements, from the previous analysis, against these defined criteria, and document the results.

Page 92 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the final number of DNS infrastructures required, identifying the qualifying criterion / criteria for each required DNS infrastructure. • Factor A3: Determination of the scope of support for each required DNS infrastructure within an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the qualified requirements for the design and implementation of one or more additional DNS infrastructures, to support service isolation, service autonomy, and / or data isolation, and  Wishes to determine the scope of the Windows Server 2003 Active Directory infrastructure for an organisation that each required DNS infrastructure will be required to support ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the scope of a Windows Server 2003 Active Directory infrastructure that each required DNS infrastructure will support, consider the following:  Where an organisation has identified the qualified requirements for the design and implementation of two or more actual or virtual DNS infrastructures, it is necessary to partition the supported Windows Server 2003 Active Directory infrastructure across each required DNS infrastructure.  This design methodology proposes execution of the following approach to determine the scope of a Windows Server 2003 Active Directory each required DNS infrastructure will support:  Understand the influence of the function and requirements for a discrete DNS infrastructure, on the scope of its support for a Windows Server 2003 Active Directory infrastructure  Understand the components of a DNS infrastructure that will influence determination of the scope of support by a DNS infrastructure  Understand the influence of requirements for virtual and actual DNS infrastructures on the determination of the scope of support by a DNS infrastructure  Understand the components of a Windows Server 2003 Active Directory infrastructure an organisation may partition, to determine the scope of support by a DNS infrastructure  Define the scope of support for each DNS infrastructure via determination of the largest components of the proposed Windows Server 2003 Active Directory infrastructure the owner(s) of each required DNS infrastructure will support. When attempting to understand the influence of the function and requirements for a discrete DNS infrastructure, on the scope of its support for a Windows Server 2003 Active Directory infrastructure, consider the following:  A discrete DNS infrastructure required support requirements for service isolation is typically associated with a corresponding service isolated Windows Server 2003 forest. Hence, in such scenarios, the boundary and scope of the supported and service isolated forest defines the scope of support for this DNS infrastructure.

Page 93 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A discrete DNS infrastructure required to support service autonomy is typically associated with a corresponding service autonomous Windows Server 2003 Active Directory component, such as a forest, tree of domains, or domain. Hence, in such scenarios, the boundary and scope of the supported and service autonomous Active Directory component defines the scope of support for this DNS infrastructure. When attempting to understand the components of a DNS infrastructure that influence the scope of support by the DNS infrastructure, consider the following:  A DNS infrastructure is comprised of the following three primary components:  The DNS namespaces supported by the DNS infrastructure  The DNS clients of a DNS infrastructure  The DNS servers that support the DNS clients and the DNS namespaces of a DNS infrastructure  It is possible to use the DNS namespace and DNS client components, either individually or together, to determine the scope of a Windows Server 2003 Active Directory infrastructure that the DNS infrastructure will support. It is not possible to determine the scope of a DNS infrastructure based upon the DNS server component, because a DNS server can:  Host any number of DNS namespaces that represent trees of Active Directory domains in any number of forests  Support any number of DNS clients directly or indirectly (for example, via participation within a name resolution strategy) When attempting to understand the influence of requirements for virtual and actual DNS infrastructures on the determination of the scope of support by a DNS infrastructure, consider the following:  The scope of a DNS infrastructure, whether actual or virtual, is defined by the following:  The three components of the DNS infrastructure (namespaces, clients, and servers)  The name resolution strategy for a DNS infrastructure  The elements within an organisation supported by a DNS infrastructure, such as services (Active Directory) and applications  The scope for a DNS infrastructure, when based upon the three components of the DNS infrastructure, is simple to determine. However, a name resolution strategy may have a support scope that extends beyond the boundaries of a DNS infrastructure based upon the three components, and may instead, support two or more DNS infrastructures. Thus, an actual DNS infrastructure, based upon the three components, that shares components of a name resolution strategy with other DNS infrastructures (such as a common internal root DNS server, or a common forwarder DNS server for all Internet name resolution queries) becomes a virtual DNS infrastructure with respect to name resolution.  Similarly, an actual DNS infrastructure that supports one or more applications and services, in addition to the defined scope of an Active Directory infrastructure, may become a virtual DNS infrastructure based upon this extended scope of support.

Page 94 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When attempting to understand the components of a Windows Server 2003 Active Directory infrastructure an organisation may partition, to determine the scope of support by a DNS infrastructure, consider the following:  A DNS infrastructure supports a Windows Server 2003 Active Directory infrastructure primarily via service location, within the context of a DNS namespace. Due to the relationship between service location and DNS namespaces, only those components of an Active Directory infrastructure that support DNS namespace elements present potential partitions for the scope of a DNS infrastructure.  Hence, the components of a supported Windows Server 2003 Active Directory infrastructure, which an organisation may partition across two or more DNS infrastructures, are:  Entire Windows Server 2003 forests (as a collection of one or more DNS namespaces)  Entire domain trees (as a collection of domain names within one DNS namespace)  Single domains (as a single domain namespace) Using the above information and approach determine and document the largest components of the proposed Windows Server 2003 Active Directory infrastructure that will reside within the scope of support for each required DNS infrastructure. Note that as alliance of DNS namespaces and clients to DNS infrastructures may not be determined at this stage of the analysis phase, it may be necessary to re-execute these tasks following identification of this information. • Factor D1: Generation of the design for the number of DNS infrastructures required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has executed the analysis to determine the requirements for the design of one or more DNS infrastructures, and  Wishes to generate the design for the number of DNS infrastructure required ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Whether the organisation has identified the opportunity to disprove or support the null hypothesis for this process, it is necessary to execute the appropriate analysis to determine these requirements, and document them within a design document. This step within this process will assist an organisation in the generation of the design for the number of DNS infrastructures required. This design methodology proposes the following format and content for the design of the number of DNS infrastructures required:  A detailed description of the process adopted by the organisation to present and discuss all factors influential in the determination of the number of DNS infrastructures required  A detailed description of the results of the discussions to identify applicable factors, influential in the determination of the number of DNS infrastructures required  Where an organisation was unable to identify any applicable factors, then include a statement to describe why.

Page 95 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where an organisation identified one or more applicable factors, then the design document must detail the following:  All of the potential (and unqualified) requirements for these factors  The details of the criteria to qualify the requirements for the design and implementation of multiple DNS infrastructures  The results of the evaluation of identified requirements against the defined criteria  Where the results of the evaluation against defined criteria has identified the requirements for the design and implementation of one or more additional DNS infrastructures, then detail the requirements, identifying the following:  The criteria compliance profile for the requirement  The nominated owner(s) of the additional DNS infrastructures  The function and role of the additional DNS infrastructure within the organisation  The scope of the proposed Windows Server 2003 Active Directory infrastructure each DNS infrastructure will support  Generate a diagram illustrating the logical relationships between multiple DNS infrastructures, and between the DNS infrastructures and the partitioned Windows Server 2003 Active Directory infrastructure. 5.9.2. Analysis of Existing DNS Infrastructure(s) Consider the following information when executing a detailed analysis to determine the presence of one or more existing DNS infrastructures, and the details of each identified DNS infrastructure: • Factor B7: Understanding the approach to execute a detailed analysis of all existing DNS infrastructures within an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to execute a detailed analysis of all existing DNS infrastructures. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objective of this component of this process is to assist an organisation in the execution of a detailed analysis to identify the presence of existing DNS infrastructures within the organisation, and the details of each identified DNS infrastructure. This information is invaluable to the execution of all remaining components of this process. This design methodology proposes execution of the following approach to execute a detailed analysis of all existing DNS infrastructures within an organisation:  The first step is to identify the presence of any actual and / or virtual DNS infrastructures within an organisation (see the background information section for descriptions of actual and virtual DNS infrastructures). Only where an organisation can categorically confirm the absence of any suitable DNS infrastructures within the organisation, for use in support of the defined Active Directory scope for the new DNS infrastructure, is it possible to bypass this specific analysis step.

Page 96 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 However, where an organisation can identify the presence of one or more existing actual and / or virtual DNS infrastructures then it is necessary to determine the following:  The scope of the analysis, to ensure the appropriate DNS infrastructure(s) are analysed, and  The current role, scope, and support functions provided by each existing inscope DNS infrastructure  For each identified configuration combination (of the five possible configuration combinations identified earlier) of existing DNS infrastructure, understand the potential design tasks required to permit support of the defined Active Directory scope for the new DNS infrastructure  For each identified existing DNS infrastructure, within the scope of this process (as determined by the first step above), execute the following steps:  Execute an analysis to determine the details for the current DNS namespace infrastructure  Execute an analysis to determine the details for the current DNS server infrastructure (where present)  Execute an analysis to determine the details for the current Windows DNS client infrastructure (where present) Based upon the above approach, for the execution of the analysis component of this process, presented within the following sections are the considerations for the execution of this component within this process:  Considerations for the identification of the presence of actual and / or virtual DNS infrastructures within an organisation  Considerations for the determination of the:  Scope for analysis of the appropriate DNS infrastructure(s) within an organisation  Current role, scope, and support functions provided by each existing in-scope DNS infrastructure  Considerations to assist in understanding the potential design tasks associated with each identified configuration combination for an existing DNS infrastructure  Considerations for the execution of an analysis to determine the details of the current DNS namespace infrastructure with each existing in-scope DNS infrastructure  Considerations for the execution of an analysis to determine the details for the current DNS server infrastructure (where present) within each existing in-scope DNS infrastructure  Considerations for the execution of an analysis to determine the details for the current Windows DNS client infrastructure (where present) within each existing inscope DNS infrastructure 5.9.2.1. Identification of Existing Actual / Virtual DNS Infrastructures Within the majority of organisations, it is very simple to identify the presence or absence of any existing DNS infrastructures. However, in some medium to large organisations (for example, represented within multiple geographical locations, and with multiple autonomous

Page 97 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

divisions), there may be multiple discrete DNS infrastructures performing various support functions. It is very important to identify all existing DNS infrastructures within an organisation. Where it is subsequently possible to identify the opportunity to use any of the identified existing DNS infrastructures to support the defined scope of the Active Directory infrastructure (where applicable), then this will assist in reducing the total cost of ownership associated with the design and deployment of the Windows Server 2003 Active Directory infrastructure. Consider the following information when performing an investigation to determine the presence of one or more actual / virtual DNS infrastructures within an organisation: • Factor A4: Determination of the scope of investigation for existing DNS infrastructures ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Can identify the potential for the presence of one or more existing DNS infrastructures within an organisation  Wishes to understand and determine the scope for the investigation for actual or virtual DNS infrastructures currently in use within the organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The results of the analysis to determine the number of DNS infrastructures required by an organisation to support the Windows Server 2003 Active Directory infrastructure will influence the scope of investigation for existing DNS infrastructures. For example, where a division within an organisation has identified the requirement for a discrete DNS infrastructure, then the scope for investigation for existing DNS infrastructures will be the logical and physical boundaries of the IT infrastructure for that division. Naturally, where an organisation has identified the requirement for two or more DNS infrastructures, execute this investigation within the logical and physical boundaries for each required new DNS infrastructure. Where an organisation has identified the requirement for a single DNS infrastructure, to support the entire Windows Server 2003 Active Directory infrastructure for the organisation, then the logical and physical boundaries of the Windows Server 2003 Active Directory infrastructure will define the scope of investigation for existing DNS infrastructures. Hence, for example, where a Windows Server 2003 Active Directory infrastructure for an organisation is to represent only three out of five divisions within an organisation, and one of the divisions not represented within the Active Directory infrastructure has an existing DNS infrastructure, then this DNS infrastructure will be out of the scope of investigation for this process. However, where an organisation has determine the requirement for three DNS infrastructures, then the scope of investigation for existing DNS infrastructures will be defined by the scope of support for each required DNS infrastructure within the Active Directory infrastructure. For example, where one of these three required DNS infrastructures is intended to support division “A”, and division “A” has three trees of Active Directory domains (one tree within “forest 1” and two trees of domains in “forest 2”) then the physical boundaries of these trees will define the scope of investigation of existing DNS infrastructures.

Page 98 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

This approach is adopted to support the use of existing DNS infrastructures (where present / where required) to support the Active Directory DNS requirements for the “intended” discrete DNS infrastructure. Using the above information, execute an analysis to determine and document the scope of analysis, to identify the presence of one or more existing DNS infrastructures, as defined by the logical and physical boundaries for each required DNS infrastructure. • Factor A5: Identification of actual and virtual DNS infrastructure(s) ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Can identify the potential for the presence of one or more existing actual / virtual DNS infrastructures within an organisation  Has identified the logical and physical boundaries of the scope for investigation of existing DNS infrastructures, and  Wishes to determine the presence of actual / virtual DNS infrastructures that are currently in use within the organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: An organisation may support multiple DNS infrastructures, each operating in parallel, or in isolation of each other. Examples of scenarios that support the presences of multiple existing DNS infrastructures within an organisation include:  The presence of autonomous divisions within an organisation that employ one or more discrete DNS infrastructures to support, for example, a Windows 2000 Active Directory infrastructure or intranet / Internet web sites  Sub-components of an organisation recently merged with the organisation or acquired by this organisation that employ their own DNS infrastructure It is important to note that any of the four configuration combinations for a DNS infrastructure stated earlier (within the “Process Approach” section for this process) require identification as a “DNS infrastructure”, including the fifth configuration combination of absence of DNS namespaces and internal servers (and hence Windows DNS clients). When investigating the presence of existing actual or virtual DNS infrastructures, it is important, at this stage, to identify:  Those existing DNS infrastructures that require consideration to support a Windows Server 2003 Active Directory infrastructure, as an extension of their current scope of support, and may hence require an upgrade, modification, or replacement.  Those existing DNS infrastructures that require exclusion from supporting a Windows Server 2003 Active Directory infrastructure, and hence extension of their current scope of support to encompass a Windows Server 2003 Active Directory infrastructure. Only those existing DNS infrastructures considered for support of a Windows Server 2003 Active Directory infrastructure will require inclusion within the analysis and gap analysis phases of this process.

Page 99 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

In order to identify those DNS infrastructures for inclusion within the analysis and gap analysis phases of this process, where an organisation may have multiple existing DNS infrastructures, this design methodology proposes the consideration of all existing DNS infrastructures for inclusion unless they meet specific exclusion criteria. When determining the exclusion criteria, consider the following:  Consider the impact associated with the exclusion of an existing DNS infrastructure from this process based upon defined exclusion criteria. For example, excluding an existing DNS infrastructure will require the use of either another existing DNS infrastructure, or where no other DNS infrastructures exist, then the design of a new DNS infrastructure to support the defined scope of the Active Directory infrastructure.  Consider the impact associated with the inclusion of an existing DNS infrastructure within this process based upon defined exclusion criteria. For example, the inclusion of an existing DNS infrastructure may be financially or administratively detrimental to this process where the gap analysis identifies the requirement for extensive upgrades or configuration modifications to the DNS infrastructure. Although the onus is with the organisation to define their own exclusion criteria, this design methodology provides the following example criteria for the exclusion of an existing DNS infrastructure within the analysis phase of this process:  An existing DNS infrastructure dedicated to the support of only one specific function, such as an intranet or Internet web site for the organisation, or exclusive support for the DNS requirements of an autonomous division within the organisation. The extension of this support function, to include the defined Active Directory scope for the new DNS infrastructure, may compromise the continuity or performance of the primary function.  An existing DNS infrastructure has a logical, physical, and network boundary beyond the scope of the Windows Server 2003 Active Directory infrastructure. The current boundary limitations for this existing DNS infrastructure will hence exclude this infrastructure from a support role for the Windows Server 2003 Active Directory infrastructure.  There is a requirement to migrate all current DNS namespaces and DNS clients currently supported by an existing DNS infrastructure to a new / single DNS infrastructure for an organisation. Hence, this existing DNS infrastructure will not be required following completion of all migration and consolidation exercises, and hence will require exclusion from the analysis and gap analysis phases of this process. Prior to inclusion of an eligible existing DNS infrastructure within this process, it may be necessary to:  Determine the current owner(s), within an organisation, of an identified existing DNS infrastructure  Obtain the consent and cooperation of the owner(s) for the inclusion of their identified existing DNS infrastructure within this process Using the above information, execute the following:  Execute an analysis to identify the presence of one or more of the following DNS infrastructure configurations (as actual or virtual) within an organisation:  The organisation has legacy / third party DNS server software on one or more DNS servers, with one or more DNS namespaces registered for use on the

Page 100 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Internet, and currently only used on the Internet. This DNS infrastructure may or may not support internal Windows DNS clients.  The organisation has legacy / third party DNS server software on one or more DNS servers, with one or more DNS namespaces registered for use on the Internet, and one or more DNS namespaces for use on the internal network for the organisation. This DNS infrastructure will support internal Windows DNS clients.  The organisation has legacy / third party DNS server software on one or more DNS servers, with one or more DNS namespaces for use currently only on the internal network for the organisation, and not currently exposed to the Internet. This DNS infrastructure will support internal Windows DNS clients.  The organisation does not currently operate any legacy / third party DNS server software, and hence has no DNS servers, but currently has one or more Internetregistered DNS namespaces, hosted by a third party service provider (such as an ISP) on the service provider’s DNS server infrastructure. This DNS infrastructure may not support internal Windows DNS clients.  The organisation does not currently operate any legacy / third party DNS server software, and hence has no DNS servers and internal DNS namespaces, and does not currently have any DNS namespaces registered with ICANN for use on the Internet. This environment will hence not support internal Windows DNS clients.  Determine and document the exclusion criteria for the selection of DNS infrastructures that require analysis within this process  Evaluate the DNS infrastructure configuration(s) identified within an organisation against the exclusion criteria  Use the results of the evaluation against the exclusion criteria to determine and document the actual or virtual existing DNS infrastructures that require consideration, to support a Windows Server 2003 Active Directory infrastructure, and hence require inclusion within the analysis and gap analysis phases of this process  Determine and document the current owner(s) of each identified existing actual and virtual DNS infrastructure 5.9.2.2. Determination of Current Role and Function of Each Existing DNS Infrastructure Consider the following information when determining the scope, current role, and support functions for each existing DNS infrastructure defined as being within the scope of the analysis and gap analysis phases of this process: • Factor A6: Determination of the current configuration, role, and support functions for each existing in-scope DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to include one or more existing DNS infrastructures within the analysis and gap analysis phases of this process, and  Wishes to determine the current configuration, role, and support functions of each existing DNS infrastructure within the organisation or division / department of the organisation

Page 101 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is important to identify, for each existing and now in-scope DNS infrastructure, the configuration combination for this infrastructure. As stated in the process approach, this design methodology recognises the following four possible configurations for an identified existing DNS infrastructure:  The presence of one or more Internet-registered DNS namespaces but no internal DNS servers, and hence no internal Windows DNS clients  The presence of one or more Internet-registered DNS namespaces only, with one or more internal DNS servers, and presence or absence of supported Windows DNS clients  The presence of one or more internal DNS namespaces only, with one or more internal DNS servers, and hence supported Windows DNS clients  The presence of one or more internal and Internet-registered DNS namespaces, with one or more internal DNS servers, and supported Windows DNS clients As discussed earlier, a DNS infrastructure can have either a single support function (an “actual” DNS infrastructure with respect to support functions) or multiple support functions (a “virtual” DNS infrastructure with respect to support functions). Some examples of support functions include:  Supporting access to directory services (such as Active Directory) via the use of SRV resource records  Supporting access to computers by DNS clients or applications on other computers (simple name resolution support functions)  Supporting access to services (such as web services for intranet or Internet web sites)  Supporting access to applications and processes within the organisation It is important to determine the current support functions of an existing DNS infrastructure as this information may influence the results of the analysis and gap analysis phase of this process. For example, a DNS infrastructure that currently supports a legacy (Windows 2000) Active Directory infrastructure has a higher potential for reuse to support a Windows Server 2003 Active Directory infrastructure, without major modifications or upgrades, unless dictated by design requirements. It is also important to determine any details for the future scope of support of the existing DNS infrastructure, and any potential conflicts in support scope. For example, an existing DNS infrastructure may be required to support a new application, service, or business process during or after modification to support the proposed Windows Server 2003 Active Directory infrastructure. In this scenario, it may be necessary to assess the impact of the extension of support scope on the performance of the DNS infrastructure to continue to support the proposed Windows Server 2003 Active Directory infrastructure. Using the above information, execute the following:  Determine and document the configuration of each identified existing and now inscope DNS infrastructure, with respect to DNS namespaces, servers, and Windows DNS clients

Page 102 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document any plans or proposals to extend or modify the scope of support of any existing DNS infrastructures, and the impact of such proposals on the support for the proposed Windows Server 2003 Active Directory infrastructure  Determine and document the current support functions of each identified in-scope DNS infrastructure • Factor A7: Determination of the current scope of support of an existing DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to include one or more existing DNS infrastructures within the analysis and gap analysis phases of this process, and  Wishes to determine the current scope of support of each existing DNS infrastructure within the organisation or division / department of the organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The following components of a DNS infrastructure will define the current scope of support provided by an existing DNS infrastructure:  The DNS namespace(s) that the existing DNS infrastructure supports  The DNS clients that the existing DNS infrastructure supports  The DNS server(s) within each existing DNS infrastructure that support the DNS namespaces and DNS clients It is important to establish the current logical and physical boundaries of each existing in-scope DNS infrastructure. This information will assist an organisation in determination of the impact of any extensions to the current scope of support, to encompass a Windows Server 2003 Active Directory infrastructure, on the existing support functions of the DNS infrastructure. When determining the current scope of support of an existing DNS infrastructure, consider the following:  The DNS namespaces, which represent the owners of the DNS infrastructure, typically define the logical support boundaries of that DNS infrastructure. However, a DNS server within an existing DNS infrastructure may support DNS namespaces belonging to another department or division within an organisation, and hence these DNS namespaces are theoretically out of the scope of support of this DNS infrastructure.  Where the boundaries become difficult to distinguish, determine the virtual logical boundaries for an existing DNS infrastructure that will define it scope of support, based upon ownership of DNS namespaces, DNS servers, and DNS clients.  Where the name resolution strategy, as a component of a DNS infrastructure, requires the use of, for example, a shared internal root DNS server, then exclude this DNS server from the scope of support of an existing DNS infrastructure. This exclusion is again based upon ownership of (in this case) the shared internal root DNS server. Using the above information, execute the following:

Page 103 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the logical and physical boundaries for each existing inscope DNS infrastructure, based upon the DNS namespaces, DNS clients, and DNS servers within the infrastructure.  Determine and document the actual and virtual boundaries of each existing in-scope DNS infrastructure, based upon ownership of the components of the DNS infrastructure. 5.9.2.3. Understanding the Potential Design Tasks Consider the following information where an organisation wishes to understand the potential design tasks associated with the identified configuration combination of an existing DNS infrastructure: • Factor B8: Current DNS infrastructure comprises of legacy or third party DNS server software, DNS servers, and one or more DNS namespaces for use only on the Internet ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more existing and in-scope DNS infrastructures consisting of legacy or third party DNS server software, DNS servers, and one or more DNS namespaces for use only on the Internet  Wishes to understand, based upon this current configuration of a DNS infrastructure, the possible tasks to be executed to permit the support of the defined Active Directory scope for the new DNS infrastructure ♦ Factor Considerations: Where the criteria for the application of this factor can be identified within an organisation, then consider the following information for each DNS infrastructure within the organisation that meets this criteria: This DNS infrastructure configuration occurs typically in organisations that have an internal dedicated DNS infrastructure to support Internet-facing web sites for the organisation. The Internet-only, ICANN registered DNS namespace(s) in use will reflect the identity of the organisation or divisions within the organisation represented on the Internet. As the DNS namespace is external to the organisation, this DNS infrastructure will be unlikely to support internal Windows DNS clients. Within this DNS infrastructure configuration, consider the presence of the following possible sub-combinations for the DNS server software currently in use within this DNS infrastructure:  All of the DNS server software used on all of the DNS servers within a DNS infrastructure for an organisation is from the same ISV and are the same version  All of the DNS server software used on all of the DNS servers within a DNS infrastructure for an organisation is from the same ISV but there are differences in the versions of the DNS software  There is a hybrid of DNS server software (from more than one ISV) used on all of the DNS servers within a DNS infrastructure for an organisation, but all versions of the DNS software from each ISV are the same  There is a hybrid of DNS server software (from more than one ISV) used all of the DNS servers within a DNS infrastructure for an organisation, but there are differences in the versions of the DNS software from each ISV

Page 104 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Note that the presence of variations in the DNS server software and versions of software may cause interoperability issues that will require addressing. Where possible, this design methodology recommends organisations upgrade and standardise, where appropriate, on to a single or fewer number of DNS server software platforms and versions. The DNS namespace gap analysis will identify the following possible DNS namespace design tasks (as singular tasks or combinations of tasks) required for this DNS infrastructure configuration to permit the support of the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current DNS namespace(s), where they meet all of the DNS namespace requirements for the Windows Server 2003 Active Directory infrastructure for an organisation  Design extensions or modifications to the current Internet-registered DNS namespace(s), to permit the use of these namespaces within an internal DNS infrastructure to support the defined scope of the Active Directory infrastructure  Design a new DNS namespace strategy, to support the defined scope of the Active Directory infrastructure and operate in parallel with the current Internet-registered DNS namespace(s)  Design a new DNS namespace strategy, to replace or consolidate all or some of the current Internet-registered DNS namespace(s) within the organisation and support the defined scope of the Active Directory infrastructure The DNS server gap analysis will identify the following possible DNS server infrastructure design tasks (as singular tasks or combinations of tasks) required for this DNS infrastructure configuration to permit the support of the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current DNS server infrastructure(s), to support the defined scope of the Active Directory infrastructure  Design extensions or modifications to the current DNS server infrastructure(s), to permit it to concurrently support the defined scope of the Active Directory infrastructure  Design one or more new Windows Server 2003 DNS server infrastructures, to support the defined scope of the Active Directory infrastructure and operate in parallel with the current legacy or third party DNS server infrastructure(s)  Design one or more new Windows Server 2003 DNS server infrastructures, to support all or some of the DNS service functions within an organisation and replace (via a migration and subsequent consolidation) all or some of the current DNS infrastructures within an organisation Where an organisation has one or more Internet-registered DNS namespaces, there may be reluctance to consolidate and decommission any of these into a new DNS namespace unless any of the following examples are valid:  An organisation is planning, or currently participating within, or has gone through a merger / acquisition process, and the current Internet-registered DNS namespaces no longer represent the new identity or identities of the organisation.  An organisation wishes to redesign their identity, to reflect a new business function or objective, and hence wishes to redesign their current DNS namespace strategy to comply with these requirements.

Page 105 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The use of one or more of the current DNS server infrastructures to support the defined scope of the Active Directory infrastructure is only permissible where the required DNS server infrastructure can meet all of the business and technical objectives and requirements of the DNS infrastructure for an organisation. Where a DNS server infrastructure cannot meet the entire DNS server infrastructure requirements of the organisation, then there will be the requirement to design modifications to this infrastructure to attain compliance, or proceed with another option. Where a DNS server infrastructure currently only supports Internet-facing DNS namespaces, there may be reluctance to extend the scope for this infrastructure to the support of an internal service, such as the defined Active Directory scope for the new DNS infrastructure. There is the possibility of a compromise to the availability of the DNS infrastructure to support Internet web sites where it is to be responsible for supporting multiple functions within an organisation. This may hence affect the business continuity of any Internet web sites that the organisation hosts internally. • Factor B9: Current DNS infrastructure comprises of legacy or third party DNS server software, DNS servers, and one or more DNS namespaces for use on the Internet and internally within an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more existing and in-scope DNS infrastructures consisting of legacy / third party DNS server software, DNS servers, one or more DNS namespaces for use on the Internet and internally within the organisation, and internal Windows DNS clients  Wishes to understand, based upon this current configuration of a DNS infrastructure, the possible tasks to be executed to permit the support of the defined Active Directory scope for the new DNS infrastructure ♦ Factor Considerations: Where the criteria for the application of this factor can be identified within an organisation, then consider the following information for each DNS infrastructure within the organisation that meets this criteria: This DNS infrastructure configuration occurs typically in organisations that have an internal dedicated DNS infrastructure to support Internet-facing web sites for the organisation, and possibly also intranet web sites and other DNS functions. Within this DNS infrastructure configuration, assuming all Internet-facing DNS namespaces are ICANN registered, and in addition to the four possible combinations for the DNS server software listed above, the following possible combinations exist for the internally used DNS namespaces within this infrastructure and require consideration:  All of the DNS namespaces used internally match all of the Internet-registered DNS namespaces  Only some of the DNS namespaces used internally match some of the Internetregistered DNS namespaces  All of the DNS namespaces used internally are registered with ICANN for use on the Internet, whether they match all or none of the Internet-registered DNS namespaces  None of the DNS namespaces used internally are registered with ICANN for use on the Internet The DNS namespace gap analysis will identify the following possible DNS namespace design tasks (as singular tasks or combinations of tasks) required for this DNS

Page 106 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

infrastructure configuration to permit the support of the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current DNS namespace(s) where they meet all of the DNS namespace requirements for the Windows Server 2003 Active Directory infrastructure for an organisation  Design extensions or modifications to the current Internet-registered DNS namespace(s) and / or the internal DNS namespaces (where they do not match the Internet-registered DNS namespaces) to permit the use of these namespaces to support the defined scope of the Active Directory infrastructure  Design a new DNS namespace strategy to support the defined scope of the Active Directory infrastructure and operate in parallel with the current Internet-registered DNS namespace(s) and the internally used DNS namespaces  Design a new DNS namespace strategy to replace or consolidate all or some of the current Internet-registered DNS namespace(s) and the internally used DNS namespaces within the organisation and support the defined scope of the Active Directory infrastructure The DNS server gap analysis will identify the following possible DNS server infrastructure design tasks (as singular tasks or combinations of tasks) required for this DNS infrastructure configuration to permit the support of the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current DNS server infrastructure(s) to support the defined scope of the Active Directory infrastructure  Design extensions or modifications to the current DNS server infrastructure(s) to permit it to concurrently support the defined scope of the Active Directory infrastructure  Design one or more new Windows Server 2003 DNS server infrastructures to support the defined scope of the Active Directory infrastructure and operate in parallel with the current legacy or third party DNS server infrastructure(s)  Design one or more new Windows Server 2003 DNS server infrastructures to support all or some of the DNS service functions within an organisation and replace (via a migration and subsequent consolidation) all or some of the current DNS infrastructures within an organisation The Windows DNS client gap analysis will identify the following possible Window DNS client design tasks (as singular or combinations of tasks) required for this DNS infrastructure configuration to permit interaction with the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current Windows DNS clients to interact with the defined scope of the Active Directory infrastructure  Design upgrades to the operating system for the Windows DNS clients (“Track 4” of this process) to permit support of all identified operating system dependent design requirements for the Windows DNS client infrastructure  Design modifications to the configuration of the Windows DNS clients (“Track 5” of this process) to permit compliance with all configuration dependent design requirements for the Windows DNS client infrastructure Where an organisation wishes to maintain a separation between external (Internet) and internal DNS namespaces, the internal namespaces are more likely candidates (where

Page 107 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

required and possible) for extension and / or modification to support the defined scope of the Active Directory infrastructure. Where the current DNS infrastructure(s) have hybrid functions (for example a single DNS infrastructure to support both Internet-facing and internal DNS namespaces) then consider the potential requirements to separate these functions into discrete actual DNS infrastructures rather than virtual DNS infrastructures. Where two or more actual DNS infrastructures exist, with clearly defined non-hybrid functions and boundaries, then the DNS infrastructure(s) used to support internal DNS namespaces are more likely candidates (where required and possible) for extension and modification of their design, scope and boundaries to support the defined scope of the Active Directory infrastructure. • Factor B10: Current DNS infrastructure comprises of legacy or third party DNS server software, DNS servers, and one or more DNS namespaces for use only on the internal network ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more existing and in-scope DNS infrastructures consisting of legacy or third party DNS server software, DNS servers, one or more DNS namespaces only for use on the internal network, and supported internal Windows DNS clients  Wishes to understand, based upon this current configuration of a DNS infrastructure, the possible tasks to be executed to permit the support of the defined Active Directory scope for the new DNS infrastructure ♦ Factor Considerations: Where the criteria for the application of this factor can be identified within an organisation, then consider the following information for each DNS infrastructure within the organisation that meets this criteria: This DNS infrastructure configuration occurs typically in organisations that have one or more DNS infrastructures to support internal (intranet) web sites and other DNS functions, such as support for DNS-enabled applications and services. Within this DNS infrastructure configuration, in addition to the four possible combinations for the DNS server software listed above, the following possible combinations exist for the DNS namespaces within this infrastructure and require consideration:  None of the DNS namespaces used internally are registered with the Internet Corporation for Assigned Names and Numbers (ICANN) for use on the Internet  Some of the DNS namespaces used internally are registered with ICANN for use on the Internet  All of the DNS namespaces used internally are registered with ICANN for use on the Internet The DNS namespace gap analysis will identify the following possible DNS namespace design tasks (as singular tasks or combinations of tasks) required for this DNS infrastructure configuration to permit the support of the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current DNS namespace(s) where they meet all of the DNS namespace requirements for the Windows Server 2003 Active Directory infrastructure for an organisation

Page 108 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Design extensions or modifications to the current internal DNS namespaces to permit the use of these namespaces to support the defined scope of the Active Directory infrastructure  Design a new DNS namespace strategy to support the defined scope of the Active Directory infrastructure and operate in parallel with the current internal DNS namespace(s)  Design a new DNS namespace strategy to replace or consolidate all or some of the internally used DNS namespaces within the organisation and support the defined scope of the Active Directory infrastructure The DNS server gap analysis will identify the following possible DNS server infrastructure design tasks (as singular tasks or combinations of tasks) required for this DNS infrastructure configuration to permit the support of the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current DNS server infrastructure(s) to support the defined scope of the Active Directory infrastructure  Design extensions or modifications to the current DNS server infrastructure to permit it to concurrently support the defined scope of the Active Directory infrastructure  Design one or more new Windows Server 2003 DNS server infrastructures to support the defined scope of the Active Directory infrastructure and operate in parallel with the current legacy or third party DNS server infrastructure(s)  Design one or more new Windows Server 2003 DNS server infrastructures to support all or some of the DNS service functions within an organisation and replace (via a migration and subsequent consolidation) all or some of the current DNS infrastructures within an organisation The Windows DNS client gap analysis will identify the following possible Window DNS client design tasks (as singular or combinations of tasks) required for this DNS infrastructure configuration to permit interaction with the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current Windows DNS clients to interact with the defined scope of the Active Directory infrastructure  Design upgrades to the operating system for the Windows DNS clients (“Track 4” of this process) to permit support of all identified operating system dependent design requirements for the Windows DNS client infrastructure  Design modifications to the configuration of the Windows DNS clients (“Track 5” of this process) to permit compliance with all configuration dependent design requirements for the Windows DNS client infrastructure • Factor B11: The organisation does not currently have an internal DNS server infrastructure but does have one or more DNS namespaces registered for use on the Internet ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has not identified the presence of any internal DNS server infrastructures but does have one or more DNS namespaces registered for use on the Internet and hosted by, for example, an Internet Service Provider (ISP)

Page 109 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to consider, based upon this current DNS namespace-only infrastructure, the possible tasks to be executed to permit the support of the defined Active Directory scope for the new DNS infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This scenario is highly prevalent in the majority of organisations wishing to design and deploy the defined Active Directory scope for the new DNS infrastructure. These organisations do not currently have any internally operated applications or services that depend upon a DNS infrastructure for operation. The DNS namespace gap analysis will identify the following possible DNS namespace design tasks (singular tasks or combinations of tasks) required for this scenario to permit the support of the defined Active Directory scope for the new DNS infrastructure:  Execute no design tasks and use the current DNS namespace(s) where they meet all of the DNS namespace requirements for the Windows Server 2003 Active Directory infrastructure for an organisation  Design extensions to the current Internet-registered DNS namespace(s) to permit the use of these namespaces within an internal DNS infrastructure to support the defined scope of the Active Directory infrastructure  Design a new DNS namespace strategy to support the defined scope of the Active Directory infrastructure and operate in parallel with the current Internet-registered DNS namespace(s)  Design a new DNS namespace strategy to replace / consolidate all / some of the current Internet-registered DNS namespace(s) within the organisation and support the defined scope of the Active Directory infrastructure This design methodology recommends that the DNS server design task for this scenario is to design a new internal Windows Server 2003 DNS server infrastructure to support the defined scope of the Active Directory infrastructure. It is highly unlikely that an ISP will be willing to host, externally to the organisation, a DNS server infrastructure to support an Active Directory infrastructure for the organisation. • Factor B12: The organisation does not currently have any DNS server infrastructures or any DNS namespaces ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has not identified the presence of any DNS server infrastructures, namespaces, and hence any supported Windows DNS clients  Wishes to consider, based upon this current absence of a DNS infrastructure, the possible tasks to be executed to permit the support of the defined Active Directory scope for the new DNS infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This scenario is prevalent in a large number of organisations where, for example, they have only recently started operating as an organisation, or where they have an exclusive legacy (Windows NT 4.0) infrastructure that relies solely upon WINS for name resolution, and no requirements for an Internet presence.

Page 110 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

This design methodology recommends that the DNS namespace design task for this scenario is to design one or more new DNS namespace strategies to support the defined scope of the Active Directory infrastructure. (Follow “Track 1” for this process). This design methodology recommends that the DNS server design task for this scenario is to design a new internal Windows Server 2003 DNS server infrastructure to support the defined scope of the Active Directory infrastructure. (Follow “Track 1” for this process) This design methodology recommends that the design task for the Windows DNS client infrastructure for this scenario is to follow “Track 4” of this process. 5.9.2.4. Analysis of the Current DNS Namespace Infrastructure Consider the following information when executing an analysis of all existing DNS namespace infrastructures within an organisation: • Factor B13: Understanding the approach to execute a detailed analysis of all existing DNS namespace infrastructures within an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more existing DNS namespaces (internal or Internet-registered), and  Wishes to understand the approach, proposed by this design methodology, to execute a detailed analysis of all existing DNS namespace infrastructures ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: All organisations following “Track 2” or “Track 3” are required to execute an analysis of existing DNS namespace infrastructure(s). Organisations following “Track 1” are not required to execute this step. The function of this step within this process is to determine the details of the current DNS namespace infrastructure(s) within an organisation. This design methodology proposes execution of the following approach to determine the following details of all existing DNS namespace infrastructures:  Determine the number of existing DNS namespaces (Internet-registered and / or private (internal) DNS namespaces) within each identified in-scope DNS infrastructure within an organisation  Determine the number and names of current child domains within each existing DNS namespace  Determine the current function and ownership of the existing DNS namespaces  Determine the requirements to modify (delete and / or redesign) specific existing DNS namespaces As it is simple to determine the first three points above, this design methodology provides the considerations only for determination of the requirements to modify (delete and / or redesign) existing DNS namespaces within each identified existing in-scope DNS infrastructure of an organisation. • Factor A8: Determination of the requirements to modify (delete and / or redesign) any existing DNS namespaces

Page 111 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has one or more existing DNS namespaces (Internet and / or private)  Wishes to determine the requirements to modify one or more of the DNS namespaces currently within use within the organisation, and the impact of the modifications on the design of the DNS namespace strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology recognises the following modification tasks, executable upon existing private (internal), or Internet DNS namespaces:  The deletion of one or more DNS namespaces from within the DNS infrastructure of an organisation, as part of a DNS namespace consolidation or migration exercise  The redesign of one or more DNS namespaces to comply with changes within the organisation When determining the requirements for the modification of one or more existing DNS namespaces, and the impact of the modification on the design for the DNS namespace strategy, this design methodology provides the following example scenarios of such requirements:  An organisation is considering the merger with, or acquisition of one or more other organisations. Where this scenario may be identified within an organisation, consider the following information:  Where the pre-merger / acquisition organisations have DNS infrastructures, the namespaces supported by these legacy DNS infrastructures may not reflect the namespace requirements of the new collective / parent organisation respectively.  The requirement to redesign the current DNS namespaces for the merged / acquired divisions within the parent organisation may only be valid where the divisions wish to retain a semi-discrete identity from the parent organisation, but still reflect their position within the parent organisation.  For example, a (fictitious) parent organisation, “GardensRUs” has acquired a small (fictitious) company, “Specialised Garden Tools”, which makes specialised gardening tools for physically challenged gardeners. The acquired organisation has a DNS namespace of “SpecialisedGardenTools.com”, and following the acquisition, will have the requirement to redesign their DNS namespace to reflect their new position within the parent organisation, but retain their discrete identity that promotes them within their niche market position. Hence, there may be the requirement to redesign their DNS namespace to, for example, “SpecialisedGardensRUsTools.com”.  It may be possible to identify the requirement to delete an existing DNS namespace from within the DNS infrastructure for an organisation. For example, a previously autonomous division acquired by the parent organisation is now subject to dissolution and full integration with one or multiple other divisions within the organisation. This division now has no requirement for representation, via any previous DNS namespaces for this division, within the DNS infrastructure for the organisation.  An organisation is considering the divestiture of one or more of its divisions to create autonomous sub-divisions within the parent organisation. Where this scenario may be identified within an organisation, consider the following information:

Page 112 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A divested division within an organisation may require external representation via a unique DNS namespace that may or may not reflect the parent organisation.  Following, for example, the previous representation of a divested division as a domain within a DNS namespace for the parent organisation, there may be the subsequent requirement to remove representation within that DNS namespace, and design a new DNS namespace to reflect the new function or status of this division.  An evolving organisation, reacting to changes within its marketplace, has identified the requirement for a change in its identity. Where this change requires reflection externally and internally, then there may be the requirement to remove all existing DNS namespaces that reflected the previous identity of an organisation, and design new DNS namespaces that reflect the new identity (or identities) for the organisation. For example, a (fictitious) organisation (“Natural Produce Inc.”) has a DNS namespace of “NaturalProduceInc.com.”. Following a re-branding exercise, the organisation name changes to “Organic Produce Inc.”, and hence will require a redesigned DNS namespace of “OrganicProduceInc.com.”. Where it is possible to identify the requirements to delete or redesign any existing DNS namespaces within an organisation, consider these modifications during the design of the DNS namespace strategy for the Windows Server 2003 Active Directory infrastructure. (See the later considerations for the integration of the Active Directory DNS namespace infrastructure with an existing DNS namespace infrastructure). Using the above information, execute the following:  Determine and document the number of existing DNS namespaces (Internetregistered and / or private (internal) DNS namespaces) within each identified inscope DNS infrastructure within an organisation  Determine and document the number and names of current child domains within each existing DNS namespace  Determine and document the current function and ownership of the existing DNS namespaces  Determine and document any requirements within the organisation, current or proposed, to remove any DNS namespaces from within the scope of the current DNS infrastructure  Determine and document any requirements within the organisation, current or proposed, to redesign any DNS namespaces within the scope of the current DNS infrastructure  Where it is possible to identify any requirements to remove or redesign any current DNS namespaces, then determine and document the following:  The DNS namespaces to be removed or redesigned  Whether the DNS namespaces that require redesign also require representation within the Active Directory infrastructure for the organisation  The timeframe for the removal or redesign of the identified DNS namespaces 5.9.2.5. Analysis of the Current DNS Server Infrastructure Consider the following information when executing an analysis of each existing DNS server infrastructure within an organisation:

Page 113 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor B14: Understanding the approach to execute a detailed analysis of all existing DNS server infrastructures within an organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more existing DNS servers within one or more DNS infrastructures, and  Wishes to understand the approach, proposed by this design methodology, to execute a detailed analysis of all existing DNS server infrastructures ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Note that where an organisation cannot identify the presence of any internal DNS servers, then it is necessary to follow “Track 1” or “Track 2” of the DNS server design process. However, where an organisation can identify the presence of one or more internal DNS servers (“Track 3” of this process), then this design methodology proposes execution of an analysis to determine the following details of the current DNS server infrastructure:  Execute a detailed analysis to determine the following details of the DNS server infrastructure within each existing in-scope DNS infrastructure:  The number of existing DNS servers within each existing in-scope DNS infrastructure, and the owner(s) of each DNS server  The DNS software source(s), version(s), service pack (where applicable), and operating system for each existing DNS server  The current server hardware specifications of each existing DNS server  The role of a DNS server on its server platform  The presence and use of typical DNS server roles (such as internal root, internal forwarder, caching only DNS servers, and so on)  The details of the configuration of each DNS server / standard server role  The number, types, and details of the DNS forward and reverse lookup zones supported by each DNS server  The details of any DNS zone replication topologies within each identified DNS infrastructure  The details of the current name resolution strategy for a DNS infrastructure  The details of the logical and physical distribution of all DNS servers within each identified DNS infrastructure  The details of the interaction of the current DNS infrastructure with DHCP and / or WINS infrastructures (where applicable)  Execute an analysis to determine the details of the following requirements to modify the existing DNS servers:  The requirements to decommission, consolidate, migrate existing DNS servers within a DNS infrastructure, and hence exclude them from the analysis and gap analysis phases of this process

Page 114 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The requirements to upgrade or decommission existing server platforms for the DNS servers To reflect the above approach, the following two sections present the considerations for this process:  Considerations for the determination of the details of the current DNS server infrastructure within each identified in-scope DNS infrastructure  Considerations for the determination of the requirement to modify the existing DNS servers, prior to assignment of support functions for the defined scope of the Windows Server 2003 Active Directory infrastructure 5.9.2.5.1. Determination of the Details of the Current DNS Server Infrastructure

Consider the following information when determining the details of the current DNS server infrastructure (where present) for each identified in-scope DNS infrastructure within an organisation: • Factor A9: Determination of the number of existing DNS servers within each existing inscope DNS infrastructure, and the owner(s) of each DNS server ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing DNS infrastructure, and  Wishes to determine the total number of DNS servers that support the existing DNS infrastructure, and the owner(s) of each DNS server ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Within the majority of DNS infrastructure identified for inclusion within this analysis phase, it is very simple to determine the number of DNS servers aligned with each specific DNS infrastructure, and the owner(s) of each DNS server. However, the determination of the total number of DNS servers that supports a DNS infrastructure may be difficult to establish where DNS servers and infrastructures do not have clear boundaries based upon support functions. Where it is possible to identify this scenario, it is necessary to align the DNS servers to the DNS infrastructure based upon, for example, ownership of primary DNS zones on each DNS server. Using the above information, conduct an analysis to determine the:  Number of DNS servers within each existing DNS infrastructure, and  The owner(s) of each DNS server • Factor A10: Determination of the current role of a DNS server on its server platform ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing DNS infrastructure, and  Wishes to determine the current role of each DNS server on its server platform

Page 115 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Where it is possible to identify all of the criteria for the application of this factor within an organisation, then consider the following information: A server platform can support multiple servers, such as file and print, DNS, DHCP, WINS, domain controllers, and so on. For example, the DNS server service may operate as one of other following functions of a server platform:  The sole function of that server, and hence the server serves no other function, such as file and print server, domain controller, and so on  The primary function of that server, and hence the server serves other functions, such as file and print server, that can be operated as secondary services. Note that this design methodology regards secondary functions are those that use fewer server hardware resources than primary functions on a server. Note that the domain controller function would be a primary function due to the excessive hardware requirements for this service.  A shared function of that server, where the DNS server service operates in conjunction with other services that share a similar hardware utilisation profile, such as WINS, or DHCP services (collectively termed “infrastructure services”).  A secondary function of that server, where the DNS server service operates in conjunction with another primary service that has a higher hardware utilisation profile, such as the domain controller service Using the above information, execute the following:  Determine and document the function of the DNS server service on each identified server platform  Where the DNS server service is not the primary function of an identified server platform, then determine and document the other function(s) of that server • Factor A11: Determination of the DNS software source(s), version(s), service pack (where applicable), and operating system for each existing DNS server ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing DNS infrastructure  Has identified the presence of one or multiple sources and versions of DNS server software currently in use within each identified DNS infrastructure  Wishes to determine the source(s) of DNS server software in use, the current version and service pack of the software, and the operating system each DNS server is operating on ♦ Factor Considerations: Where it is possible to identify all of the criteria for the application of this factor within an organisation, then consider the following information: Within most organisations, it may be possible to identify multiple versions of DNS server software, from different ISVs, and operating on multiple types of operating system. Determination of the details of all current versions of DNS server software is essential to the execution of the DNS server gap analysis, later within this process.

Page 116 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Hence, this design methodology proposes determination of the following information for each identified DNS server:  The ISV source for the DNS server software (for example, BIND DNS or Microsoft DNS server software, and so on)  The current version of DNS server software currently in use (for example, BIND 4.0, Microsoft Windows NT 4.0, Windows 2000, Windows Server 2003 DNS server software, and so on)  The operating system the DNS server software is operating on (for example, Sun Solaris 2.6, 7, 8; IBM AIX 4.3; Microsoft Windows NT 4.0, Windows 2000, Windows Server 2003, and so on) Using the above information, execute the following:  Determine and document the ISV source for all DNS server software currently in use  Determine and document the version of each DNS server software currently in use  Determine and document the details of the operating system and service pack, and so on, each identified DNS server software currently operates upon  Collate all determined information, for each existing DNS server within each identified DNS infrastructure, and tabulate for easy referral • Factor A12: Determination of the current server hardware specifications of each existing DNS server ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing DNS infrastructure  Has identified the presence of one or multiple versions and models of hardware platforms for the DNS servers within an existing DNS infrastructure  Wishes to determine the server hardware specifications for each existing DNS server ♦ Factor Considerations: Where it is possible to identify all of the criteria for the application of this factor within an organisation, then consider the following information: Determination of the hardware specifications for each server supporting the identified DNS server software is essential for execution of the DNS server gap analysis, later within this process. Hence, this design methodology proposes determination of the following information for each identified DNS server:  The OEM model of server hardware platform (for example, HP, Dell, IBM, Sun and so on) for each existing DNS server  The specifications for all standard equipment, parts, and components identifiable within each existing OEM model of server (such as CPU, RAM, RAID cards, hard disk drives and so on)

Page 117 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The specifications for all non-standard equipment, parts, and components identifiable within each existing OEM model of server (such as extra hard disk drives, extra RAM, extra CPUs, and so on) Where possible, this design methodology recommends the execution of an analysis to determine the baseline performance statistics for each identified DNS server. For example, execution of statistic logging of the following hardware and software parameters over one week:  The current memory, CPU, disk, network interface card statistics, and so on  The current DNS service statistics, such as, for example, zone transfers, DNS caching, dynamic updates, name resolution queries, WINS lookup queries, and so on. • Factor A13: Determination of the presence and use of typical DNS server roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation  Has identified the presence of one or more DNS servers within an existing DNS infrastructure, and  Wishes to determine the presence of standard DNS server roles within an existing in-scope DNS infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A DNS infrastructure can support a variety of DNS server roles, such as:  A “standard” DNS server that hosts primary and secondary forward and reverse lookup DNS zones  A “caching-only” DNS server that does not host any DNS zones and relies upon its DNS cache, forwarder / conditional forwarder, and / or root hints for name resolution  An “internal forwarder” DNS server that primarily performs inter-namespace name resolution for name queries to external (e.g. the Internet) namespaces  An “internal root” DNS server that primarily performs intra- and intra-namespace name resolution for name queries to other internal namespaces It is important to determine the presence and use of these typical DNS server roles within an organisation, as this information is essential in the design and implementation of a DNS server infrastructure to support a Windows Server 2003 Active Directory infrastructure. Using the above information, execute the following:  Determine and document the presence of any or all of these typical DNS server roles within each existing in-scope DNS infrastructure  Where it is possible to identify the presence and use of these roles, determine and document the typical server role assigned to each identified DNS server within each existing in-scope DNS infrastructure • Factor A14: Determination of the configuration details for each identified DNS server / typical server role

Page 118 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation  Has identified the presence of one or more DNS servers within an existing in-scope DNS infrastructure  Has identified the presence and use of one or more typical DNS server roles  Wishes to determine the DNS configuration details for each identified DNS server / typical server role ♦ Factor Considerations: Where it is possible to identify all of the criteria for the application of this factor within an organisation, then consider the following information: For each identified existing DNS server / typical server role, execute an analysis to determine the following configuration details of the server (where applicable):  The TCP/IP configuration of each NIC within each DNS server  The configuration of forwarder / conditional forwarder entries on each DNS server  The configuration of root hints on each DNS server  The configuration of advanced parameters, such as DNS Round Robin, and so on  All other configuration parameters for a DNS server It is important to categorise all identified configuration options and parameters based upon DNS RFCs and other standards, and those that are proprietary to the ISV. For example, the integration of DNS with a WINS infrastructure is proprietary to Microsoft Windows DNS server software. Using the above information, execute the following:  Determine and document the DNS-specific configuration details for each identified DNS server role or typical server role  Determine and document all RFC-compliant configurations and all DNS configurations proprietary to the ISV for the DNS server software. • Factor A15: Determination of the number, types, and details of the DNS forward and reverse lookup zones supported by each DNS server ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing in-scope DNS infrastructure, and  Wishes to determine the number, type, and details of the forward and reverse lookup DNS zones held on each DNS server ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: For each identified existing DNS server, conduct an analysis to determine the following examples of DNS zone details:  The number of forward and reverse lookup DNS zones hosted by each DNS server  The type of each DNS zone (primary, secondary, stub)

Page 119 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The storage option for each DNS zone (where multiple options are available)  The use of delegated subdomains within each DNS zone  The number of resource records within each DNS zone  The zone configuration details, such as:  The details of the Start of Authority resource record  The configuration and details of DNS zone replication (source / destination DNS server(s))  The configuration of dynamic updates to the DNS zone (if a primary DNS zone)  The list of name servers for each DNS zone  The configuration of scavenging and ageing of resource records Using the above information, determine and document the above details for all forward and reverse lookup DNS zones on each in-scope DNS server. • Factor A16: Determination of the details of any DNS zone replication topologies within each identified DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing in-scope DNS infrastructure  Has identified one or more DNS zones that are shared amongst two or more DNS servers within an existing in-scope DNS infrastructure  Wishes to determine the details for all DNS zone replication topologies within each in-scope DNS infrastructure ♦ Factor Considerations: Where it is possible to identify all of the criteria for the application of this factor within an organisation, then consider the following information: This design methodology proposes execution of the following approach to determine the details for all DNS zone replication topologies within each in-scope DNS infrastructure:  Select an in-scope DNS server and identify all active forward and reverse lookup DNS zones  For each active DNS zone, determine whether the DNS zone is a primary DNS zone or a secondary zone. Where the zone is a primary DNS zone, determine the permitted replica list for the zone, where applicable. Where the zone is a secondary DNS zone, identify the DNS server hosting the primary DNS zone.  Where the DNS zone is a stub zone, identify the target DNS server for the stub zone.  Where the DNS zone is Active Directory-integrated (for example, Windows 2000 DNS operating on a domain controller), then identify all Windows 2000 DNS servers in the domain.  Determine the types of network links between the DNS servers that replicate a DNS zone between them (for example, a LAN or WAN network infrastructure)

Page 120 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where the network links are WAN links, determine the levels of available bandwidth within the network links during and out of normal business hours  The configuration of notification lists (where applicable) for each DNS zone  Repeat for each in-scope DNS server and each in-scope DNS infrastructure. Using the above information and approach, determine and document the above DNS zone replication details for all active DNS zones. • Factor A17: Determination of the details of the current name resolution strategy for a DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing in-scope DNS infrastructure  Wishes to determine the details of the current name resolution strategy for the existing in-scope DNS infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The name resolution strategy for a DNS infrastructure can serve one or both of the following two primary functions:  Intra-namespace name resolution  Inter-namespace name resolution The requirement for an intra-namespace name resolution strategy is only applicable where an organisation has:  Two or more internal DNS namespaces, and  Is required to support name resolution queries for resource records contained within either namespace The requirement for an inter-namespace name resolution strategy is only applicable where an organisation has:  One or more internal DNS namespaces, and  Is required to support name resolution queries for resource records contained within external (for example, the Internet) namespaces When determining the details of all existing name resolution strategies, consider the following:  It is important to note that where a DNS infrastructure is required to support internamespace name resolution, it may be possible to identify multiple egress points (for example, to the Internet) for name resolution queries.  This design methodology proposes execution of the following approach to determine the details of existing name resolution strategies:  Select an in-scope DNS infrastructure and determine the following requirements:

Page 121 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• The requirements for the DNS infrastructure to support intra-namespace name resolution • The requirements for the DNS infrastructure to support inter-namespace name resolution  Where the DNS infrastructure is required to support intra-namespace name resolution, determine the configured methods to support this requirement, such as whether the name resolution strategy employs internal root DNS servers and root hints, or cross-replicated DNS zones, and so on  Where the DNS infrastructure is required to support inter-namespace name resolution, determine the configured methods to support this requirement, such as whether the name resolution strategy employs internal forwarder DNS servers and forwarder / conditional forwarder configuration entries, or an external forwarder DNS server (for example, hosted by an ISP) and so on  Repeat for each in-scope existing DNS infrastructure Using the above information and approach, execute the following:  For each in-scope DNS infrastructure, determine and document the requirements for the DNS infrastructure to support intra-namespace and / or inter-namespace name resolution  Determine and document the details of the configured methods within each DNS infrastructure to support the identified name resolution requirements. • Factor A18: Determination of the logical and physical distribution of all DNS servers within each identified DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of two or more DNS servers within an existing in-scope DNS infrastructure  Has identified that the logical scope of an existing in-scope DNS infrastructure extends to support two or more physical locations for an organisation  Wishes to determine the details of the logical and physical distribution of all DNS servers within each existing in-scope DNS infrastructure ♦ Factor Considerations: Where it is possible to identify all of the criteria for the application of this factor within an organisation, then consider the following information: The execution of the DNS server gap analysis relies upon details of the logical and physical distribution of the DNS servers within an organisation. Hence, this design methodology proposes execution of the following approach, to determine the details of the logical and physical distribution of DNS servers, within each in-scope DNS infrastructure:  Select an in-scope DNS infrastructure and determine the:  Logical distribution of the DNS severs on the supporting network infrastructure for an organisation  Physical distribution of the DNS servers, within office and geographical locations for an organisation

Page 122 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine the number of DNS servers within each geographical location  Determine the details of the network links between each geographical location (such as link speed, net available bandwidth levels, and so on) that supports DNS servers within the same DNS infrastructure  Repeat for each in-scope existing DNS infrastructure Using the above information, execute the following:  Determine and document the details for the logical and physical distribution of the DNS servers within an organisation  Generate a diagram for each in-scope DNS infrastructure illustrating the logical and physical distribution of the DNS servers within an organisation. • Factor A19: Determination of the details of the interaction of the current DNS infrastructure with DHCP and / or WINS infrastructures (where applicable) ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more DNS servers within an existing in-scope DNS infrastructure  Has identified that the requirement for an existing in-scope DNS infrastructure to support dynamic updates from a DHCP server (that supports option 81), and / or has identified the requirement for the use of a WINS infrastructure for host name resolution by a Microsoft Windows DNS infrastructure  Wishes to determine the details of the interaction of the current DNS infrastructure with DHCP and / or WINS infrastructures for each existing in-scope DNS infrastructure ♦ Factor Considerations: Where it is possible to identify all of the criteria for the application of this factor within an organisation, then consider the following information: The integration of an existing DNS infrastructure with a DHCP and / or WINS infrastructure will influence the design for the modification or upgrade of the existing DNS infrastructure to support the proposed Windows Server 2003 Active Directory infrastructure. Hence, this design methodology proposes execution of the following approach to determine the details of integration with DHCP and / or WINS infrastructures:  Determine the presence and details of all existing DHCP infrastructures within an organisation  Determine whether the identified DHCP infrastructures are integrated with any of the in-scope DNS infrastructures  Where it is possible to identify the integration of DHCP with DNS, then determine the following information:  The number of DHCP servers configured to dynamically update DNS zones on behalf of DHCP clients  The source and version of the DHCP server software on each of these DHCP servers

Page 123 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The configuration details of the DHCP server(s) (to dynamically update only forward lookup DNS zones (“A” resource records) or reverse lookup DNS zones as well (“PTR” resource records) and so on)  Select an in-scope Windows DNS infrastructure and execute the following:  For each forward and reverse lookup zone, determine the presence of any configurations to integrate the Windows-based DNS infrastructure with WINS  Where it is possible to identify the requirement for an existing in-scope Microsoft Windows DNS infrastructure to use an existing WINS infrastructure for host name resolution, determine the following information: • The forward and reverse lookup DNS zones on each DNS server configured to use WINS lookup • The WINS servers configured for each DNS zone • On a reverse lookup DNS zone, the DNS parent domain name to append to the NetBIOS host (computer) name returned by a WINS reverse lookup  Repeat for each in-scope DNS infrastructure Using the above information and approach, execute the following:  Determine and document all existing requirements for the integration of an in-scope DNS infrastructure with one or more existing DHCP infrastructures within an organisation.  Where it is possible to identify existing requirements for the integration of DNS with DHCP, then determine and document the above details  Determine and document all existing requirements for the integration of an in-scope Windows-based DNS infrastructure with one or more existing WINS infrastructures within an organisation  Where it is possible to identify existing requirements for the integration of a Windows-based DNS infrastructure with WINS, then determine and document the above details 5.9.2.5.2. Determination of the Requirements to Modify the Current DNS Servers

Consider the following information when determining the requirements to modify any or all of the current DNS servers within each identified in-scope DNS infrastructure for an organisation: • Factor A20: Determination of the requirements to decommission, consolidate, or migrate existing DNS servers within an existing in-scope DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more existing in-scope DNS server infrastructures, and  Wishes to determine the requirement to modify the existence of these DNS servers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 124 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The existing presence of one or more DNS servers within an organisation does not imply their continued availability to support a proposed Windows Server 2003 Active Directory infrastructure. It is hence necessary to determine all requirements to modify the existence of these DNS servers, via decommissions, consolidations, or migrations. When determining the requirements to modify the existence of one or more existing DNS servers within an in-scope DNS infrastructure, consider the following:  The owners of an existing DNS infrastructure may decide to decommission one or more of their existing DNS servers where, for example, there is a requirement to migrate all of their DNS namespaces, DNS data, and DNS clients, to a new centralised DNS infrastructure for an organisation. For example:  A recently acquired organisation has its own DNS infrastructure, and as part of the integration project, a DNS infrastructure decommissioning exercise will follow a migration to the centralised DNS infrastructure for the parent organisation  The organisation has decided to discontinue the use of an existing DNS server platform and will instead design and deploy a completely new DNS infrastructure on a different organisation-wide standard DNS server platform.  An organisation may have several DNS infrastructures (with, for example, multiple DNS servers in each infrastructure) that have grown “organically” via the presence of several autonomous divisions. This organisation may hence require the execution of a consolidation exercise to reduce the total cost of ownership of the DNS infrastructure, and reduce the complexity associated with the management and operation of multiple DNS servers within each DNS infrastructures. Using the above information, execute the following:  Determine and document all requirements to decommission, consolidate, or migrate an existing DNS servers prior to assignment of support functions for the Windows Server 2003 Active Directory infrastructure  Determine and document the perceived impact of the decommissioning or consolidation of existing DNS servers on all of the current and proposed support functions of that infrastructure  Determine and document the planned or proposed timescales for the execution of any decommissioning, consolidation, or migration exercises  Determine and document the expected final number of DNS servers within each DNS infrastructure that may be assigned support functions for the Windows Server 2003 Active Directory infrastructure • Factor A21: Determination of the requirements to upgrade or decommission existing server platforms for the DNS servers within an existing in-scope DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has one or more existing DNS servers operating on one or multiple OEM server platforms, and  Wishes to determine the requirements to upgrade or decommission existing server hardware platforms ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 125 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Most organisations either schedule hardware refresh cycles for procured server hardware platforms, or lease and recycle server hardware platforms. The planned or proposed execution of a hardware refresh may influence the design for the DNS server infrastructure, with respect to the minimum recommended hardware specifications, and the number of servers, and so on. Hence, this design methodology proposes execution of the following approach to determine the requirements to upgrade or decommission existing server hardware platforms for DNS servers:  Determine, for each existing server platform that supports an existing DNS server, the requirements to upgrade or decommission that server platform prior to assignment of support function for the Windows Server 2003 Active Directory infrastructure to that DNS server.  Where there is a requirement to upgrade an existing DNS server hardware platform, determine the following logistics for this operation:  The DNS server to receive hardware component upgrades  The specific component(s) that are to be upgraded within the server  The timescales for the ordering, delivery, installation, and testing of the upgraded server hardware components  The impact of the server hardware platform upgrade on existing DNS server services, and any other operations and services supported by that server  Where there is a requirement to decommission an existing DNS server hardware platform, determine the following logistics for this operation:  The DNS server to have a decommissioned server hardware platform  Whether there is a requirement to replace this server hardware platform with a new server (migration) or not (consolidation)  If this is a migration process, determine the: • Configuration details of the new server platform • The logistics for the procurement, installation and configuration of the new server platform  If this is a consolidation process, determine the requirement to migrate the current DNS data to another existing DNS server Using the above information and approach, execute the following:  Determine requirements for the upgrade or decommissioning of existing DNS server hardware platforms  Where it is possible to identify the requirements to upgrade or decommission existing DNS server hardware platforms, then determine and document the details of these planned operations. 5.9.2.6. Analysis of the Current Windows DNS Client Infrastructure Consider the following information when determining the details of the current Windows DNS client infrastructure (where present) within each identified in-scope DNS infrastructure within an organisation:

Page 126 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor A22: Determination of the types of Windows DNS clients currently supported by each in-scope DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to identify all versions of the Windows operating system, and hence DNS client software, that one or more existing in-scope DNS infrastructures currently support. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The presence of multiple versions of Windows DNS clients will influence the design of the technical configuration of the DNS clients. The pre-Windows 2000 versions of the Windows DNS client software have limited configuration capabilities, as WINS was the primary name resolution service, and not DNS. However, with the introduction of Windows 2000 and Active Directory, DNS became the primary name resolution service used by the clients. This hence reflects the more advanced configuration capabilities of the Windows 2000 and later DNS client software. It is important to determine all versions of Windows clients each required DNS infrastructure will be required to support, as this will influence the requirements for the generation of multiple DNS client configuration designs, to match the different configuration capabilities of the clients. Hence, this design methodology proposes execution of the following approach to determine the details of the current Windows client infrastructure for each in-scope DNS infrastructure:  Identify all versions of Windows server and client software currently within use in an organisation. Remember a Windows server may also be a client to a DNS infrastructure.  Determine the number of Windows 95, 98, NT 4.0, Windows 2000, Windows XP Professional, and Windows Server 2003 DNS clients that the DNS infrastructure will be required to support.  Determine the distribution of these clients with respect to:  The Active Directory Site infrastructure for each forest within the Active Directory infrastructure of an organisation  The scope of the DNS infrastructure that will support these clients  Determine the physical and logical distribution of these clients within the organisation and business structure of the organisation.  Determine the number and types of in-scope DNS clients currently supported by a legacy / third party DNS infrastructure, and the details of their current DNS client configurations. Using the above information and approach, execute the following:  Determine the number and types of Windows clients currently supported by each inscope DNS infrastructure  Determine and document the above details for all identified clients  Determine the requirements for the upgrade and decommissioning of any existing Windows clients

Page 127 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where it is possible to identify any planned requirements to upgrade or decommission any existing Windows clients, then determine and document the following information:  The Windows clients that require upgrades, and the upgraded version of Windows operating system  The timescales and logistics for execution of the required upgrades and decommissions • Factor A23: Determination of the current configuration details for all Windows DNS clients ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of multiple versions of the Windows operating system, and hence DNS client software, supported by one or more in-scope DNS infrastructures, and  Wishes to determine the current configuration details for all Windows DNS clients ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Within most organisations, it is highly unlikely to find:  A single version of Windows operating system for the DNS clients, and consequently  A documented standard configuration for all Windows DNS clients Hence, collating such information may be a difficult task without the aid of any centralised management solutions that can remotely query all Windows clients to gather such details, such as Systems Management Server (SMS). However, where such a management solution exists, determine the following details of the existing Windows DNS clients:  The details of the TCP/IP configuration with respect to DNS (such as DNS server list, DNS suffix, and so on) (this may be extracted from the global or scope options for a DHCP server infrastructure, where employed)  Determine the details of the configuration of the Windows DNS clients, based on the technical capabilities of the Windows operating system. For example to, configuration of dynamic updates to DNS zones, configuration of suffix devolution, and configuration of connection-specific DNS suffixes, and so on  Document the results of this analysis for all versions of Windows DNS clients supported by each existing in-scope DNS infrastructure. • Factor A24: Determination of the current modes for implementation of the configuration parameters on existing Windows DNS clients ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Currently supports multiple versions of the Windows operating system, and hence DNS client software, and  Wishes to determine the current mode(s) for implementation of the configuration requirements to the existing Windows DNS clients

Page 128 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to identify a variety of methods to implement the required configuration parameters on Windows DNS clients. This design methodology recognises the following methods for configuration of the Windows DNS clients:  Manual configuration of the DNS clients  Use of DHCP scope options to configure the DNS clients  Use of computer startup / user logon scripts to configure the DNS clients  Use of Group Policy Object (GPO) policy settings  Configuration of DNS client settings within a scripted installation of a standard client build  Configuration of DNS client settings within a deployment image of a standard client build This Windows DNS client gap analysis will employ this information to determine the requirements to modify the mode of implementation of the client configuration parameters. Note that the configuration of Windows DNS clients may hence occur once (via incorporation within a standard build) or dynamically. Using the above information, execute an analysis to determine and document all current method(s) for configuration of Windows DNS clients. 5.9.3. Determination of the DNS Namespace Design Requirements All organisations following “Track 1”, “Track 2”, or “Track 3” are required to execute this step within this process. Consider the following information when determining the design requirements for a DNS namespace strategy, to support the defined scope of the Active Directory infrastructure: • Factor B15: Understanding the approach to determine the design requirements for a DNS namespace strategy for each required in-scope DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the design requirements for a DNS namespace strategy for each required in-scope DNS infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The process to generate a design for a DNS namespace strategy involves the following four steps:  Execution of an analysis to determine the details for all existing DNS namespace strategies within an organisation  Execution of an analysis to determine the design requirements for a DNS namespace strategy to support the defined scope of the Active Directory infrastructure

Page 129 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Execution of a gap analysis between the existing DNS namespace strategy and the required namespace strategy, to determine the required design tasks  Execution of the determined design tasks to generate a design for a DNS namespace strategy The function of this component of this process is to determine the design requirements for a DNS namespace strategy. When executing this component of this process, it is important to identify all DNS namespace design requirements exclusively from the perspective to supporting the defined scope of the Windows Server 2003 Active Directory infrastructure. This design methodology proposes execution of the following approach to determine the design requirements for a DNS namespace strategy:  Determine the number of DNS namespaces that will require representation within an Active Directory infrastructure, and identify the ownership of each tree of Active Directory domains within an Active Directory infrastructure  Determine the design requirements for the Active Directory DNS namespaces required to support an Active Directory infrastructure where an organisation has no current DNS namespaces (“Track 1” of this process)  Determine the design requirements for the Active Directory DNS namespaces required to support an Active Directory infrastructure where an organisation has one or more existing (internal or Internet-registered) DNS namespaces (“Track 2” and “Track 3” of this process) To reflect this approach, the following three sections present the considerations for the execution of this step within this process:  Considerations for the determination of the number of Active Directory DNS namespaces required, and the ownership of each required namespace  Considerations for the determination of the design requirements for identified Active Directory DNS namespaces where the organisation has no existing DNS namespaces (“Track 1” of this process)  Considerations for the determination of the design requirements for identified Active Directory DNS namespaces where the organisation has one or more existing DNS namespaces (“Track 2” and “Track 3” of this process) 5.9.3.1. Determination of the Number of DNS Namespaces Required and their Owners Consider the following information when determining the number of Windows Server 2003 Active Directory DNS namespace required, and the ownership of each required DNS namespace: • Factor A25: Determination of the number of DNS namespaces and DNS domain names required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Is planning to design and deploy a Windows Server 2003 Active Directory infrastructure with one or more Active Directory forests / trees, and  Wishes to determine the number of DNS namespaces and domains required to support this Active Directory infrastructure

Page 130 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Determine the total numbers of DNS namespaces that will be required for use within an Active Directory infrastructure for an organisation, via the results of the following processes within this design methodology:  Examine the results of the “Organisation-Wide Active Directory Plan” process to “determine the number of forests required”  Examine the results of the “Forest Plan” (for each forest within the Active Directory infrastructure) process to “determine the number of domains required”  Examine the results of the “Forest Plan” (for each forest within the Active Directory infrastructure) process to “determine the structure and relationships of multiple domains”. Collate and document the information to illustrate the number of DNS namespaces that are required for each forest, and the number of domains that will require a domain name within each identified DNS namespace. • Factor A26: Identification of the ownership of each Active Directory tree a DNS namespace will represent ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Is planning to design and deploy a Windows Server 2003 Active Directory infrastructure with one or more Active Directory forests and multiple unique DNS namespaces, and  Wishes to determine the owner(s) of each required Active Directory tree of domains ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is important to note that prior to the execution of this process, there should be very little information established as to the domain names required within any of the required DNS namespaces. The “Organisation-Wide Active Directory Plan” and “Forest Plan” processes that determine the number of forests required, and the number, structure, and relationships of the domains within each forest only provide the following facts:  The number of discrete DNS namespaces required to support the Active Directory infrastructure  The number of domains that will require naming within each DNS namespace The requirements that defined the number of forests required, and the number, structure, and relationships of the domains within each forest may reflect the ownership of the resulting DNS namespaces. It is important to identify the ownership of each required tree of Active Directory domains (and thus DNS namespaces) within a Windows Server 2003 Active Directory infrastructure. Knowledge of the ownership of each DNS namespace will assist in the execution of the DNS namespace gap analysis to determine the design approach required for each DNS namespace and the scope and function of each DNS namespace within the organisation.

Page 131 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Using the above information, determine and document the ownership details for all domain namespaces that require design within this process. 5.9.3.2. Determination of the DNS Namespace Design Requirements for Track 1 Consider the following information when determining the design requirements for the Windows Server 2003 Active Directory DNS namespaces, where an organisation does not have any existing DNS namespaces (and hence following “Track 1” of this process): • Factor A27: Determination of the requirement to use legacy (Windows NT 4.0) domain names ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more legacy (Windows NT 4.0) domain infrastructures, and  Wishes to determine the requirements for the use of the NetBIOS domain names within FQDNs, in the DNS namespace(s) required to support the Windows Server 2003 Active Directory infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where an organisation has one or more existing Windows NT 4.0 domain infrastructures, there may be the requirement to use the current NetBIOS domain names within FQDNs, in the DNS namespace(s) required to support the Windows Server 2003 Active Directory infrastructure. When determining the presence of such requirements, consider the following:  The Microsoft NetBIOS domain naming guidelines do not comply with the Internet DNS domain naming guidelines. For example, NetBIOS domain names can use white spaces and symbols such as “! @ # $ % ^ & ' ) ( . - _ { } ~)” disallowed within the Internet DNS domain naming guidelines.  If the current domain names do not comply with Internet DNS domain naming guidelines, as the names contain, for example, spaces or disallowed symbols, then there will be the requirement for a design task to redesign the appropriate domain names.  Note that it is possible to assign a NetBIOS domain name to an Active Directory domain that does not match the first 15 characters of the DNS domain name. For example, an Active Directory domain assigned a fully qualified DNS domain name of “Natsum.com.”, may also have a NetBIOS domain name of “Data”. The architecture of a Windows Server 2003 Active Directory infrastructure permits the consolidation of a multiple Windows NT 4.0 domain infrastructure to one, or just a few Active Directory domains. However, there are very few requirements to justify the retention of a current Windows NT 4.0 domain model. Hence, where the migration process to a Windows Server 2003 Active Directory infrastructure will involve consolidation of a multiple Windows NT 4.0 domain infrastructure to one or a few Windows Server 2003 Active Directory domains, execute the following:  Determine those NT 4.0 domains that will require consolidation or removal. These Windows NT 4.0 domains hence require exclusion from the scope of consideration for the use of their domain names within the new Active Directory infrastructure. This is necessary to prevent confusion in users of the Active Directory infrastructure.

Page 132 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Where there is a requirement to remove Windows NT 4.0 domains, it is because they are either not required within the Active Directory infrastructure, or can be consolidated to, for example, one or more Organizational Units within a domain.  Following the removal or consolidation of Windows NT 4.0 domains, do not rerepresent their domain names within the Active Directory infrastructure as Active Directory domain names. This design methodology recommends consideration of the requirements to use the Microsoft NetBIOS domain names within the FQDNs for Active Directory domains where it is possible to identify compliance with one or more of the following example criteria within an organisation:  There is the requirement to retain the legacy NetBIOS domain names, as this will be beneficial to the users within the domains, as they will be familiar with the domain names and the current functions of the domains within the organisation.  There is the requirement to retain one or more legacy NetBIOS domain names, as the domains currently, and will, support in-house developed applications hard coded to use the current NetBIOS domain names. The organisation has determined, after the execution of a feasibility study for the modification of these applications, that it is unfeasible to modify the applications. This design methodology recommends organisations do not consider requirements to use the Microsoft NetBIOS domain names within the FQDNs for Active Directory domains where it is possible to identify compliance with one or more of the following example criteria within an organisation:  There is a requirement to change the function of one or more Windows NT 4.0 domains during the migration process to a Windows Server 2003 Active Directory infrastructure. Retaining the legacy NetBIOS domain names, after a functional change for the domain, may confuse the users of the domains.  Two or more autonomous divisions within an organisation are to participate within the migration to an Active Directory infrastructure, and one or more NetBIOS names currently in use within the discrete Windows NT 4.0 domain infrastructures match. Where these NetBIOS domain names match, do not recommend their use within the Windows Server 2003 Active Directory infrastructure. Using the above information, execute the following:  Determine and document the requirements for the use of existing NetBIOS domain names within FQDNs, in the DNS namespaces required to support the defined scope of the Active Directory infrastructure.  Where identified, then:  Determine and document the NetBIOS domain names that will require porting to a FQDN  Identify those current identified NetBIOS domain names that do not comply with the Internet DNS domain naming guidelines  Determine and document, where currently possible, the target DNS namespace that will host the NetBIOS domain name to be ported • Factor B16: Understanding the requirements and approach to determine the root domain names for each required DNS Namespace ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has:

Page 133 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Identified the requirement for the use of one or more Windows NT 4.0 domain names within a FQDN for a required DNS namespace, and  Has no existing DNS namespaces (following “Track 1” of this process) and hence  Wishes to understand the requirements and approach to determine the domain names for the root domain within each identified DNS namespace(s) to host a Windows NT 4.0 domain name ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where an organisation has no existing DNS namespaces (internal or external), they hence have not defined the root domain names for any DNS namespaces. The identification of the requirement to use one or more of the legacy Windows NT 4.0 domain names within a FQDN for a DNS namespace still requires the definition of a root domain name for that DNS namespace. For example, an organisation has two Windows NT 4.0 domains named “Resources” and “Accounts” (single master domain model). They wish to use these two domains within a tree of domains identified for creation within a Windows Server 2003 Active Directory forest. However, recommendations exist not to use a single label domain name for the root domain of a tree / DNS namespace, such as “Accounts”, and instead to use a two-label domain name, such as “Natsum.com.” or “Natsum.local.”. (See considerations for the determination of the design requirements for a DNS namespace design model for more details on the use of single label names for root domains). The name of the root domain for each Active Directory tree (DNS namespace) defines and distinguishes it from all other trees within the forest, and within the Active Directory infrastructure for an organisation. Due to the critical importance of the name of the root domain for each Active Directory tree, it is hence imperative that the name reflect a specific requirement for the Active Directory tree. The DNS namespace gap analysis (see later) hence introduces the concept of the requirement to create a design for a “DNS namespace design model”. The “DNS namespace design model” will reflect the business and technical requirements for the naming of DNS namespaces (root domains of each tree) and all sub-domains within each tree. Hence, where an organisation has identified the requirement for the design of a multiple tree (DNS namespace) domain infrastructure, and does not know the required domain names for the root domains of each required DNS namespace, then this design methodology recommends the design and use of a DNS namespace design model. The DNS namespace design model will assist an organisation in determining the names for the root domain for each required DNS namespace, and the names for the child domains within each required tree of domains. 5.9.3.3. Determination of the DNS Namespace Design Requirements for Tracks 2 and 3 In addition to the considerations for “Track 1” (use of the legacy (Windows NT 4.0) domain names), consider the following information when determining the design requirements for organisations following “Track 2” and “Track 3” of this process: The analysis conducted so far has revealed the following details about the current DNS namespace infrastructure and Active Directory DNS namespace requirements: • Details of the current DNS infrastructure (number of DNS namespaces within an organisation (Internet-registered and / or private (internal) DNS namespaces); their function and ownership, the number and names of current child domains within each

Page 134 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

existing DNS namespace, the requirements to modify (delete and / or redesign) existing DNS namespaces, and so on) • Details of the Active Directory namespace requirements (number of forests required, number of trees (and hence DNS namespaces) required within each tree, and number of domains within each tree). Building upon this information, the following considerations discuss the determination of the integration requirements for the identified Active Directory DNS namespace(s) with the existing internal (private) and external (Internet) DNS namespace(s). • Factor A28: Determination of the requirements for the integration of the Active Directory DNS namespaces with one or more external (Internet) DNS namespaces ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has one or more Internet-registered DNS namespaces, and  Wishes to determine the requirements for the integration of the Active Directory DNS namespaces with these DNS namespace(s) ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When considering the integration of one or more Active Directory DNS namespaces with one or more external (Internet-registered) DNS namespaces, this design methodology recognises and supports four possible options for the integration. The first two options align the Active Directory DNS namespaces with the Internet-registered DNS namespaces, and the last two options use discrete namespaces. This design methodology recognises and supports the following four options:  Option One: Use the same DNS name for the root domain of an Active Directory tree as for the root domain of an Internet-registered DNS domain name for an organisation. For example, an organisation with an Internet-registered domain name of “Natsum.com” may use the same domain name for the root domain of a tree of domains within an Active Directory forest.  Option Two: Delegate a child domain of an Internet-registered DNS namespace for use as the root domain of an Active Directory tree of domains. For example, delegate a child domain of an Internet-registered DNS namespace, such as “AD.Natsum.com”, or “Internal.Natsum.com.” to the root domain of an Active Directory tree of domains.  Option Three: Use the same second-level domain name label for an Internetregistered DNS namespace for the root domain of an Active Directory tree of domains, but change the suffix, for internal use only. For example, use the Internetregistered DNS namespace of “Natsum.com” as, for example, “Natsum.local” or “Natsum.AD”, for the root domain of a tree of domains.  Option Four: Do not use any of the Internet-registered DNS namespaces for the Active Directory DNS namespaces, and instead design new and discrete namespaces for the Active Directory trees. When determining the required option(s) for the integration of the Active Directory DNS namespaces with one or more Internet-registered DNS namespaces, consider the following:

Page 135 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The use of the same DNS namespace both externally and internally (options one and two above) is associated with the following distinct advantages and disadvantages that require consideration:  The advantages associated with the use of the same Internet-registered DNS namespace for an internal Active Directory infrastructure are: • A tree name within a forest will match an externally registered domain name. Thus, where users are familiar with the function or role a DNS namespace has within an organisation, it may be possible to translate this to the internal Active Directory domain represented by this DNS namespace. • The user logon name (UPN) may match the e-mail address and Internetregistered domain namespace for the organisation. Thus, it is intuitive for people external to an organisation to deduce the appropriate suffix for an email address for a user within the organisation, with the knowledge of the email alias.  The disadvantages associated with the use of the same Internet-registered DNS namespace for an internal Active Directory infrastructure are: • Complex configuration may be required for internal proxy clients to permit their interpretation of when to send requests outside the internal network for the organisation. Some versions of proxy clients and servers are unable to make the distinction, and thus may generate network issues. • The barrier between internal and external resources becomes less distinct and hence reduces security for internal resources. To maintain a secure internal environment, it will be necessary to separate the DNS servers hosting the DNS zones for the Internet-registered DNS namespaces and the DNS zones supporting the Active Directory infrastructure. This may hence also increase the associated financial and administrative overheads associated with the maintenance of the supporting DNS infrastructure. • Without clear distinctions between the DNS servers hosting external-facing and internal-facing DNS zones and their resource records, name resolution issues will arise for internal users attempting to access Internet-facing resources within the Internet-registered DNS namespace(s).  The use of a different external and internal DNS namespaces (options three and four above) is associated with the following distinct advantages and disadvantages that require consideration:  The advantages associated with the use of a different internal DNS namespace for an Active Directory infrastructure to an existing Internet-registered DNS namespace are: • It is possible to establish a clear distinction between servers that host internal resources and those that host Internet-facing resources using their fully qualified domain names, thus creating an effective security barrier. • It is operationally simpler to manage disjointed namespaces as they discrete management, without any overlap. • Configuration of proxy clients (where required) is simpler because an exception list can be used to filter all internal DNS domain namespaces. • Security configuration of client browsers is simpler to establish allowing the distinction of safe zones for all internal DNS namespace.

Page 136 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The disadvantages associated with the use of a different internal DNS namespace for an Active Directory infrastructure to an existing Internetregistered DNS namespace are: • A general recommendation stands that organisations register all DNS domain names, whether for internal or external use, with ICANN to guarantee unique domain names. This may hence increase the administrative and financial overheads associated with multiple domain namespaces within an organisation. There may also be issues where other organisations or individuals have already registered the required domain names, and are unwilling to concede / transfer / sell the names. • The logon names for user may be different to their e-mail addresses. SMTP E-mail address suffixes are usually set to match an Internet registered domain name for an organisation to allow the intuitive deduction of the e-mail address for a user within an organisation. Where there is a distinct internal domain namespace to an external namespace, the UPNs for the users will be different, unless the organisation configures an additional UPN at the forest level to match the external DNS domain namespace. • The design of a DNS infrastructure to accommodate separate external and internal DNS domain namespaces would have to cater for, for example, separate DNS servers to host the external namespaces within a perimeter / partitioned network. • There will be the requirement to design one or more new DNS namespaces to support the Active Directory DNS namespace requirements. See the considerations for the determination of the design requirements for a DNS namespace design model.  Using the above information, execute the following:  Determine the requirement to use the same namespace for an Active Directory tree as an existing Internet-registered DNS namespaces (options one or two), or the requirement to use different namespaces for the root domain names for one or more Active Directory DNS namespaces (options three or four).  Where it is possible to identify the requirement to use options one or two, determine and document the following: • The Internet DNS namespace(s) to be used • For option two, determine the hierarchical position within the Internetregistered DNS namespace for the subdomain that will require delegation as the root domain for an Active Directory tree. For example, determine whether the delegated child domain is to be a third, fourth, or deeper, level child domain. If it is to be a fourth, or deeper, level child domain (not recommended) then determine the parent namespace for this domain. • The configuration requirements necessary to enable the required integration between the existing Internet DNS namespaces and the Active Directory DNS namespaces, using options one or two  Where the requirement is identified to use options three or four, determine and document the following: • For option three, the suffix to be attached to the domain name label for the Internet-registered domain name, and thus used as the root domain name for an Active Directory tree

Page 137 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• For option four, the number of Active Directory DNS namespaces that will be required to be designed and used in parallel with any existing Internetregistered DNS namespaces. • The configuration requirements necessary to enable the required integration between the existing Internet DNS namespaces and the Active Directory DNS namespaces, using options three or four • Factor A29: Determination of the requirements for the integration of the Active Directory DNS namespaces with one or more internal DNS namespaces ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has one or more internal DNS namespaces, and  Wishes to determine the requirements for the integration of the Active Directory DNS namespaces with these DNS namespace(s) ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Internal DNS namespaces, not currently supporting a legacy (Windows 2000) Active Directory infrastructure, are typically created to support intranet web sites, or for dedicated use by DNS-enabled applications, and so on. When determining the requirements for the use of one or more internal DNS namespaces currently in use within an organisation, to support a Windows Server 2003 Active Directory infrastructure, consider the following:  There are five options for the integration of an Active Directory DNS namespace with an existing internal DNS namespace. These are:  Option One: Use one or more existing internal DNS namespaces in their entirety to support the defined scope of the Active Directory infrastructure where, for example, the existing DNS namespace(s) currently support a legacy (Windows 2000) Active Directory infrastructure.  Option Two: Use the root domain name for the internal DNS namespace as the root domain name for the root domain of an Active Directory DNS namespace. For example, it is possible to use an internal DNS namespace of “Development.com” as the name for the root domain for an Active Directory tree. Note that this may lead to name resolution issues for the current clients of the internal namespace. Issues such as the logical separation of the DNS zones currently hosting the internal DNS namespace(s) and the DNS zones to host the Active Directory DNS namespaces will require consideration to ensure continued operation of both namespaces.  Option Three: Use the same internal DNS namespace, but assign a delegated subdomain of this internal namespace to be the root domain for an Active Directory DNS namespace. For example, it is possible to delegate the child domain of an internal DNS namespace, “AD.Development.com” to become the root domain name for an Active Directory tree.  Option Four: Use the same label for the root domain name within the internal DNS namespace for the Active Directory DNS namespace, but assign a different suffix. For example, it is possible to use the label for the root domain name of the internal DNS namespace “Natsum.com”, for the Active Directory root domain name as “Natsum.AD” or “Natsum.local”.

Page 138 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Option Five: Do not use any of the internal DNS namespaces for the Active Directory DNS namespaces, and instead design new and discrete namespaces for the Active Directory trees.  The advantages and disadvantages to these options are as for the previous factor within this process, for the respective options. Using the information above, execute the following:  Determine and document the requirement to use the same namespace for an Active Directory tree as an existing internal DNS namespaces (options one, two, or three), or the requirement to use different namespaces for the root domain names for one or more Active Directory DNS namespaces (options four or five).  Where the requirement is identified to use options one, two, or three, determine and document the following:  The internal DNS namespace(s) to be used for options one or two  For option three, determine the hierarchical position within the internal DNS namespace for the subdomain that will require delegation as the root domain for an Active Directory tree. For example, determine whether the delegated child domain is to be a third, fourth, or deeper, level child domain. If it is to be a fourth, or deeper, level child domain (not recommended) then determine the parent namespace for this domain.  The configuration requirements necessary to enable the required integration between the existing internal DNS namespaces and the Active Directory DNS namespaces, using options one, two, or three  Where the requirement is identified to use options four or five, determine and document the following:  For option four, the suffix to be attached to the domain name label for the internal domain name, and thus used as the root domain name for an Active Directory tree  For option five, the number of Active Directory DNS namespaces that will be required to be designed and used in parallel with any existing internal DNS namespaces.  The configuration requirements necessary to enable the required integration between the existing internal DNS namespaces and the Active Directory DNS namespaces, using options four or five 5.9.4. DNS Namespace Gap Analysis Consider the following information when executing the DNS namespace gap analysis, to determine the design tasks necessary to generate a design for a DNS namespace strategy: • Factor B17: Understanding the approach to execute the DNS namespace gap analysis ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to execute the DNS namespace gap analysis. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 139 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Although all organisation following tracks 1, 2, and 3 of this process are required to conduct the DNS namespace gap analysis, the scope of the gap analysis will differ between the tracks. Execute the DNS namespace gap analysis following completion of the analysis of the current DNS namespace infrastructure, and determination of the DNS namespace requirements to support the defined scope of the Active Directory infrastructure. When attempting to understand the objectives of the DNS namespace gap analysis, consider the following:  The gap analysis, for organisations following “Track 1” of this process, will determine the design tasks necessary to create a DNS namespace strategy to support the required Active Directory infrastructure where:  An organisation has a legacy Windows NT 4.0 domain infrastructure, but does not wish to retain the use of the NetBIOS domain names, or where  An organisation does not have a legacy Windows NT 4.0 domain infrastructure  Where an organisation (following “Track 1”, “Track 2”, or “Track 3”) has:  A legacy Windows NT 4.0 domain infrastructure, and  Has identified the requirements to use the NetBIOS domain names, it is necessary to conduct a gap analysis to determine the differences between the requirements to use legacy (Windows NT 4.0) NetBIOS domain names, and the Active Directory DNS namespace requirements.  Where an organisation is following “Track 2” or “Track 3” of this process, the gap analysis will determine the differences between the current DNS namespace infrastructure and the requirements for the DNS namespace infrastructure to support the defined scope of the Active Directory infrastructure. This design methodology proposes the following approach to execute the DNS namespace gap analysis:  Execute the DNS namespace gap analysis, and from the results of these gap analyses, determine the specific design tasks that require execution, to design / redesign components of the current DNS namespace infrastructure.  Where the current DNS namespace infrastructure meets all of the DNS namespace requirements for the support of a Windows Server 2003 Active Directory infrastructure for an organisation, then there will be no design requirements for the DNS namespace strategy of this DNS infrastructure.  However, where there is a positive identification of the requirement to execute design / redesign tasks on one or more current DNS namespaces, then determine the requirements for the design and use of a DNS namespace design model for DNS namespace components such as domain names.  Where an organisation identifies the requirements for the design of a DNS namespace design model, it is then necessary to determine the design requirements for the DNS namespace design model. Hence, to reflect the above approach and objectives for the DNS namespace gap analysis, the following two sections present the considerations for the execution of this step within this process:  Considerations for the execution of a DNS namespace gap analysis and determination of the required DNS namespace design tasks

Page 140 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Considerations for the determination of the requirements for a DNS namespace design model 5.9.4.1. Execution of a DNS Namespace Gap Analysis Consider the following information when executing a DNS namespace gap analysis: • Factor A30: Execution of DNS namespace gap analysis for “Track 1” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Does not have a legacy Windows NT 4.0 domain infrastructure, or has not identified the requirement to use any legacy Windows NT 4.0 NetBIOS domain names within any of the required Active Directory DNS namespaces, and  Wishes to determine the required tasks to design a DNS namespace strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where an organisation identifies compliance with the criteria for the application of this factor, it is necessary to design all Active Directory DNS namespace requirements. This design methodology strongly encourages these organisations to proceed with the design of a DNS namespace design model, as it is important to ensure that the decided DNS namespaces and child domain names meet all business and technical requirements for their use. • Factor A31: Execution of DNS namespace gap analysis against requirements to use Windows NT 4.0 NetBIOS domain names ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation following tracks 1, 2, or 3:  Has an existing Windows NT 4.0 domain infrastructure, and has identified the requirements for the use of one or more of the Windows NT 4.0 NetBIOS domain names within one or more of the required Active Directory DNS namespaces, and  Wishes to identify any required design / redesign tasks associated with this required integration, to generate the required design for a DNS namespace strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the differences between the requirements for the use of the legacy Windows NT 4.0 domain names, and the Active Directory DNS namespace requirements, consider the following:  To determine the scope of design tasks necessary to compliment the integration of NetBIOS domain names into the required Active Directory DNS namespaces, it is necessary to:  List and identify all of the Active Directory DNS namespaces required, and the number of child domain names required within each tree.  Identify the mapping of required child domains with the required Windows NT 4.0 NetBIOS domain names, and hence determine which domain names still require design.

Page 141 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 It is important, prior to use of the identified Windows NT 4.0 NetBIOS domain names, to ensure that their compliance with the domain naming requirements for the organisation.  For example, an acquired autonomous sub-division of an organisation may have its own legacy Windows NT 4.0 domain infrastructure. Two of the Windows NT 4.0 domains for this division will require migration into an Active Directory tree within the parent organisation. However, the NetBIOS domain names for these two domains are not suitable for use within the Active Directory infrastructure because, for example:  The NetBIOS domain names do not comply with the Internet domain naming guidelines (for example, the names use white spaces or other disallowed symbols such as “! @ # $ % ^ & ' ) ( . - _ { } ~”).  They are duplicates of other domain names within the Active Directory infrastructure for the organisation  They do not reflect the domain naming requirements for the organisation to, for example: • To reflect the identity of the domain owner (the NetBIOS domain names could simply be “accounts” or “data”, which does not permit deduction of the owner of the domain) • To reflect the function of the domain within the Active Directory infrastructure (the NetBIOS domain names could simply be “NY1” or “NY2”, to denote their geographical locations and scope within the organisation) • To reflect the geographical location and scope of the domains within the Active Directory infrastructure (the NetBIOS domain names could simply be “HR1” or “Sales”).  The domain names exceed or do not meet the minimum length requirements for domain names, to ensure compliance with naming rules or technical limitations on FQDN lengths, respectively.  As stated earlier, where an organisation does not have any existing DNS namespaces (and hence following “Track 1” of this process), there is still the requirement to define the domain names for the root domains of each required Active Directory tree (and thus define the DNS namespace). This is a mandatory additional design task for this track. Single label Windows NT 4.0 NetBIOS domain names cannot cater for this requirement. To ensure that all Windows NT 4.0 NetBIOS domain names are consistent with domain naming rules and guidelines for the organisation, it is necessary to define the rules and guidelines, as components of the DNS namespace design model (see later). Using the above information, execute the gap analysis to determine the following:  Determine and document a list of the required Active Directory domain names, and those domain names potentially supported via use of the legacy Windows NT 4.0 NetBIOS domain names.  For example, an organisation has determined the requirement for two Active Directory trees of domains, with four domains within each tree. The organisation has ten legacy Windows NT 4.0 domains, but the NetBIOS domain names for only three of these domains will be required within the Active Directory infrastructure. Following the execution of the gap analysis, they have produced the following table (table 6.2), indicating the NetBIOS domain name assignments, and outstanding DNS domain name requirements for the required Active Directory domains:

Page 142 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Active Directory Tree Tree 1 (DNS namespace to be determined) Tree 2 (DNS namespace to be determined

FQDNs for Child Domains, indicating which domains are to be assigned a legacy NetBIOS domain name, and which domains still require a DNS domain name Child1.Tree1 (DNS domain name to be determined) Child1.Tree2 (Will use a NetBIOS domain name) Child2.Tree1 (DNS domain name to be determined) Child2.Child1.Tree2 (DNS domain name to be determined) Child3.Child1.Tree1 (Will use a NetBIOS domain name) Child3.Child1.Tree2 (DNS domain name to be determined) Child4.Child2.Tree1 (DNS domain name to be determined) Child4.Tree2 (Will use a NetBIOS domain name)

Table 6.2: Example of NetBIOS Domain Name Assignments to Active Directory Domains  Determine and document the required NetBIOS domain names that will require redesign or modification, to ensure compliance with domain naming guideline and rules (defined within the DNS namespace design model). • Factor A32: Execution of the DNS namespace gap analysis for “Track 2” and “Track 3” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Is following tracks 2 or 3, and has identified the requirements for one or a combination of the following options for the integration of the required Active Directory DNS namespace(s) with one or more existing DNS namespaces:  Option One: The option to use one or more existing internal DNS namespaces in their entirety (where they support, for example, a legacy (Windows 2000) Active Directory infrastructure) to support the defined scope of the Active Directory infrastructure  Option Two: The option to use the same root domain names for internal or Internet DNS namespaces as for the root domains for the required Active Directory DNS namespaces  Option Three: The option to use a delegate subdomain of an internal or Internet DNS namespace as the root domain for an Active Directory DNS namespace  Option Four: The option to use the same label for a root domain name of an internal or Internet DNS namespace as for the root domain of an Active Directory DNS namespace, but with a different domain name suffix, such as “.AD” or “.local”  Option Five: The option to use discrete DNS namespaces to support the Active Directory infrastructure, with no overlap of any existing internal or Internetregistered DNS namespaces for an organisation, and  Wishes to identify any required design / redesign tasks associated with these required integration options, to generate the required design for a DNS namespace strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where the requirement to use one or more existing internal DNS namespaces in their entirety (where they support, for example, a legacy (Windows 2000) Active Directory infrastructure), to support the defined scope of the Active Directory infrastructure is identified, then consider the following:  Where the Windows Server 2003 Active Directory infrastructure is to be created via the existing Windows 2000 Active Directory infrastructure, and will exactly match

Page 143 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

(with respect to the number of Active Directory forests, trees and domains within each forest), then there may not be any requirement to design or redesign any DNS namespaces.  Where the Windows Server 2003 Active Directory infrastructure will involve expansion processes that will hence increase the final number of forests, trees or domains, then there will be the requirement to identify these differences, and hence the subsequent DNS namespace design / redesign tasks. For example, there may be the requirement to create new Windows Server 2003 Active Directory domains, or tree of domains, that the current DNS namespace infrastructure does not represent.  Where the Windows Server 2003 Active Directory infrastructure will involve consolidation processes that will hence decrease the final number of forests, trees, or domains, then there will be the requirement to identify these differences, and hence the subsequent DNS namespace design / redesign tasks. For example, there may be the requirement to remove one or more domains within a tree of domains, or entire trees of domains, or even entire forests. Note that where there is a requirement to remove selected domains from within a tree, then this will affect the FQDN domain names for any existing child domains. Consider the following where there is the requirement to use options 2, 3, or 4 from the list of options specified within the criteria for application of this factor:  The identification of the requirement to use just the root domain name, or a delegated child domain, or just the domain name label of the root domain of an existing DNS namespace, will still require, where the Active Directory tree supports multiple domains, the design of the domain names for the child domains.  Where it is possible to identify this requirement, determine the number of domains that will require the design of a DNS domain name. Where there is a requirement to use discrete DNS namespaces for the required Active Directory trees, which do not overlap with any existing DNS namespaces, then all root and child domain names will require design. It is hence necessary to determine the number of root and child domains that will require a design for a DNS domain name. Using the above information, execute the following:  Determine the required option(s) for integration of existing DNS namespaces  Determine the design tasks associated with the selected option(s) 5.9.4.2. Determination of the Design Requirements for a DNS Namespace Design Model Consider the following information when determining the design requirements for a DNS namespace design model: • Factor B18: Understanding the approach to determine the design requirements for a DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the design requirements for a DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 144 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

This design methodology introduces the concept and structure of a DNS namespace design model. See later for the details of the function and components of a DNS namespace design model. Although this design methodology strongly recommends all organisations design and use a DNS namespace design model, where the results of the DNS namespace gap analysis have identified the requirements for namespace design tasks, it is first necessary to determine the requirements for the design of a DNS namespace design model. Hence, this design methodology proposes execution of the following approach for this component of this process:  Determine the requirements for the design and use of a DNS namespace design model  Where an organisation has identified the requirements for the design and use of a DNS namespace design model, then execute the following:  Understand the components of the DNS namespace design model for this design methodology  Determine the business and technical factors for the required DNS namespace design model for this design methodology Hence, to reflect the above approach, presented within the following three sections are the considerations for the determination of the design requirements for a DNS namespace design model:  Determination of the requirements for a DNS namespace design model  Understanding the components of a DNS namespace design model  Determination of the business and technical DNS namespace design model factors 5.9.4.2.1. Determination of the Requirements for a DNS Namespace Design Model

Consider the following when determining the requirements for the design and use of the DNS namespace design model for this design methodology: • Factor B19: Understanding the importance of DNS domain names ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the importance of DNS domain names when determining the requirements for the design and use of the DNS namespace design model for this design methodology. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A significant amount of consideration is required when deciding the names for the root domain of a DNS namespace, and the DNS domain names for child domains within a namespace. The time and consideration assigned to this task must reflect the importance of the required DNS domain names to the function and operation of an Active Directory infrastructure. A DNS namespace design model reflects the consideration an organisation has made into ensuring the assignment of appropriate DNS domain names to all root and child domains within their Active Directory infrastructure.

Page 145 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

As such, a DNS namespace design model is an essential and integral component of a DNS namespace strategy for an Active Directory infrastructure for most organisations. Consider the following information where an organisation wishes to understand the importance of the DNS domain names, for the root domain(s) (which defines the DNS namespace) and all child domains:  A DNS domain name represents a component of the security model for an Active Directory infrastructure. The DNS domain name defines the logical security boundary for resources controlled by the domain controllers for a domain, and thus defines the scope for authentication and authorisation controls for access to resources held within a domain. Knowledge of the name of a domain hence permits appropriate placement of resources within the security infrastructure for an organisation, and access to those resources by users, computers, applications, and other processes within an organisation.  A DNS domain name for the root domain of an Active Directory tree (and hence DNS namespace) may reflect one or a combination of many business and technical factors that will ensure the unique positioning of a DNS namespace within an Active Directory infrastructure for an organisation. • Factor A33: Determination of the requirement for a DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified differences between the current and required DNS namespaces, and  Has identified the associated design tasks to cater for the differences, and now  Wishes to determine the requirements for the design and use of the DNS namespace design model for this design methodology ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objectives for a DNS namespace design model are to ensure the production of consistent names for DNS namespaces, and domains within the namespaces, for a multiple-domain Windows Server 2003 Active Directory infrastructure. The DNS namespace design model will provide the rules for the creation of namespace and domain names, based upon the business and technical requirements for the naming model. The rules for the DNS namespace design model will ensure that, for example:  All domain names are compliant with Internet domain naming guidelines  All domain names are created to meet the same business and technical requirements, such as naming domains to reflect identity, function, geographic location, compliance with security requirements, stability of the domain names within the organisation, and so on As the design of the DNS namespace design model for this design methodology is a significant undertaking, this design methodology recommends organisations define criteria to qualify requirements for the execution of this design task. Although the onus is with the organisation to define their criteria, to qualify requirements for the design of the DNS namespace design model, this design methodology provides the following example criteria:

Page 146 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The organisation has identified the current (or future) requirement to design / redesign the names for more than three DNS namespaces  The organisation has identified the current (or future) requirement to design / redesign the domain names for more than three Active Directory domains  The organisation has identified the requirement to provide controls and a framework around the generation and use of domain names within the Active Directory infrastructure for the organisation to support, for example, autonomous divisions within the organisation. Following definition of the criteria to qualify requirements for the design of the DNS namespace design model, evaluate all identified criteria against potential requirements. Where an organisation can identify compliance with any or all of these criteria, then it is necessary to consider the design and use of a DNS namespace design model. However, where an organisation is unable to identify these criteria, then it will be necessary to design / redesign the required DNS namespace(s) and / or domain name(s) outside of the framework of a design model. The basis for the statement of criteria is that the design of a DNS namespace design model may be a superfluous requirement where an organisation has the requirement to only design the DNS namespace and / or child domain names for only, for example, one or two DNS names for domains. However, in medium to large organisations, where there may be many Active Directory trees, and child domains within each tree, a DNS namespace design model may be essential to ensure compliance with business and technical requirements, especially where the trees and domains are to support autonomous divisions within an organisation that require representation within the same Active Directory infrastructure. Note that the figures within the criteria above are for illustrative purposes only. For example, an organisation may decide that the current Windows Server 2003 Active Directory infrastructure requirement only dictate the requirement for the design of one DNS namespace and two Active Directory domain names. However, where for example, an organisation actively acquires other organisations, then the number of DNS namespaces and domains may increase with time. There may hence be the requirement for a DNS namespace design model to accommodate the future growth of the organisation. Using the above information, execute the following:  Define and document the criteria to qualify the requirements for the design and use of a DNS namespace design model to reflect, for example:  The number of DNS namespaces and domains that require design, or  Identified requirements to accommodate the future growth of an organisation,  Identified overheads in time and cost of development of a DNS namespace design model, and so on  Determine and document all requirements for the design of a DNS namespace design model, based upon the defined criteria, and identify the qualifying criteria / criterion. 5.9.4.2.2. Understanding the Components of a DNS Namespace Design Model

Consider the following when attempting to understand the components of a DNS namespace design model:

Page 147 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor B20: Understanding the components a DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the use of the DNS namespace design model, and  Wishes to understand the components of the DNS namespace design model for this design methodology ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A DNS namespace design model is composed of the following eight components:  Non-conditional naming rules that govern the naming of all root and child domains within an Active Directory infrastructure  Mandatory business and technical factors that influence the naming of all domains within an Active Directory infrastructure  Conditional naming rules that govern the naming of root domains for an Active Directory DNS namespace  Optional business and technical factors that influence the naming of root domains for an Active Directory DNS namespace  Conditional naming rules that govern the naming of child domains within an Active Directory DNS namespace  Optional business and technical factors that influence the naming of child domains within an Active Directory DNS namespace  Non-conditional usage rules that govern the use of the DNS namespace design model within the Active Directory infrastructure for an organisation  Mandatory business factors that influence the use of the DNS namespace design model within the Active Directory infrastructure for an organisation The functions and relationships of the eight components of a DNS namespace design model are summarised in the following diagram:

Page 148 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Non-Conditional Usage Rules Mandatory Business Usage Factors for Design Model

DNS NAMESPACE DESIGN MODEL

Conditional Naming Rules for Root Domains Optional Business &/or Technical Naming Factors for Root Domains

Non-Conditional Naming Rules Mandatory Business &/or Technical Naming Factors

Active Directory Tree of Domains

Conditional Naming Rules for Child Domains
Natsum.com

Optional Business &/or Technical Naming Factors for Child Domains
Domain 2

Domain 1

© 2004 MUSTANSHI

R

BHAR

MAL

Domain 3

Domain 4

Figure 6.10: Functions and Relationships of the Components of the DNS Namespace Design Model The order of application, of the four sets of rules, is as follows:  The first rules that require evaluation and application, when there is the requirement to name one or more Active Directory domains, are the non-conditional usage rules.  Secondly, the non-conditional naming rules require evaluation and application.  Finally, the conditional naming rules (for root or child domains, as appropriate) require evaluation and application. • Factor B21: Understanding non-conditional naming rules ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the use of non-conditional naming rules for a DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Non-conditional naming rules consist of one or more mandatory factors that require compliance when naming all in-scope Active Directory domains within an Active Directory infrastructure. The DNS namespace design model for this design methodology will only contain one set of non-conditional naming rules. The scope of application of the non-conditional naming rules is all Active Directory domains within the scope of the Active Directory infrastructure the design model supports. It is necessary to apply non-conditional naming rules prior to the application of nonconditional naming rules for root or child domains, to ensure compliance with mandatory business or technical factors for the naming of all domains within an Active Directory infrastructure. For example, a mandatory technical factor such as the requirement to ensure all domain names are unique, not just within a forest, but also within the entire Active Directory infrastructure within the scope of this DNS namespace design model.

Page 149 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor B22: Understanding conditional naming rules ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the use of conditional naming rules for a DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Conditional naming rules, as their name suggests, contain conditional statements for the application of the optional factors defined within the naming rules. An example of a simple conditional naming rule is “if the child domain to be named is within the development forest, and is owned by the network services department, then the domain name shall be a combination of <factor> and <factor> as <details of rules>”, to produce, for example, a domain name of “networkdev”. Each conditional naming rule may consist of one or multiple optional factors. Each optional factor may influence, directly or indirectly, and in isolation or in conjunction with other optional factors, the name for a root or child domain. The business and / or technical requirements for the naming of Active Directory domains dictate the optional factor or factors used within the design model (see next section on the business and technical factors for a DNS namespace design model). When determining the conditional naming rules for the DNS namespace design model, consider the following possible combinations for the selection and use of the business and technical factors that contribute the design model naming rules:  It is possible to design a simple conditional naming rule that uses only one optional factor for the naming of all root or child domains within a DNS namespace. For example, the conditional naming rules for child domains may use the single factor “identity of the department / division that owns a child domain”. The conditional naming rule, once applied, will hence use the factor to ensure that all child domain names reflect the names of the department / division that owns the domain.  It is possible to design a hybrid conditional naming rule that uses a combination of factors for the naming of all root or child domains within a DNS namespace. For example, the conditional naming rules for root domains may use the optional factors “function” and “physical location”, and the rules may state (for example) “name all root domains using a combination of the “function” and “physical location” factors, governed by rules and conditional statements. For example, it is possible to derive a root domain name of “DataNY” to comply with these rules, where the function of the domain is to secure data, and the domain is located in New York.  It is possible to design multiple sets of conditional naming rules that have specific application scopes. For example, conditional naming rules for each forest or each tree of domains, domains within a specific hierarchical level in a DNS namespace (such as first, second, and third level domains), and so on The conditional statements within the rules define how the rules apply, where they apply, the mode of application and use of the factors within the rules to meet the business and technical requirements for their use, and so on. • Factor B23: Understanding non-conditional usage rules ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the use of non-conditional usage rules for a DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 150 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Usage rules for a DNS namespace design model are important to prevent pollution of an Active Directory infrastructure with domain names that do meet the pre-requisites for this design model. For example, in an organisation where security is a concern, such as a military or government department, it may be possible for an unauthorised personnel to, for example, disguise an unauthorised Active Directory domain on the network infrastructure by using a coded domain name that complies with the DNS design model requirements. A DNS namespace design model will contain only one set of non-conditional usage rules. The non-conditional usage rules for a DNS namespace design model will define, for example, the following:  The scope for application of the DNS namespace design model  The pre-requisites that must be met prior to the use of the DNS namespace design model Failure to comply with the non-conditional usage rules will prevent the use of the DNS namespace design model. For example, a mandatory business factor within the nonconditional usage rule is “domain to be named must be a permanent domain and not a temporary or interim domain”. 5.9.4.2.3. Business and Technical Factors for a DNS Namespace Design Model

Consider the following when determining the business and technical naming and usage factors required for inclusion within the DNS namespace design model: • Factor B24: Understanding business usage factors and business and technical naming factors ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the use of business usage factors and business and technical naming factors within a DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Business usage factors are components of the “non-conditional usage rules” for the DNS namespace design model for this design methodology. They provide the factors that govern the use of the DNS namespace design model within the organisation. Naming factors provide the foundations for the creation and assignment of DNS domain names. The “non-conditional naming rules”, the “conditional naming rules for root domains”, and the “conditional naming rules for child domains” all employ business and technical naming factors, which are the heart of a DNS namespace design model. Although the onus is with the organisation to define their own business and technical naming factors, and define which naming factors are mandatory and which are optional, this design methodology has provided (below) a number of examples of business and technical naming factors. • Business Naming Factor A34: Determination of the requirements to use domain names to reflect the identity of the domain owner

Page 151 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, in isolation of other naming factors, and within a non-conditional naming rule for application to all domains, then each domain must have a discrete owner  Where this is a requirement to use this factor, in isolation of other naming factors, and within a conditional naming rule for root domains or child domains, then each root or child domain must have a discrete owner ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This naming factor is usually the most common factor applied to the majority of root domain names, to define the DNS namespaces. For example, an organisation, Natsum Inc., that owns an Active Directory forest, can use this factor to create the domain name for the forest root domain as “Natsum.com.”. Consider the predominant application of this factor within conditional naming rules for root domains, where identity is of key importance. In organisations with multiple autonomous divisions, each discretely represented as a child domain within a tree of Active Directory domains, consider the application of this factor within conditional naming rules for child domains. In this scenario, distinction of the identities, and hence ownership, of each child domain may be an important business requirement, and hence consideration. This factor may require use in conjunction with other factors, such as the minimum and maximum lengths for domain names, function, and role of a domain, and so on. For example, an autonomous division or department within an organisation (such as Human Resources) owns two child domains within an Active Directory tree that have two discrete functions (control over access to HR databases, and control over access to HR general resources). Hence, using a combination of these factors (identity, function, and maximum domain name length (stating, for example, a maximum of six characters for a domain name)), it is possible to design the names for these domains as “HRDATA” and “HRRES”. Using the above information, conduct an analysis to determine the following:  The requirement for this use of this factor within a naming rule  Where it is possible to identify the requirement for the use of this factor, then determine and document the following:  The required priority for the use of this factor (to be reflected within the naming rules)  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  Domain name abbreviation requirements where necessary, and associated rules for name abbreviation (see technical naming factors “minimum domain name length” and “maximum domain name length”) • Business Naming Factor A35: Determination of the requirements to use domain names to reflect the function or role of a domain

Page 152 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, in isolation of other naming factors, and within a non-conditional naming rule for application to all domains, then each domain must have a unique (and hence distinguishable) function or role within an Active Directory infrastructure  Where this is a requirement to use this factor, in isolation of other naming factors, and within a conditional naming rule for root domains or child domains, then each root or child domain must have a unique (and hence distinguishable) function or role within an Active Directory infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Note that for the majority of Windows Server 2003 Active Directory domains, it is not possible to identify a distinct function or role for the domain within the Active Directory infrastructure. This is because of the opportunities for domain consolidation presented by Active Directory, and hence a consolidation of functions and roles into one or fewer numbers of domains. In organisations where security has high priority, then revealing the function of a domain via its domain name may expose this domain to attack. The use of this factor is suitable for the naming of child domains created to serve specific functions, rather than root domains for an Active Directory tree of domains. Where it is possible to identify a clear function or role for a domain, such as to control access to sensitive corporate data, or to control access to groups of specific applications or services and so on, then consider the following:  Where there is more than one other instance of a domain within a tree or forest of domains with the same describable function, then it is necessary to either:  Develop a rule to produce a coded domain name based solely on the function of the domain, or  Use the function factor in conjunction with one or more other factors to produce a unique domain name  Where there is a requirement to use the function of a domain within the domain name, then the name must either:  Intuitively reflect the function (for example, where the function of domain is to control access to financial applications, the domain name / component of domain name may be “financeapps”, or where a domain is created to support a joint venture between two organisations, it may be named “JVT”, and so on), or  Be deducible via knowledge of the code used to generate the domain name (for example, a naming rule states the use of the codes “Fin” to denote “Finance”, “Nwk” to denote “Network”, “Fct” to denote “Forecast” applications). The use of coded function denominators assist in securing knowledge of the function of a domain, as long as there is secured access to the code. Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “function” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:

Page 153 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The required priority for the use of this factor (to be reflected within the naming rules)  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  Requirements to design codes for functions of domains where there are restrictions imposed by other naming factors such as security, and maximum domain name length, and so on. • Business Naming Factor A36: Determination of the requirements to use domain names to reflect the geographic location of a domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  The organisation has multiple geographic locations (see below for interpretation of “geographical locations”), and  The boundary for each domain to be named with this factor does not span more than one geographic location, and  Where there is a requirement to use this factor, in isolation of other naming factors, and within a non-conditional naming rule for application to all domains, then each geographic location must not support more than one domain to be named with this factor  Where this is a requirement to use this factor, in isolation of other naming factors, and within a conditional naming rule for root domains or child domains, then each geographic location must not support more than one root or child domain to be named with this factor ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to define “geographical location” by the following common physical boundaries:  Office buildings  Cities or towns  Regional government boundaries defined by counties, boroughs, states, province, territories, regions, districts, and so on.  Individual countries defined by political boundaries, such as United Kingdom, United States of America, France, Spain, Germany, and so on.  Geopolitical boundaries such as Europe, EMEA (Europe, Middle East, Africa), Australasia, Americas, NOPAC (North Pacific, to include Hong Kong SAR (Special Administrative Region of China), China, South Korea, Taiwan), SOPAC (includes locations south of Hong Kong SAR, up to India, but excluding Afghanistan), and so on.  Continents such as Africa, Antarctica, Asia, Australia, America Note that there is no single standard for what defines a continent, and therefore various cultures and sciences have different lists of considered continents. In general, a

Page 154 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

continent must be large in area, consist of non-submerged land, and have geologically significant borders. While some consider there are as few as four or five continents, the most commonly used counts are six or seven. The use of this factor is suitable for the naming of child domains specifically created to support the Active Directory requirements for users, computers, applications, and services within a geographic location for an organisation. This factor is suitable for application within conditional naming rules scoped for specific root or child domains, for example, based upon hierarchical position within a DNS namespace. It is possible to use this factor in isolation, or in combination with other factors. It may not be suitable for use within a non-conditional naming rule for the majority of geographically distributed organisations. Where it is possible to identify in-scope Active Directory domains hosted within discrete geographical locations, then consider the following:  Where there is the requirement for the name of a geographical location to comply with another required naming factor, such as security, consider the use of codes for the geographical locations to shorten and obfuscate the location name.  Where there is the requirement for compliance with other factors such as minimum and maximum domain name lengths, and the requirement to ensure intuitive deduction of the location for the domain, consider the use of location codes to abbreviate the names. For example, where geographical locations imply discrete countries, consider the use of the ISO 3166 two-character codes for the countries and regions of the world. (See Appendix A for the ISO 3166 codes) Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “geographical location” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The required priority for the use of this factor (to be reflected within the naming rules)  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  Requirements to design codes for geographical locations of domains where there are restrictions imposed by other naming factors such as security, and maximum domain name length, and so on • Business Naming Factor A37: Determination of the requirements to use domain names to reflect stability requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, in conjunction with other factors, then no other factors are used that may affect the stability of the domain name.  The domains to be named are all permanent domains, to validate the requirement for stable domain names

Page 155 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to interpret the requirement to ensure all domain names are “stable, and do not require changes” as “instances of domain names that are based upon variables with constant values that will not change for the lifetime of the domain”. It is not possible to overemphasise the importance of stable domain names within an organisation. For example, within most organisations, there are many applications, processes, services, and so on, that rely upon the domain name for continued normal operation. Windows Server 2003 GPOs rely heavily upon domain names for operation. There are hence significant financial and administrative implications associated with change of a domain name. Where an organisation is considering the use of this factor within a naming rule, then it must take high priority. Hence, where it is possible to identify the requirements for the use of this naming factor, this design methodology strongly recommends its use as a mandatory factor within a non-conditional naming rule for the design model. The concurrent use of the following naming factors may influence the stability of a domain name:  Concurrent use of the geographical location factor can influence the stability of a domain name. For example, an organisation might re-locate resources from one geographical location to another, and thus require the renaming of a domain to reflect the new location.  Concurrent use of the function factor can influence the stability of a domain name. For example, an organisation may undergo an internal restructuring or migration exercise that involves the consolidation of certain domains, and hence an associated change in function of the domains. This may hence require reflection within the name of the domain.  Concurrent use of the security factor can influence the stability of a domain name. For example, a breach of the security codes used to name the domains may hence result in the requirement to re-design the security codes, and thus all of the domain names affected by the breach.  Concurrent use of the identify factor (and the factor stipulating the requirement for registration of the domain name with ICANN for use on the Internet) can influence the stability of a domain name. For example, an organisation may be merged with, or acquired by, another organisation, and thus require a change in identity. This change in identity may thus require reflection within any associated domain names, and Internet-registered root domain names. Note that Windows Server 2003 Active Directory supports a new utility that permits the renaming of Active Directory domains to attain any of the following three requirements:  The simple renaming of Active Directory domains within a Windows Server 2003 forest without repositioning the domains within a tree structure or forest  The renaming of Active Directory domains within a Windows Server 2003 forest with repositioning of the domains (except the forest root domain), and hence creation of new domain structures within a tree  The creation of new Active Directory trees via the renaming of a domain to create new DNS namespaces Where an organisation is considering the use of the “domain rename” utility, note the following information:

Page 156 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The domain rename utility is not for casual use, and requires careful consideration, and significant planning and design prior to execution of the complex procedures for this utility.  The objective for the domain rename utility is not to represent a solution to the instability of domain names, generated by incomprehensive domain name planning, but a way forward where no other solution is available.  There are significant constraints, pre-requisites, and pre- and post-execution tasks for the use of this utility that require acknowledgement and understanding prior to use.  The design of the procedures for the design and execution of the domain renaming utility are beyond the scope of this volume of the design methodology. Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “stability” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority for the use of this factor (to be reflected within the naming rules) when used concurrently with other required naming factors within the DNS namespace design model • Business Naming Factor A38: Determination of the requirement to use domain names to reflect security requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, then the DNS namespace design model (holding the code for the abbreviations for the domain names) requires use within the confines a secure access control infrastructure to prevent any security breaches.  Where there is a requirement to use this factor, then it is not possible to use it concurrently with the factor to ensure “simple and intuitive” domain names, as these factors contradict each other. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objective for the use of the security factor in naming Active Directory domains is to obfuscate one or more of the following aspects of a domain:  The function(s) and role(s) of a domain within an Active Directory infrastructure  The owner(s) of the domain  The geographical location of the domain Although this mode of security is weak, and requires consideration in conjunction with other stronger security precautions, it is relevant as the name of a domain is the first reference point for an attack on a domain. The risk of attack decreases where the name

Page 157 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

of the domain, within an Active Directory infrastructure containing multiple domains, does not permit the intuitive deduction of the function, owner, or geographical location of the domain. The use of the security factor to influence the design of domain names has particular relevance where, for example, the function of Active Directory domains is to control access to sensitive data or resources available on a network infrastructure for an organisation. When determining the requirements for the use of this factor within naming rules, consider the following:  It is necessary to produce a code for the production of a secure domain name that does not intuitively infer its function, without knowledge of the code. It is possible to base the code, for example, on a multitude of factors associated with the domain, such as its owner, function, geographical location, and so on.  For example, a domain within a government department provides the access control infrastructure to secure secret documents and other sensitive resources. The owner of the domain is the “Foreign Office” department, and the domain is located in London. A code developed for each department name, location, and domain function, states that “Foreign Office” codes as “U3”, London codes as “88”, and the domain function to secure data and resources codes as “PR99”. This results in a coded domain name of “U388PR99”. This domain name would hence not make any sense without knowledge of the code used to generate the domain name, or the components of the code.  As can be inferred from the above example, it is necessary to determine the design requirements for the following aspects of a code for a secure domain name:  Identify of the required component(s) for the coded domain name. For example, it is possible to use metadata aspects of the domain (such as the domain owner, geographical location, function, and so on), or other generic parameters. Note that the components employed in the coded domain name must, when used in the specified order (see below), and where possible, be able to permit distinction between domains named with these components.  Where more than one component is required (advisable), then it is necessary to determine the sequence for these components within the domain name. This must be consistent to permit users, assigned knowledge of the code, the ability to decipher the domain name quickly and accurately.  For each required component, it is necessary to develop either a simple abbreviated representation of the component (this approach is not secure), or a coded abbreviation of the component (this approach is more secure).  Rules are required for the assembly of the code components where conflicts exist. For example, two domains may share all components in common and hence become indistinguishable from each other.  It is necessary to develop a secure method to assign knowledge of the code to the appropriate users of the domain and its resources.  Consider the interaction of the security factor with other concurrent factors within a naming rule, such as stability and so on, when designing the domain names. Where an organisation identifies the requirement for the use of the security factor, the naming rules that will employ this factor must identify the priority for compliance with the factor. If it is to take high priority, then consider the use of this factor within the nonconditional naming rules, as a mandatory naming factor.

Page 158 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “security” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The required priority for the use of this factor (to be reflected within the naming rules)  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority level for this factor, when used concurrently with other required naming factors within the DNS namespace design model  The code design requirements, identifying the components, sequence, codes, and rules • Business Naming Factor A39: Determination of the requirement to use domain names that require registration with ICANN ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, then the domain names to be generated must be unique against all other domain names registered for use on the Internet  Where there is a requirement to use this factor, the technical naming factor to ensure all root domain names use a specific internal (non-Internet) suffix (such as “.local”), is not concurrently used within the same naming rule as it will contradict this factor  Where there is a requirement to use this factor, then the organisation must be able to accommodate:  The financial and administrative requirements of the registration process  The domain name maintenance requirements with the registration authority (such as domain name renewal, retention, and so on) ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology strongly recommends that all domain names assigned to Active Directory domains are unique (see the technical naming factor to ensure “unique domain names). The scope for this requirement may extend beyond a tree of domains, a forest, or even an entire Active Directory infrastructure for an organisation, to the Internet. The advantages to the registration of a domain name with ICANN are that it guarantees a unique domain name. For example, in organisations where multiple autonomous divisions may create multiple Active Directory domains, it may be difficult to enforce the requirement to ensure all domain names are unique within the scope of an entire Active Directory infrastructure. Hence, where it is possible to identify this scenario within organisation, consider the use of this naming factor to force registration of all domain names with a third party organisation (ICANN) to guarantee uniqueness.

Page 159 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Consider the requirement to guarantee unique domain names beyond the scope of an Active Directory forest, or the Active Directory infrastructure for an organisation where, for example, organisations are merged with, or acquired by, other organisations. During these activities, it is possible for the merged / acquired organisation to have an Active Directory domain with the same domain name. Hence, globally unique domain names can obviate the requirement for the design and implementation of complex domain renaming exercises in such scenarios. Where there is the requirement for the use of this factor, the design methodology recommends a limited scope of application, for example, within a conditional naming rule for root domains. This design methodology does not recommend the use of this factor where it is possible to identify compliance with the following criteria:  The organisation has centralised administration for all domain naming functions, and hence can guarantee all domain names will be unique  The requirements for the scope for uniqueness of domain names states the boundary of an Active Directory forest, and hence the forest owner is responsible for ensuring unique domain names  There will never be a requirement to use the domain names on the Internet Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “registration of domain names with ICANN” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority for the use of this factor (to be reflected within the naming rules) when used concurrently with other required naming factors within the DNS namespace design model • Business Naming Factor A40: Determination of the requirement to use domain names to reflect intuitivism requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, only a limited number of other naming factors will be concurrently used to permit the development of intuitive domain names  Where there is a requirement to use this factor, the security factor is not concurrently used within the same naming rule as it will contradict this factor ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objective of this factor is to ensure that the domain name intuitively permits the deduction of its function, geographical location, owner, and so on. This may be of importance within a multiple domain infrastructure that supports many users requiring frequent access to domain resources.

Page 160 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When determining the requirements for the use of this factor within a naming rule, consider the following:  It is possible to generate intuitive domain names based upon a single factor (such as geographical location) or a combination of factors.  Where combinations of factors are used, the sequence for the assembly of the abbreviations for each factor must be consistent to permit ease of deduction. For example, an organisation names two domains using a combination of the three factors “owner”, “geographical location”, and “function”, in that sequence. Hence, from the domain names “SALESLONDATA” and “HRNYAPPS” it is possible to intuitively deduce the owners, location, and function of each domain, as “Sales, London, Data”, and “Human Resources, New York, Applications”.  Where there is a requirement to generate abbreviations for components of a domain name, to meet intuitivism requirements and compliance with maximum domain name lengths, ensure that the abbreviation for the component is decipherable and unique. Using the above information, conduct an analysis to determine the following:  The requirement for the use of “intuitive domain names” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority for the use of this factor (to be reflected within the naming rules) when used concurrently with other required naming factors within the DNS namespace design model  The required rules for the generation of abbreviations for multi-component domain names to comply with intuitivism requirements • Business Naming Factor A41: Determination of the requirement to enforce domain names for root domains to use a minimum of two labels ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisite for the use of this factor:  Where there is a requirement to use this factor, the “use single label domain names” factor is not concurrently used within the same naming rule as it will contradict this factor ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to generate an internal (not Internet-registered) root domain name with only a single label, such as “Mycompany” and not two labels, such as “Mycompany.com.”. When determining the requirement to include this factor within a naming rule, consider the following:  The requirement to enforce the use of a minimum of two labels within a root domain name for an internal DNS namespace may be identified where, for example:

Page 161 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 An organisation has many autonomous divisions, no centralised administrative model, and the potential for autonomous divisions to create single label domains. There is thus the potential for the creation of conflicting domain names.  An organisation has legacy (Windows 95, 98, NT 4.0) Windows DNS clients that cannot update single label domain DNS zones  An organisation wishes to ensure integration of Active Directory DNS namespaces with existing Internet-registered DNS namespaces  The use of two or more label domain names, in conjunction with the naming factor to ensure the registration of all domain names with ICANN, will permit the generation of unique domain names. Using the above information, conduct an analysis to determine the following:  The requirement for the use of “minimum of two label domain names” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority for the use of this factor (to be reflected within the naming rules) when used concurrently with other required naming factors within the DNS namespace design model  The required rules for the generation of abbreviations for multi-component domain names to comply with intuitivism requirements • Business Naming Factor A42: Determination of the requirement to enforce domain names for root domains to use a single label ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is the requirement to use this factor, and the use of dynamically updatable DNS zones to support single label domain names, then the Active Directory domain must not support any legacy Windows (95, 98, NT 4.0) clients  Where there is the requirement to use this factor, and disable the use of NetBIOS over TCP/IP name resolution, then the Active Directory domain must not support any legacy Windows (95, 98, NT 4.0) clients  Where this is the requirement to use this factor, the “register all domain names with ICANN” factor is not concurrently used within the same naming rule as it will contradict this factor ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: There are many recommendations against the use of single label domain names within a Windows Server 2003 Active Directory infrastructure. However, where it is possible for an organisation to identify one or more requirements for the use of single label domain names, then consider the following:

Page 162 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 In order to permit Windows 2000 and later Windows clients to use their DC Locator functions to locate domain controllers via DNS, it is necessary to configure these clients with the REG_DWORD registry entry “AllowSingleLabelDnsDomain” within the registry sub-key “HKLM\System\CurrentControlSet\Services\Netlogon\Parameters”, and configure the data value as “1”.  In order to permit the dynamic update of single label domain DNS zones by Windows 2000 and later Windows clients, it is necessary to configure these clients with the REG_DWORD registry entry “UpdateTopLevelDomainZones” within the registry sub-key “HKLM\System\CurrentControlSet\Services\DnsCache\Parameters”, and configure the data value as “1”.  See later (determination of the design requirements for DNS clients) for details of these registry changes, and modes of application and so on  This design methodology recommend the use of this factor, where required, as an optional factor within a conditional naming rule. Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “single label domain name” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority for the use of this factor (to be reflected within the naming rules) when used concurrently with other required naming factors within the DNS namespace design model  The required rules for the generation of abbreviations for multi-component domain names to comply with intuitivism requirements • Business Naming Factor A43: Determination of the requirement to use domain names to reflect language requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, then the organisation must be represented within multiple geographical locations where the primary language for the location differs from at least one other location  There is a requirement to restrict the language or number of languages used for the naming of Active Directory domains within the Active Directory infrastructure for an organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: In organisations that span multiple countries and even continents, the languages used within each location represented by the organisation may require consideration. The objective of the “language” factor is to ensure that all domain names are readable by the primary and secondary users of a domain, without the requirement to learn new

Page 163 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

languages or recognise the required domain names, and install language packs on operating systems. This design methodology recommends consideration of the requirement for the use of this factor where it is possible to identify any of the following example scenarios within an organisation:  Users from different countries require access to an Active Directory domain within an organisation. Each country has a different primary language, but all users within each country are fluent in one common language. In this scenario, it is hence necessary to use this factor to ensure the use of the language in common to all users for naming the appropriate domain(s).  An organisation wishes to deploy a standard desktop operating system build to all users that share a common role within an organisation. As the distribution of the users is across many different countries, each with different primary languages, the organisation wishes to minimise the number of standard builds necessary and has advocated the use of a single language pack within the build. The chosen language pack reflects the primary language for the organisation, which all users are required to use regardless of the primary language of their country. Hence, to ensure all desktop computers configured with this build can illustrate the appropriate names for all objects within the Active Directory, including the names of the domains, the organisation wishes to use this factor to ensure the use of the common language in naming domains. This factor will have a limited scope of application within the majority of organisations. However, where there is an identified requirement for the use of this factor, the potential impact of non-compliance within this factor requires consideration. Hence, this design methodology recommends consideration for the use of this naming factor as a mandatory factor within a non-conditional naming rule. When determining the scope for application of this factor, consider the:  Geographical boundaries of the domains to be named  Geographical distribution of the users that will require access to the domain, the appropriate language packs installed on their operating systems, and so on. Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “language” factor within a naming rule  Where the requirement for the use of this factor is identified, determine:  The required language(s) to be defined by each naming rule  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority for the use of this factor (to be reflected within the naming rules) when used concurrently with other required naming factors within the DNS namespace design model • Technical Naming Factor A44: Determination of the requirement to use domain names to reflect uniqueness requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:

Page 164 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where there is a requirement to use this factor, the organisation must have the ability to enforce its application for all domains within its scope  Where there is a requirement to use this factor, the concurrent use of the technical naming factor “compliance with RFC 1123 Internet domain naming characters” is required within the same naming rule to ensure a consistent framework for the unique domain names ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the requirement for the use of this naming factor to ensure unique domain names, it is important to define the scope. For example, an organisation may require that all domain names are unique across all forests within the entire Active Directory infrastructure for an organisation, or just within a single forest. The domain name for a child domain must be different to that of the parent domain and to that of all other sibling domains of the same parent. For example, a parent domain of “A.com” has three child domains. None of the three child domains can have a domain name of “A” as this will conflict with the parent domain name. In addition, neither of the child domains can share, for example, “B” as a domain name, because then there may be more than one “B.A.com” FQDN within the forest. However, a child domain of “B.A.com” can have a child domain (a grandchild of “A” with a domain name of “A”, to give the grandchild domain a FQDN of “A.B.A.com”. Although this approach is technically possible, the design methodology recommends that an organisation does not adopt it. Instead, the design methodology recommends that all domain names be unique, within a minimum scope of an Active Directory forest, and a recommended scope of the entire Active Directory infrastructure for an organisation. Unique domain names will ensure that clients for the domains will be able to connect to the correct domain for normal operations, especially when using the UNC convention and hence just using the NetBIOS name for a domain. When determining the requirements for the use of this factor within a naming rule, consider the following:  The use of the naming factor “registration of domain names with ICANN” may assist in enforcing this factor, by delegation of the onus on ensuring the uniqueness of domain names to an Internet registrar. Note that the concurrent use of this factor naturally assumes other considerations, such as the use of two label domain names, and so on.  There may be the requirement to develop a procedure, reflected by the naming rules, to ensure checks for unique domain names where this is an internal procedural requirement.  The naming rules that will define the use of this factor require the use of loop back processing of this factor, subsequent to the preliminary generation of a domain name. For example, a naming rule with multiple factors, including the requirement for unique domain names, generates a domain name of, for example, “ChildAData”. Following the generation of this name, the rules must state the requirement to reprocess the uniqueness factor (loop back processing) to ensure the resultant name is unique. Where the generated domain name is not unique, then the rules must cater for this and suggest appropriate alternatives. Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “uniqueness” factor for domain names within a naming rule  Where the requirement for the use of this factor is identified, determine:

Page 165 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The scope of application for this factor within an organisation (tree, forest, Active Directory infrastructure, the Internet, and so on)  The naming rule scope for application of this factor (non-conditional naming rule, conditional naming rules for all root or child domains, or conditional naming rules for selected root or child domains) and required mode for use (mandatory or optional)  The required priority for the use of this factor (to be reflected within the naming rules) when used concurrently with other required naming factors within the DNS namespace design model • Technical Naming Factor A45: Determination of the requirement to use domain names to comply with Internet domain naming rules ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has identified the requirement for the design of a DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The Internet domain naming rules define the following:  The characters that may be used within domain names (defined within Request for Comments (RFC) number 1123) as:  Hyphen ( - )  0-9  A-Z and a-z (domain names are case-insensitive)  The maximum length of domain name labels (63 UTF-8 bytes per label)  The maximum length of a fully qualified domain name (FQDN) (255 UTF-8 bytes) This design methodology requires the inclusion of this naming factor as a mandatory factor within the non-conditional naming rule for a DNS namespace design model. The design methodology also recommends that this factor encompass the requirement to enforce the use of Unicode characters for all domain names only where all servers running DNS server software (to support the Windows Server 2003 Active Directory infrastructure) support Unicode (see RFC 2044 for more details). The use of this factor within a naming rule may require loop back processing to ensure compliance with this factor by a generated domain name. • Technical Naming Factor A46: Determination of the requirement to enforce domain names for root domains to use a specific internal (non-Internet) suffix ♦ Criteria for Execution: Explore the considerations for the execution of this factor within the DNS namespace design model where it is possible to attain compliance with the following pre-requisites for the use of this factor:  Where there is a requirement to use this factor, the naming factor to “ensure all domain names are registered with ICANN” is not concurrently used within the same naming rule as it will contradict this factor  Where there is a requirement to use this factor, there is no requirement to use an existing Internet-registered DNS namespace, or a delegated child domain of an

Page 166 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

existing Internet-registered DNS namespace for the Active Directory root domain as these requirements will contradict this factor ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: To separate internal and external DNS namespaces, one possible approach is to assign all internal Active Directory DNS namespaces with a private suffix, such as “.local.”, “.private”, “.ad.”, and so on. The scope for the application of this naming factor is restricted to the root domains of Active Directory trees that will require a two-label domain name, and excludes the use of Internet-registered DNS namespaces, or delegated child domains of an Internetregistered DNS namespace. Hence, where there is a requirement to use this factor, it must be included within a conditional naming rule for root domains. Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “specific internal suffix” factor for root domain names within a conditional naming rule for root domains  Where the requirement for the use of this factor is identified, determine the suffix or suffixes to be used and their scope of application (all or specific trees, and all or specific forests) within the Active Directory infrastructure. • Business Usage Factor A47: Determination of the requirements for business usage factors for a DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the use of business usage factors within a DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A business usage factor stipulates the parameters and framework for the application of a DNS namespace design model. This is important to ensure the correct and appropriate use of the design model for naming Active Directory domains. When determining the requirement for the use of business usage factors for a DNS namespace design model, consider the following examples of scenarios:  The lack of any guidelines or a framework for the controlled use of a DNS namespace design model may present a security risk. For example, within an organisation that has many Active Directory domains represented on the network infrastructure, unauthorised access and use of the DNS namespace design model (that employs the “security” factor) may permit an authorised user to effectively establish and disguise a domain on the network infrastructure. The presence of one extra domain, correctly named, amongst many other domains, may easily go unnoticed, and serve as the platform for launching attacks on the internal network infrastructure.  The lack of any guidelines or a framework for the use of a DNS namespace design model may result in incorrectly named domains. For example, administrators of autonomous divisions may incorrectly interpret a component of the namespace design model, such as the scope of application for a factor, or the process for the generation of a domain name. Absence of controls to perform, for example, checks on the accuracy and applicability of generated domain names prior to application, may permit the administrators to apply an incorrect domain name. The subsequent re-naming of such domains, to ensure compliance with the design model, although possible, may be a costly and time-consuming exercise.

Page 167 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The lack of any guidelines or a framework for a DNS namespace design model, to prevent its use beyond its intended scope of application, may present a security risk via exposure of the naming model components and rules. For example, an administrator within an organisation may inappropriately use the DNS namespace design model, with a restricted internal scope of application, to name Active Directory domains exposed for use on the Internet to support an Internet-based service offered by the organisation. Use the above information to execute an analysis to determine and document the requirements for the use of business usage factors (examples presented below). • Business Usage Factor A48: Determination of the requirement for controlled access and use of the DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to consider the use of this business usage factor, to ensure guidelines are present for the secure access to, and use of, the DNS namespace design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Any DNS namespace design model, which employs the security factor and thus contains the rules to generated coded domain names, requires secured and controlled access and use. The following are examples of possible components of a framework necessary to ensure secured and controlled access and use of a design model:  The storage of the DNS namespace design model on a secure server / storage location that provides physical and network security  The use of existing or designated security boundaries to control access and use of the design model  The use of an access control procedure to be followed to permit access and use of the design model When determining the requirements for the use of this factor to govern the use of a DNS namespace design mode, consider the following:  The application of this factor may only have relevance in organisations where security is a primary concern, such as military, governmental, or research organisations.  The implementation of this factor may imply a significant administrative, and potential financial, overhead that requires consideration Using the above information, conduct an analysis to determine the following:  The requirement for the use of this factor within a non-conditional usage rule  Upon identification of this requirement, determine the mode of application of this factor, identifying the controls and procedures that are necessary to restrict access to, and use of, the DNS namespace design model. • Business Usage Factor A49: Determination of the requirement to establish an approval process for generated domain names ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to establish an approval process for domain names

Page 168 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

generated using the DNS namespace design model prior to their application within the production environment ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: An approval process for Active Directory domain names generated by a DNS namespace design model is imperative to prevent costly and time-consuming Windows Server 2003 Active Directory domain re-name exercises. The components of this factor must hence include the following:  The domain name approval process  A list of the approvers for generated domain name, based upon scope of application of domain naming rules within a design model  The criteria for the approval or rejection of a generated domain name  A change control procedure for the approval process to cater for new requirements When determining the requirement for the use of this factor, consider the following:  Consider the requirement to ensure that the approval process meet the following example criteria:  The approval process should be simple to use and not a time consuming process with many steps and complex approval paths  The approval process will require distribution to the appropriate administrators to ensure awareness of its existence, function, and scope  The use of an approval process may imply a significant administrative, and potential financial, overhead that requires consideration Using the above information, conduct an analysis to determine the following:  The requirement for the use of the approval process factor within a non-conditional usage rule  Upon identification of this requirement, determine the required components of the approval process, to operate within the parameters of stated criteria. • Business Usage Factor A50: Determination of the requirement to define the scope for application of a DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to define the scope for application of a DNS namespace design model within the organisation. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Guidelines to define the scope for application of a DNS namespace design model may ensure the appropriate use of the design model within an organisation. For example, there may be the requirement to restrict the use of the design model against only production Active Directory domains, and not test, development, or temporary domains. When determining the requirement for the use of this factor, consider the following:

Page 169 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The ideal scope for application of a DNS namespace design model is the Active Directory infrastructure for an organisation (as reflected by the positioning of this design process within the Organisation-Wide Active Directory Plan).  Where the scope for component naming rules within a DNS namespace design model vary from specific child domains within a tree, to all domains within the entire Active Directory infrastructure, then this usage factor should reflect this variety of scopes. Using the above information, conduct an analysis to determine the following:  The requirement for the use of the “definition of the scope for the design model” factor within a non-conditional usage rule  Upon identification of this requirement, determine the required scope(s) for the use of the DNS namespace design model 5.9.5. Design of a DNS Namespace Strategy The activities to produce a design for a DNS namespace strategy can commence following the completion of all DNS namespace analysis tasks. The design for the DNS namespace strategy will contain one or both of the following elements: 1. 2. A design for a DNS namespace design model, where required by an organisation A design for the DNS namespace infrastructure (DNS domain names for all required domains within the Active Directory infrastructure), with or without the use of a design model

Presented within the following two sections are the considerations for the execution of this step within this process: 1. 2. 5.9.5.1. The considerations for the design of a DNS namespace design model The considerations for the design of DNS namespace infrastructure Design of a DNS Namespace Design Model Consider the following information when generating a design for a DNS namespace design model: • Factor D2: Generating a design for a DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a DNS namespace design model,  Has determined all of the design requirements for a DNS namespace design model, and  Wishes to understand the required structure and format for the design model ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes that the design for the required DNS namespace design model adopt the following format and contents:

Page 170 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A detailed design document detailing all design requirements for the components of the DNS namespace design model  A flow chart that reflects that rules, factors, and priorities identified during the analysis phase. When generating the design for the flow chart, to reflect the required DNS namespace design mode, it is important to ensure the following:  There are no ambiguities at any decision points that could result in an incorrect domain name been produced  The flow chart must be able to be used without significant guidance notes and hence must be kept as simple as possible  All potential conflicts must be thought out and resolved within the flow chart  Where there are many naming rules, and factors to be considered per naming rule, consider a hierarchical flow chart structure with, for example, one discrete flow chart for each rule, and one flow chart to spawn them all at the beginning of the process. Using the above information, generate a design for the DNS namespace design model, and supporting flow chart. • Factor B25: Understanding the requirements to provide training in use of DNS namespace design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a DNS namespace design model, and  Wishes to understand the requirements to provide training in the use of the DNS namespace design model ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where an organisation has developed a complex design model, this design methodology recommends that either training or written instructions accompany the distribution of the design model to the administrators responsible for its application. This is imperative in organisations where, for example, administrators manage divisions distributed across many geographical locations, and, for example, they use a different primary language to that of the administrators that developed the design model. Misunderstandings due to language differences may result in the generation of undesirable domain names, and hence unacceptable consequences. 5.9.5.2. Design of DNS Namespace Infrastructure Consider the following information when generating a design for DNS namespaces and child domain names, with or without the use of a namespace design model: • Factor D3: Generation of a design for DNS namespace infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has completed the DNS namespace gap analysis and identified the requirements for the execution of DNS namespace design tasks, and

Page 171 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to generate the design for the DNS namespace infrastructure for the DNS infrastructure, with or without the use of a design model ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes that the design for the DNS namespace infrastructure, for each required DNS infrastructure, comprise the following format and contents:  A detailed design document identifying the following:  The DNS domain names that require assignment to each required Windows Server 2003 Active Directory domain within the scope of the Active Directory infrastructure for a DNS infrastructure.  The factors influential in the generation of each required DNS domain name  A diagram illustrating the logical infrastructure or the scope of the Active Directory infrastructure supported by a DNS infrastructure, and the assigned DNS domain names 5.9.6. Determination of the Design Requirements for a DNS Server Infrastructure All organisations following “Track 1”, “Track 2”, or “Track 3” are required to execute this step within this process. Consider the following information when determining the design requirements for a DNS server infrastructure, to support an Active Directory infrastructure. Presented within the following two sections are the considerations for the execution of this step within this process: 1. 2. 5.9.6.1. Considerations for the determination of the business and technical design requirements for a DNS server infrastructure Considerations for the determination of the Active Directory design requirements for a DNS server infrastructure Determination of the Business and Technical Design Requirements for a DNS Server Infrastructure Consider the following information when determining the business and technical requirements for the design of a DNS server infrastructure to support the defined scope of the Active Directory infrastructure: • Factor B26: Understanding the approach to determine the design requirements for a DNS server infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the design requirements for a DNS server infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The process to determine the design requirements for a DNS server infrastructure, to reflect business and technical objectives and to support the defined scope of the Active Directory infrastructure, uses the following steps:  Execution of an analysis of the current DNS server infrastructure

Page 172 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determination of the design requirements for:  A DNS server infrastructure to support the defined scope of the Active Directory infrastructure  The tasks to build, implement, and configure the DNS server infrastructure  Execution of a gap analysis between current and required DNS server infrastructure design requirements to identify design tasks  Generation of a design for a DNS server infrastructure  Generation of a design for a process to support one or more of the following:  Build, implement, and configure the required DNS servers  Upgrade and configure existing DNS servers  Modify the configuration of existing DNS servers  Execute a migration of one or more existing DNS servers to a new DNS server software platform In order to execute the second step in this process, (this section), it is necessary to determine the design requirements for a DNS server infrastructure using a DNS server software standard that matches the support requirements for an Active Directory infrastructure. Windows Server 2003 DNS server software is exactly aligned with all of the support requirements for a Windows Server 2003 Active Directory infrastructure. Hence, all considerations presented below support identification of DNS server requirements against the use of a Windows Server 2003 DNS server infrastructure, which is the “ideal” DNS server software because it has the most accurate alignment with the DNS support requirements of a Windows Server 2003 Active Directory infrastructure. For organisations following “Track 3” of this process, the final DNS server software used to support the defined scope of the Active Directory infrastructure may not be Windows Server 2003 DNS server, but instead another third party software. However, for the purpose of identification of design requirements for a DNS server infrastructure, to support the defined scope of the Active Directory infrastructure, the considerations presented are based upon the use of Windows Server 2003 DNS server software. For organisations following “Track 1” or “Track 2” of this process (have no existing internal DNS servers), this design methodology strongly recommends the use of Windows Server 2003 DNS server software, as the DNS server platform to support the Windows Server 2003 Active Directory infrastructure for the organisation. This design methodology proposes that organisations execute an analysis to determine the design requirements to support business and technical objectives first, and then determine the most appropriate software to support those requirements. This approach hence prevents the undesirable consequence of attempting to constrain business and technical requirements around the limitations and functional boundaries of current DNS server software within an organisation. This design methodology proposes the following approach to determine the design requirements for a DNS server infrastructure, to support business and technical objectives and requirements:

Page 173 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Understand the overheads associated with the management of multiple DNS namespaces within a DNS infrastructure  Determine the design requirements for a name resolution strategy for a DNS infrastructure  Determine the design requirements for DNS zones within a DNS infrastructure  Determine the design requirements for DNS zone replication within a DNS infrastructure  Determine the design requirements for the integration of DNS with WINS and DHCP  Determine the design requirements for the DNS servers within a DNS infrastructure  Determine the design requirements for the tasks to build, implement, and configure DNS servers within a DNS infrastructure Hence, to reflect the above approach, the following seven sections present the considerations for this process:  Considerations for the management of multiple DNS namespaces within a DNS infrastructure  Considerations for the determination of the design requirements for a name resolution strategy  Considerations for the determination of the design requirements for DNS zones within a DNS infrastructure  Considerations for the determination of the design requirements for DNS zone replication within a DNS infrastructure  Considerations for the determination of the design requirements for the integration of DNS with WINS and DHCP  Considerations for the determination of the design requirements for the DNS servers within a DNS infrastructure  Considerations for the determination of the design requirements for the build, deployment, and configuration of the identified DNS servers for the DNS infrastructure 5.9.6.1.1. Management of Multiple DNS Namespaces

Consider the following information when attempting to understand the overheads associated with the management of a DNS infrastructure supporting multiple DNS namespaces: • Factor B27: Understanding the overheads associated with the management of multiple DNS namespaces ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the creation or continued support for multiple DNS namespaces, and  Wishes to understand the implications associated with the management and support of a multiple DNS namespace infrastructure

Page 174 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to execution of an analysis to determine the design requirements for a DNS server infrastructure, it is important to acknowledge and bear in mind the financial and management overheads associated with the following:  The management of multiple DNS namespaces  The distribution of multiple DNS namespaces amongst multiple DNS servers Where an organisation has identified the requirement for the support or continued support of a multiple DNS namespace infrastructure, it is important to consider the following examples of management and financial overheads associated with each namespace:  The overheads associated with the number of DNS servers required to support the multiple DNS namespaces  The overheads associated with the distribution of the DNS namespaces across DNS servers within multiple geographical locations for an organisation  The management overheads associated with each DNS zone within each DNS namespace for an organisation It is also very important to consider the following:  The scalability and growth potential for the DNS namespaces to reflect the potential growth of an organisation, and  The potential requirements to consolidate multiple DNS namespaces, for example, to reduce the total cost of ownership (TCO) for a DNS server infrastructure, or scale down an organisation in the face of a depressed economy, and so on. • Factor B28: Understanding the overheads associated with the distribution of multiple DNS namespaces amongst multiple DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of multiple DNS namespaces, and  Wishes to consider the overheads and implications associated with the distribution of DNS namespaces across all or specific DNS servers within an organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The design for the distribution of multiple DNS namespaces amongst DNS servers within an infrastructure must consider the following:  The physical distribution of the clients for each DNS namespace within the organisation  The numbers of DNS servers required to support multiple DNS namespaces  The potential physical distribution topology for DNS servers within an organisation to cater for support of local requirements  The requirements to preserve net levels of available bandwidth within WAN links

Page 175 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The requirements for load-balancing of DNS server services to support large volumes of name resolution requests from multiple clients, without degradation to the performance of the services, and so on The design for DNS zones and zone replication and transfers, and the requirements for the performance, redundancy, and availability of the DNS infrastructure discussed later in this process, will consider and cater for the distribution of multiple DNS namespaces across multiple DNS servers 5.9.6.1.2. Determination of the Design Requirements for a Name Resolution Strategy

Consider the following when determining the design requirements for a name resolution strategy for a DNS infrastructure: • Factor B29: Understanding the approach to determine the design requirements for a name resolution strategy, for a DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the design requirements for a name resolution strategy for a DNS infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes execution of the following approach to determine the design requirements for a name resolution strategy, for a DNS infrastructure:  Understand the objectives and components of a name resolution strategy  Determine the requirements for intra-namespace and inter-namespace name resolution, and the required strategy to support the identified requirements  Determine the design requirements for the use of internal or external root DNS servers  Determine the design requirements for the use of root hints on internal DNS servers  Determine the design requirements for the use of forwarder and conditional forwarder configuration entries  Determine the design requirements for forwarder and conditional forwarder entries  Determine the design requirements for the use of internal forwarder DNS servers  Determine the design requirements for the use of caching-only DNS servers  Determine the design requirements for the use of stub zones Following identification of the design requirements for a name resolution strategy, the process to determine the design requirements for DNS servers (see later) will assist an organisation in identification of the following:  The configuration design requirements, as part of a standard DNS server configuration, for a caching-only DNS server role  The number of caching-only DNS servers required  The configuration design requirements, as part of a standard DNS server configuration, for an internal forwarder DNS server role

Page 176 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The number of actual or virtual internal forwarder DNS servers required  The configuration design requirements, as part of a standard DNS server configuration, for an internal root DNS server role  The number of actual or virtual internal root DNS servers required • Factor B30: Understanding the objectives and components of a name resolution strategy ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of one or more DNS namespaces within the DNS infrastructure, and  Wishes to understand the objectives and components of a name resolution strategy for a DNS infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objective of a name resolution strategy is to integrate multiple internal and / or external (Internet) DNS namespaces. DNS server software provides service location and name resolution services to DNS clients of the DNS infrastructure. When a DNS client requests the IP address for a FQDN of a server, the DNS server service will resolve the supplied FQDN to an IP address. Where the FQDN supplied by a DNS client is beyond the scope of authority for a DNS server, it is necessary to configure support for routing of these name resolution queries between DNS servers, to find an authoritative DNS server, where possible. The name resolution strategy provides the strategy and design for the routing of name resolution queries between DNS servers, to support intra-namespace and internamespace name resolution. This design methodology recognises the following three types of name resolution strategies:  A strict intra-namespace name resolution strategy  A strict inter-namespace name resolution strategy  A hybrid intra-namespace and inter-namespace strategy As the objective of this process is to design a DNS infrastructure to support a defined scope of a Windows Server 2003 Active Directory infrastructure, the design for a name resolution strategy must primarily support name resolution within and between Active Directory DNS namespaces. However, it would be unfeasible to design and implement a DNS infrastructure that only supports internal name resolution, or restricted internal and external name resolution, to support (for example) and extranet federated forest infrastructure. Hence, this design methodology requires the design and implementation of the hybrid name resolution strategy for a DNS infrastructure. This name resolution strategy will hence be required to support both intra-namespace and inter-namespace name resolution, for all name resolution queries within an organisation, and not exclusively to support a Windows Server 2003 Active Directory infrastructure. The components of a name resolution strategy, which support the routing of intranamespace and inter-namespace name queries, are all configuration aspects of DNS

Page 177 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

server software. Hence, the determination of the design requirements for a name resolution strategy is a component of the design for a DNS server infrastructure. The following components are associated with a name resolution strategy, to reflect the capabilities and features of Windows Server 2003 DNS server software:  The use of internal or external root DNS servers  The use of root hints on internal DNS servers  The use of forwarder and conditional forwarder configuration entries  The configuration of forwarder and conditional forwarder entries  The use of internal forwarder DNS servers  The use of caching-only DNS servers  The use of stub zones Note that not all DNS server software currently in use will support conditional forwarding of name resolution requests or the use of stub zones. However, most DNS server software currently in use does support the use of root hints, forwarders, and domain delegations. Note that every design for a name resolution strategy is required to reflect specific intranamespace and inter-namespace name resolution requirements for an organisation. Hence, depending upon the identified design requirements for intra-namespace and inter-namespace name resolution, every name resolution strategy will employ differing components, and naturally, differing configurations for these components. The following simple example illustrates the relationships between the components of a name resolution strategy listed above. Note that the intention of this diagram is merely to illustrate the relationships of these features, and does not represent a recommended design for a name resolution strategy for use as per the illustration, without consideration of the factors that will influence the design of the name resolution strategy.

Page 178 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

INTERNET RHE
A.root-servers. Net Firewall

Cache.dns

Forwarder DNS Server (Multihomed)

F / CF
Firewall

LEGEND: RHI = Root Hint to Internal Root DNS Server RHE = Root Hint to External Root DNS Server D = Delegation SZ = Stub Zone F = Forwarder CF = Conditional Forwarder RHI SZ
DNS1.A.com

RHI
DNS Zone

DNS1. Natsum.com

RHI SZ
Internal Root DNS Server

DNS Zone

D / SZ
Natsum.com.

A.com.

DNS2.C.B. Natsum.com

B. Natsum.com.

A. Natsum.com.

B.A.com.

C.A.com.

DNS Zone

C.B. Natsum.com.

D.B. Natsum.com.

D.B.A.com.

E.B.A.com.

© 2 0 0 4 MU S TA NS HI

R

BHAR

MAL

Figure 6.11: Example Illustration of Relationships between Name Resolution Strategy Components • Factor A51: Determination of the requirements for an intra- and inter-namespace name resolution strategy ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of one or more DNS namespaces, and  Wishes to determine the requirements for an intra- and inter-namespace name resolution, and the strategy to support identified requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the requirements for an intra-namespace and inter-namespace name resolution strategy, consider the following:  As discussed earlier, this design methodology requires that the scope of support provided by a name resolution strategy encompass all name resolution requirements within an organisation, inclusive of Active Directory name resolution requirements.  All requirements for internal and external intra-namespace and inter-namespace name resolution support resource or service access by users, computers, applications, services, and protocols. Hence, when determining the requirements for intra-namespace and inter-namespace name resolution, it is necessary to determine all requirements to support resource and / or service access within and between namespaces.

Page 179 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Hence, when determining the requirement for an intra-namespace and internamespace name resolution strategy, this design methodology proposes execution of the following approach:  Execute an analysis to identify all requirements to support internal and external intra-namespace resource / service access  Execute an analysis to identify all requirements to support internal and external inter-namespace resource / service access  Determine the initial requirements for components of a name resolution strategy to support all identified intra-namespace and inter-namespace name resolution requirements When executing an analysis to identify all requirements to support internal and external intra-namespace resource / service access, consider the following:  Requirements for intra-namespace name resolution imply requirements to support name resolution within a single DNS domain name (intra-domain) and between domains (inter-domain) within the same DNS namespace.  Both of these forms of access to resources and services require support from a name resolution strategy.  The following diagram illustrates examples of intra-domain and inter-domain access to resources, within the same DNS namespace (intra-namespace):
LEGEND:
DB1.Natsum.com.

1 2

Intra-Domain Resource Access Inter-Domain Resource Access

Natsum.com.

FS1.C.B. Natsum.com.

2
B. Natsum.com. A. Natsum.com.

1
Laptop1.C.B. Natsum.com.

C.B. Natsum.com.

D.B. Natsum.com.
© 2 0 0 4 MU ST AN SH I
R

BHARMAL

Figure 6.12: Example of Intra-Namespace Resource Access  This design methodology recommends the assumption that all Active Directory domains within a tree of domains (a DNS namespace) will require support by a name resolution strategy for intra-namespace name resolution.  It is important to identify all non-Active Directory related requirements to support intra-namespace name resolution, such as:  Between web servers hosting an intranet or Internet-facing web site  Between clients of an internal or external-facing web infrastructure

Page 180 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When executing an analysis to identify all requirements to support internal and external inter-namespace resource / service access, consider the following:  Requirements for inter-namespace name resolution strictly imply requirements to support name resolution between domains (inter-domain) that reside within different DNS namespaces.  It is important to note that a name resolution strategy for a DNS infrastructure is only required to support the following requirements for inter-namespace name resolution:  The requirements to support name resolution between different DNS namespaces exclusively within an organisation, and / or  The requirements to support name resolution between different DNS namespaces where one namespace resides within an organisation and another outside of the logical boundaries of an organisation  This design methodology does not support the design for a name resolution strategy, for a DNS infrastructure, to support inter-namespace name resolution where the different namespaces reside exclusively outside of the logical boundaries of an organisation. The onus on provision of this, strictly external, name resolution service is with the ISP for an organisation.  The following diagram illustrates an example of inter-domain access to resources, between different DNS namespaces (inter-namespace):
LEGEND:

1
Natsum.com.

Inter-Domain Resource Access

DB1.A.com.

B. Natsum.com.

A. Natsum.com.

1

A.com.

D.B. Natsum.com.

Laptop1.D.B. Natsum.com.

B.A.com.
© 2004 MUSTANSHI
R

BHARMAL

Figure 6.13: Example of Inter-Namespace Resource Access  This design methodology provides the following examples of where an organisation may require inter-namespace name resolution, within or between organisations:  An organisation is planning the design of intranet or extranet federated forest infrastructures, to integrate two or more internal Windows Server 2003 Active Directory forests. The results of the Organisation-Wide Active Directory Plan process, “design of federated forest infrastructures”, will identify all requirements for a DNS infrastructure to support inter-namespace name resolution, to support in turn, an intranet or extranet federated forest infrastructure.  An organisation is planning the design of one or more external trust-relationships between domains within separate Windows Server 2003 Active Directory forests. The results of the Domain Plan (for each Windows Server 2003 Active Directory domain required within each forest) process, “design external trust-relationships”, will identify all requirements for a DNS infrastructure to support inter-namespace

Page 181 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

name resolution, to support in turn, the requirements for one or more external trust-relationships. When determining the initial components of a name resolution strategy, required to support all identified intra-namespace and inter-namespace name resolution requirements, consider the following:  This design methodology proposes execution of the following approach to determine the initial components of a name resolution strategy:  Understand the possible approaches towards the design of a name resolution strategy  Understand the (high-level) role of each potential component of a name resolution strategy in supporting intra-namespace and inter-namespace name resolution  Determine the initial components of a name resolution strategy to support identified intra-namespace and inter-namespace name resolution requirements  When attempting to understand the possible approaches towards the design of a name resolution strategy, consider the following:  This design methodology recognises two possible approaches towards the design of an intra- and inter-namespace name resolution strategy: • The first possible approach is to configure each DNS server to host a replica of all DNS zones within each namespace that is to be included within the scope of the name resolution strategy. This hence makes every DNS server authoritative for all DNS data within a DNS infrastructure. This approach thus negates the requirement for inter-server name resolution and hence the requirements for a name resolution strategy. • The second approach is to design and configure name resolution pathways between DNS servers within and between one or more DNS server infrastructures, and support distributed name resolution.  The selection of the first possible approach will have a very limited scope of application within the majority of organisations. This design methodology does not recommend this approach, and proposes the following criteria to support its use within an organisation: • The organisation is a small organisation with no requirements for external name resolution, and • The organisation has a single or a very few internal DNS namespaces, that each contain only one or a few DNS zones hosted on local DNS servers, and • The organisation is physically located in one geographical location  Where it is not possible to identify compliance with the above criteria, then an organisation is required to select the second design approach.  The second option, to configure name resolution pathways between DNS servers within and between one or more DNS server infrastructures, will have a broader scope of application within the majority of organisations. When attempting to understand the role of each potential component of a name resolution strategy, in supporting intra-namespace and inter-namespace name resolution, consider the following:

Page 182 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The design of one or more pathways for intra- and inter-namespace name resolution involves the use of all or some of the following DNS server roles and software features, as components of a name resolution strategy:  Internal and external root DNS servers  Root hints to internal or external root DNS servers  Internal forwarder DNS server  Forwarders and conditional forwarder configuration entries  Caching-only DNS servers  Delegations and stub zones  When attempting to understand the role of internal and external root DNS servers, in the design of a name resolution strategy, consider the following:  Thirteen root DNS servers, authoritative for the “root” (“.”) DNS namespace, support the Internet. The InterNIC supports these root DNS servers, and it provides a list of their names and IP addresses under anonymous FTP, as the file “/domain/named.root”, on the server FTP.INTERNIC.NET. The “cache.dns” file for a Windows Server 2003 DNS server contains the list of the names and IP addresses for these root DNS servers. As all Internet DNS namespaces terminate at the root (“.”) domain, these servers are authoritative for all top-level domain names for all Internet-registered DNS namespaces.  An internal root DNS server, as a logical role assigned to an internal DNS server, is aware of all internal DNS namespaces, and is hence able to support all (strictly internal) inter-namespace and intra-namespace name resolution requirements.  When attempting to understand the role of root hints to internal or external root DNS servers, in the design of a name resolution strategy, consider the following:  Internal DNS servers within a DNS infrastructure employ root hints to locate an internal or external root DNS server. A root hint is simply a name and IP address for an internal or external root DNS server.  The use of root hints support the concept of name resolution pathways. Where an internal DNS server is unable to locally resolve an inter-namespace name query, or use any configured forwarders or conditional forwarders to assist in name resolution, the server will resort to a root DNS server, via a configured root hint, as the next step in name resolution.  Note that although root hints require configuration on internal DNS servers, and a DNS server can support a number of root hints, the internal DNS servers are unaware of whether the root hints point to internal or external root DNS servers. The design of the name resolution pathways will dictate which root hints, on which DNS servers, point to internal and / or external root DNS servers.  When attempting to understand the role of an internal forwarder DNS server, in the design of a name resolution strategy, consider the following:  The recommended function for an internal forwarder DNS server is to route all name queries for inter-namespace name queries, which an internal DNS server or internal root DNS server is unable to resolve, to an external DNS server.  An internal forwarder DNS server, in the strictest manifestation of this role, has hence a critical role within a name resolution strategy, but a limited scope of support.

Page 183 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 When attempting to understand the role of forwarder and conditional forwarder configuration entries, in the design of a name resolution strategy, consider the following:  Internal DNS servers employ a forwarder entry to locate another DNS server (internal or external) to assist in a name resolution query, when it is unable to resolve a received name resolution query, using its local cache and local DNS zones.  A forwarder configuration entry, like a root hint, contains the name and IP address of another DNS server, and is not DNS namespace specific.  A conditional forwarder configuration entry is the same as a forwarder entry but is DNS namespace specific. Hence, a conditional forwarder entry will route a name resolution query to another DNS server based upon the DNS namespace in the name resolution query received by the DNS server. Windows Server 2003 DNS server now supports conditional forwarder entries.  A conditional forwarder is hence useful in configuration of a specific internamespace name resolution pathway between two DNS servers.  When attempting to understand the role of caching-only DNS servers, in the design of a name resolution strategy, consider the following:  A caching-only DNS server is simply an internal DNS server that does not have any forward or reverse lookup DNS zones. Hence, a caching-only DNS server is only able to support name resolution via: • The use of a local cache of resolved name queries • The use of forwarder and conditional forwarder configuration entries • The use of root hints to an internal or external root DNS server  A caching-only DNS server does not participate in any DNS zone replication topologies.  When attempting to understand the role of delegation and stub zones, in the design of a name resolution strategy, consider the following:  Delegation within DNS implies the partitioning of a DNS namespace hosted by a DNS zone, into multiple DNS zones. This hence creates delegation and glue resource records within the parent DNS zone. An internal DNS server will use delegation records in attempts to resolve received name queries, prior to the use of any configured forwarder or conditional forwarder entries.  Stub zones are DNS zones created on an internal DNS server which act as a shortcut or pointer to the DNS name server authoritative for the actual DNS zone. A stub zone is hence similar to a secondary DNS zone, as it receives transfers from the master DNS zone, but the scope of zone transfers are restricted to the following records: • The Start of Authority (SOA) resource record (RR) • The name server (NS) resource records (RRs) for the DNS name servers authoritative for that DNS zone • The host (A) RRs for the name servers authoritative of that DNS zone

Page 184 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 An internal DNS server will use local stub zones in attempts to resolve received name queries, prior to the use of any configured forwarder or conditional forwarder entries.  This design methodology recommends the use of stub zones to create an internal root DNS server (see later for details). Using the above information, execute the following:  Determine and document the requirements to support internal and external intranamespace name resolution within the organisation  Determine and document the requirements to support internal and external internamespace name resolution within the organisation  Determine and document the initial components required to support the design and implementation of a name resolution strategy, which will support all identified intranamespace and inter-namespace name resolution requirements.  Qualify all initial required components, for a name resolution strategy, via execution of the following factors. • Factor A52: Determination of the requirements for the use of internal and / or external root DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a name resolution strategy that employs name resolution pathways between DNS servers, and  Has identified the initial requirement to include this component within the design for a name resolution strategy, and  Wishes to qualify the requirements for the use of either internal or an external root DNS servers as a component of a name resolution strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A root DNS server is authoritative for all namespaces it supports, within the context of the role of a root server. The root DNS servers that support the Internet root (“.”) domain are configured within the default cache.dns file for a Windows 2000 / Windows Server 2003 DNS server. It is possible for an organisation to design and implement one or more internal root DNS servers that will be authoritative for all, or a set of, internal DNS namespaces. Note that the term “internal” refers to those DNS namespaces “owned” by an organisation, whether registered for use on the Internet or only on the private internal network. When determining the requirements for the design and implementation of an internal root DNS server, consider the following:  The selection of an internal or external root DNS server depends upon the following requirements:  The requirement for access to resources outside of an internal DNS namespace for an organisation, and the proxy capabilities of computers within the internal network of an organisation that require access to resources beyond the scope of the internal DNS namespace of an organisation

Page 185 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The use of internal DNS namespaces to support an Active Directory infrastructure where they match external (Internet-registered) DNS namespaces  The presence of internal DNS namespaces that are not registered for use on the Internet, and the requirement to support name resolution requests for RRs within these namespaces from other namespaces within an organisation  Where computers within an organisation require access to resources that are beyond the scope of an internal DNS namespace, for example on the Internet, then it may not be possible to use an internal root DNS server unless:  The proxy capabilities of the computers permit distinction between internal and external DNS namespaces, or  Conditional forwarding is configured on an internal root DNS server to point to a forwarder DNS server that can resolve name queries for Internet namespaces Where an organisation is considering the use of the same namespace for an Active Directory infrastructure as registered on the Internet, then it may not be possible to use an internal root DNS server if the internal namespaces duplicate the external namespaces. The following example explains this restriction on the use of an internal root DNS server, where an organisation has, for example, an Internet-registered DNS namespace of “Natsum.com.”, and wish to use it internally to represent a Windows Server 2003 Active Directory tree of domains. The organisation has an internal root DNS server, “IntRootDNS1.A.com.”, with a stub zone configured for the DNS zone “B.Natsum.com.”. In a normal internal name query, the use of the same internal namespace as an external (Internet-registered) namespace with an internal root DNS server presents no issues, as illustrated in the following diagram: A client (“Client.B.A.com.”) within the organisation, from another Windows Server 2003 Active Directory tree (“A.com.”) wishes to access a file server in the “Natsum.com.” Active Directory tree named “FS1.B.Natsum.com.”. The following steps occur:

Page 186 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Stub Zone for B.Natsum.com: @ IN SOA DNS1. admin. ... ; Zone NS records @ NS DNS1.B.Natsum.com. DNS1.B.Natsum.com. A 192.169.2.55

INTERNET

IntRootDNS1. A.com.

DNS Zone Natsum.com.

WebServer Hosting “www.natsum.com”

Cache.dns

2 1

3 4
B. Natsum.com. A. Natsum.com. FS1.B. Natsum. com. DNS1. B.Natsum.com.

A.com. Client. B.A.com.

6

DNS2. B.A.com.

5

Cache.dns B.A.com.

Manually Configured Root Hint: 3600000 NS IntRootDNS1.A.com. IntRootDNS1.A.com. 360000 192.169.2.57

7
Name Resolution Steps:

© 2004 MUSTANSHI

R

BHARMAL

1 2 3 4 5 6 7

The client (Client.B.A.com.) sends a name query to its designated DNS name server (DNS2.B.A.com.) requesting name resolution for “FS1.B.Natsum.com.” After examination of the primary and secondary zones and the cache , the DNS server (DNS2.B.A.com.) determines it is not authoritative for the “Natsum.com.” namespace. It then sends an iterative query to the internal root DNS server (IntRootDNS1.A.com.) via a manually configured root hint. The internal root DNS server examines its zones and finds a stub zone (in this example) for the “B.Natsum.com.” DNS zone, with a NS RR pointing to the DNS server authoritative for this zone (DNS1.B.Natsum.com.). It then sends “DNS2.B.A.com.” the IP address for “DNS1.B.Natsum.com.”. “DNS2.B.A.com.” sends an iterative query to “DNS1.B.Natsum.com.” to resolve the name query for “FS1.B.Natsum.com.”

“DNS1.B.Natsum.com.” send the IP address for “FS1.B.Natsum.com.” to “DNS2.B.A.com.”

“DNS2.B.A.com.” sends the IP address for “FS1.B.Natsum.com.” to “Client.B.A.com.”

The client (Client.B.A.com.) connects to “FS1.B.Natsum.com.” and access the required resources

Figure 6.14: Example of a Normal Name Resolution Process Using an Internal Root DNS Server However, if the internal client attempts to access a web page hosted within the Internetregistered DNS namespace of “Natsum.com.”, for example, www.Natsum.com, then the query will fail. This is because the internal root server, in the example depicted above, will use the stub zone records pointing to the internal DNS server that is authoritative for the “Natsum.com.” namespace first, and not use any configured forwarders or conditional forwarders. Any subsequent attempts to configure a conditional forwarder on the internal root DNS server to, for example, point to a forwarder DNS server for the “www.Natsum.com.” namespace, would not be allowed as this internal root DNS server is already authoritative for the “Natsum.com.” namespace. The Windows Server 2003 DNS server software will present the following error dialog box following such an attempt.

Page 187 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Figure 6.15: Windows Server 2003 DNS Error Dialog Box during Attempt to Enter a Forwarder Entry Thus, where an Internet-registered DNS namespace is used internally (to support, for example, an internal Windows Server 2003 Active Directory tree of domains), then internal clients will not be able to access the Internet-facing services of this server, unless the DNS server and RRs for the Internet-facing services under this namespace are within the scope of the name resolution strategy. However, in most organisations, there is typically a clear boundary established between DNS infrastructures supporting Internet-facing services and those supporting internal services, and hence between name resolution strategies, that would typically cope with such requests via the use of recursive requests to an Internet root DNS server. Where an organisation currently uses, or is planning the use of, DNS namespaces not registered with ICANN for use on the Internet, then it is not possible to use an external (Internet) root DNS server to support name resolution queries for RRs within these namespaces from other namespaces within an organisation. This scenario requires the use of one or more internal root DNS servers, or the use of conditional forwarders. Note that the exclusive use of conditional forwarders on all internal DNS servers may be an extensive administrative overhead where there are multiple internal DNS servers to be configured and maintained. However, the use of one or more internal root DNS servers with, for example, stub zones for the root zones supported on an appropriate authoritative internal DNS servers, has a lower administrative overhead associated, due the fewer numbers of DNS servers that will require configuration and maintenance. When determining the requirements for the use of internal root DNS servers, determine the number of internal root DNS servers required, and the scope for each required root DNS server. For example, an organisation may require the use of a single root DNS server to bridge multiple DNS infrastructures together that collectively support the Windows Server 2003 Active Directory infrastructure for the organisation. This internal “shared root” DNS server will have to have the appropriate stub zones or conditional forwarder entries to permit support for all internal inter-namespace name resolution queries between multiple DNS infrastructures. Where there is a requirement for multiple internal root DNS servers, it is necessary to determine the primary scope of support for each server, defined by physical and logical boundaries for a DNS infrastructure and the physical placement of each internal root DNS server. In addition, it is important to determine the requirements for the routing of internal internamespace name resolution queries between each internal root DNS server (via the use of stub zones and / or conditional forwarder entries). Using the above information, execute the following:  Determine and document the requirements for the use of an internal root DNS server

Page 188 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the number of internal root DNS servers required  Where there is the requirement for the design and deployment of multiple internal root DNS servers, then execute the following:  Determine and document the primary scope of support for each internal root DNS server  Determine and document the requirements for the routing of internal internamespace name resolution queries between each internal root DNS server (via the use of stub zones / conditional forwarder entries)  Determine and document the requirements for the use of an external root DNS server • Factor A53: Determination of the design requirements for root hints ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a name resolution strategy that employs name resolution pathways between DNS servers, and  Has identified the initial requirement to include this component within the design for a name resolution strategy, and  Wishes to qualify and determine the design requirements for the use and configuration of root hints as a component of a name resolution strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Root hints (stored by default in the file “Cache.dns”, located in the “%systemroot%\System32\dns” folder) permit DNS servers authoritative for non-root DNS zones to discover and locate DNS servers authoritative for DNS zones mapping to domain names higher up within a DNS namespace. See figure 6.14, example of a normal name resolution process using an internal root DNS server, for an example of the use of a root hint to locate a root DNS server. A DNS server uses root hints within the following order of events, after reception of a name resolution query from a DNS client:  The DNS server will first attempt to resolve the name query using any primary, secondary, and stub zones that it hosts, zone delegations, and the contents of its cache  If the first step fails, then the DNS server will use any configured forwarder entries for the DNS server to send a recursive query to a DNS server designated as the forwarder for this server / namespace (where conditional forwarders are used). The DNS server will wait for a configured time (default is 5 seconds) for a response from each configured forwarder DNS server, for each conditional forwarder entry, before executing the next step.  If all configured forwarders fail to respond, or the DNS server has no forwarders configured, then the DNS server will use any configured root hints to attempt to send a recursive query to a configured root hint server. Failure of the root hint server to resolve the name query will result in a negative response sent back to the DNS client that submitted the name resolution query.

Page 189 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When determining the requirements for the use of root hints, it is important to identify the internal root DNS servers to which the root hints will point. When identifying the internal root DNS servers for root hints, use the following selection criteria:  For an internal normal (non-root) DNS server to be configured with root hints, select an internal root DNS server that supports, as part of its scope, the DNS namespace supported by the internal (non-root) DNS server  Where multiple internal root DNS servers share a similar support scope, enter all of these root DNS servers within the root hints if they are all local to the DNS server. If, however, there are internal root DNS servers that are geographically remote to an internal DNS server, then select the closest root server based upon the most appropriate network links between the sites. Where internal root DNS servers are required, it is important to delete all the root hint entries, on all normal (non-forwarder) DNS servers, within the default cache.dns file pointing to the external root DNS servers, to prevent the redirection of internal name resolution traffic to external root DNS servers, without any control or filtering. The following illustration is an example of the scenario described above, where an internal root DNS server forwards a name query for an external namespace (on the Internet) to a multi-homed forwarder DNS server. None of the internal DNS servers has the default cache.dns file, and only the Internet-facing forwarder DNS server (in a DMZ) has the default cache.dns file with the root hints configured to point to external root DNS servers. Note: An alternative to this scenario would be to configure internal (non-root) DNS servers to send recursive queries directly to one or more forwarder DNS servers in a DMZ (using forwarder / conditional forwarder configuration entries), instead of via an internal root DNS server.

Page 190 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

6
INTERNET

Cache.dns

7 4

5
A.root-servers. Net Firewall

IntRootDNS1. A.com. Cache.dns Conditional Forwarder Entry: All other Domains 192.169.2.99

WebServer Hosting “www.natsum.com”

11

10 12

Forwarder DNS Server Firewall (Multihomed) (192.169.2.99 + Internet IP address)

3

8
Manually Configured Root Hint: 3600000 NS IntRootDNS1.A.com. IntRootDNS1.A.com. 360000 192.169.2.57 Cache.dns

1
Client. B.A.com.

2 9
DNS2. B.A.com.

© 2004 MUSTANSHI

R

BHAR

MAL

Name Resolution Steps (Note that not all actual steps are illustrated):

1 2 3 4 5 6 7 8 9
10 11 12

The client (“Client.B.A.com.”), wishing to access an Internet web site (“www.Natsum.com”), opens a web browser and enters the URL: “http:\\www.Natsum.com”. This submits a name resolution query to the designated DNS server , “DNS2.B.A.com.”, for the client The DNS server for the client (“DNS2.B.A.com.”) receives the name query and after determining it is not authoritative for the domain name “Natsum.com”, uses a configured root hint entry to send an iterative query to an internal root DNS server , “IntRootDNS1.A.com.”. The internal root DNS server, after determining it is not authoritative for the “Natsum.com.” namespace, uses a conditional forwarder (in this example) for “all other domains” to send a recursive query to a forwarder DNS server (192.169.2.99) The forwarder DNS servers, using root hint entries within the default “cache.dns” file, sends a query to an external root DNS server to resolve the address “www.Natsum.com” to an IP address An external root DNS server (in this example, “A.root-servers.net.”) resolves the namespace to an IP address (via the appropriate DNS servers authoritative for this namespace), and sends this back to the forwarder DNS server (note that not all steps are illustrated in this high-level example) The forwarder DNS server sends the IP address for the “www .Natsum.com” address back to the internal root DNS server The internal root DNS server sends the IP address for the “www .Natsum.com” address back to the internal DNS server (“DNS2.B.A.com.”) The internal DNS server (“DNS2.B.A.com.”) sends the IP address for the “www.Natsum.com” address back to the client (“Client.B.A.com.”) The client (“Client.B.A.com.”) connects to the web server hosting the “www.Natsum.com” web site

The web server hosting the “www.Natsum.com” web site sends the requested page to the client

The client (“Client.B.A.com.”) receives the requested web page

Figure 6.16: Example of the Use of Root Hints and an Internal Root DNS Server Note that the use of an internal root DNS server to conditionally forward entries to forwarder for resolution of Internet namespace name queries may result in pollution of the cache of the internal root DNS server. It is possible for an external attacker to re-direct a query to a false DNS server for a name query submitted via the internal root DNS server, and thus returns a polluted resolution that is stored in the cache on an internal root DNS server. All subsequent name queries for that namespace will go to a false DNS server until the DNS server administrator clears the cache on the internal root DNS server. To prevent this, the default configuration of a Windows Server 2003 DNS server secures the cache against pollution (selected checkbox in the “Advanced” tabbed page for the “Properties” dialog box of a DNS server).

Page 191 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

It is possible to configure a Windows 2000 DNS server to filter out responses for nonsecure records, and thus enable protection against cache pollution. Note that a Windows 2000 DNS Server with SP3 or later is by default configured to protect the cache against pollution. However, where SP3 or later is not applied, enable protection of the cache via the addition of a REG_DWORD registry entry “SecureResponses”, with a data value of “1” (to eliminate non-secure data) to following registry value within the “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters” registry key on the DNS server. Where there is a requirement to exclusively use an external root DNS server, then it is advisable that root hints are not used (delete the cache.dns file) on all internal DNS servers (except forwarders). Then configure all internal DNS servers to use forwarders to forward name resolution queries for RR within external namespaces to a “forwarder DNS server”. The “forwarder DNS server” can then use the root hints configured within the default cache.dns file to forward name resolution queries for RRs within external namespaces to an external root DNS server within, for example, an ISP for the organisation. Using the above information, execute the following:  Determine and document the requirement(s) for the use of root hints  Determine and document the identity of the DNS servers that require configuration with root hints, and the root DNS servers (internal or external) that require configuration within the cache.dns file  Determine and document the identity of the DNS servers not to use root hints and thus require deletion of the cache.dns file, “%systemroot%\System32\dns” folder  For each internal DNS server that will require configuration with root hints, determine and document the identity of the internal root DNS servers to which the root hints configured for these normal (non-root) internal DNS servers will point • Factor A54: Determination of the requirement for forwarders and conditional forwarders ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a name resolution strategy that employs name resolution pathways between DNS servers, and  Has identified the initial requirement to include this component within the design for a name resolution strategy, and  Wishes to qualify and determine the design requirements for the use of forwarder and conditional forwarder configuration entries as a component of a name resolution strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Within the context of a configuration feature for a DNS server (and not a role for a DNS server), a “forwarder” is an IP address entry configured on a DNS server. The DNS server uses this IP address entry to “forward” (as a recursive name query) any name resolution queries it receives from a resolver (a DNS client) that it cannot resolve using the primary or secondary zones or the cache it hosts. The term “forwarder” also refers to the recipient DNS server of this forwarded recursive name query, but now within the context of a role for this DNS server.

Page 192 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The role of a forwarder DNS server is to act as a bridge for name resolution pathways between DNS namespaces, as part of an intranet, extranet, and Internet name resolution strategy for a DNS server infrastructure. Hence, a forwarder DNS server, or the use of forwarder entries on a DNS server, is not required where an organisation has only one DNS namespace, and no requirements to route name resolution queries to an external (Internet or other) root DNS server (all name resolution queries are restricted to the internal / private network for the organisation). If, on the other hand, an organisation will require forwarders (role and configuration) where it is possible to identify compliance with the following requirements:  The organisation has multiple internal DNS namespaces, and  The requirement to route the following name resolution queries:  Between the internal namespaces (within the organisation (intranet)  Between the organisation and the DNS namespaces within another organisation (extranet), and  Between the organisation and any Internet DNS namespaces (Internet) Most version of DNS server software in use today supports the use of “forwarders” (as a configuration entry for a DNS server), however only a few versions of DNS server currently support conditional forwarding. Note that whilst Windows Server 2003 DNS server supports conditional forwarding, Windows 2000 DNS server does not. Conditional forwarding allows the selective forwarding of a name resolution query based upon the domain name within the query received from the resolver. Hence, it is possible to configure conditional forwarding entries, on a DNS server that supports this feature, to route name queries that pertain to specific DNS namespaces, or domain names within a namespace, to a forwarder DNS server. The use of conditional forwarding thus permits a granular approach to the use of forwarding within a name resolution strategy for a DNS infrastructure. The use of conditional forwarding on internal, non-root, DNS servers can assist in alleviating the workload on internal root DNS servers, for name resolution between namespaces within an organisation. For example, a client with a FQDN of “client1.B.A.com.” wishes to access resources on a file serve with a FQDN of “FileServer1.B.Natsum.com.”. If the designated DNS server for “client1.B.A.com.” is configured with a conditional forwarder to route all name queries for the domain “B.Natsum.com.” to the DNS server authoritative for this namespace (e.g. “DNS1.B.Natsum.com.”) then this means that the query does not have to travel to an internal root DNS server to be resolved because of the internamespace nature of the query. However, where an organisation has many internal DNS servers, there may be a significant administrative overhead to configure and maintain conditional forwarders for all possible domain namespaces within the organisation. In this scenario, it is simpler to establish the requirement for an internal root DNS server. Using the above information, execute the following:  Determine and document the requirements for the design and implementation of forwarder and conditional forwarders configuration entries

Page 193 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where there is a requirement to use forwarders and / or conditional forwarders, then determine the DNS servers, within each current DNS server infrastructure, capable of supporting the use of forwarders and conditional forwarders  Also determine the DNS servers within each current DNS server infrastructure, not capable of supporting these features  For those DNS servers unable to support these required features, determine whether an upgrade is possible and feasible to a version that is capable of supporting these required features • Factor A55: Determination of the configuration requirements for forwarders and conditional forwarders ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and use of forwarder and / or conditional forwarder entries, and  Wishes to determine the design requirements for the configuration of forwarder and conditional forwarder entries as a component of a name resolution strategy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When configuring conditional forwarder entries on a Windows Server 2003 DNS server, it is possible to enter multiple IP addresses for each conditional forwarder namespace. Thus, the following two factors require consideration for this configuration:  The requirement for multiple IP addresses for each domain name within a conditional forwarder, and  The order of the IP addresses within the list of the forwarder DNS servers for the domain name As discussed above, it is possible to use multiple IP addresses for a conditional forwarder entry to support requirements for fault tolerance of Internet name resolution services, and the control and segregation / partitioning of name resolution traffic. The order for the list of IP addresses is very important as they determine the sequence of their use by the DNS server when it attempts to forward a name query. The DNS server contacts a forwarder DNS server using the first IP address associated with the domain name within the received name query. Failure of the first forwarder DNS server to respond will cause the DNS server to use the second IP address on the list, and so on. It is important to ensure that forwarder DNS servers that are geographically (or based upon network access) local to a DNS server are placed at the top of any list of IP addresses for multiple forwarder DNS servers. This will ensure that a local DNS server, for example, in New York, does not attempt to forward a name query to a forwarder in London when there already is a suitable forwarder in New York. Where a Windows Server 2003 DNS server is configured with multiple conditional forwarder entries that have a similar root domain name, then when the DNS server received a name query that it has to forward to a forwarder, it will use the conditional forwarder entry with the longest matching domain namespace within the query. For example, there are three conditional forwarder entries created for a DNS server. These are for “Natsum.com.”, “A.Natsum.com.”, and “B.A.Natsum.com.”. The DNS server receives name query from a DNS client that contains the FQDN of

Page 194 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“host1.C.B.A.Natsum.com.”. The forwarder DNS server selected by this DNS server is the IP addresses within the conditional forwarder entry with the longest matching domain namespace entry within the submitted name query. In this example, it will be the designated forwarder for the “B.A.Natsum.com.” conditional forwarder entry on this DNS server. As discussed earlier, it is possible to disable recursion for an entire DNS server or, granularly for specific domain names or namespaces that are configured as conditional forwarder entries on a Windows Server 2003 DNS server. The granular disabling of recursion for specific domain names / namespaces produces a “forward-only” DNS server that does not attempt to resolve a name query using standard recursion should a configured forwarder for a conditional forwarder entry fail to resolve the name query. Note that a forward-only DNS server will generate a valuable cache of positive and negative name resolution attempts, that it will attempt to use prior to the use of forwarders or root hints. The technical configuration requirements for a forwarder include the ability to be able to forward a name query to an authoritative name server for a namespace / domain name within a namespace. The authoritative name server could be an external root DNS server (to resolve Internet or extranet (root server is, for example, within another organisation) namespaces) or an internal root DNS server that is authoritative for a one or more other namespaces within an organisation. Therefore, the technical requirements for a forwarder, depending upon its support functions, are:  If the forwarder is to resolve name queries for Internet namespaces, it will require a set of root hints, such as the default cache.dns file entries, pointing to one or more external root servers authoritative for Internet namespaces / DNS server for the ISP for an organisation  If the forwarder is to resolve name queries for internal namespaces, then it will require:  A conditional forwarder pointing to another internal root server that is authoritative for another internal namespace, or  A stub zone for a DNS zone that is authoritative for the target namespace within the name query  If the forwarder is to resolve name queries for a namespace within another organisation, then it will require:  A conditional forwarder pointing to an internal DNS server that is authoritative for the namespace within the other organisation, or  A conditional forwarder pointing to an internal root DNS server within the other organisation that is authoritative for the namespace within the other organisation, or  A stub zone for a DNS zone that is authoritative for the target namespace within the name query Using the above information, execute the following:  Determine and document the technical configuration requirements for conditional forwarder entries

Page 195 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the technical configuration requirements for forwarder entries  Determine and document the requirements for the design and deployment of a “forward-only” DNS server • Factor A56: Determination of the requirement for internal forwarder DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a name resolution strategy that employs name resolution pathways between DNS servers  Has determined the requirement for the use of forwarders and conditional forwarders (as configuration entries on one or more internal DNS servers)  Wishes to determine the requirements for the use of dedicated internal forwarder DNS servers ♦ Factor Considerations: Where it is possible to identify all of the above criteria for the application of this factor within an organisation, then consider the following information: The objectives for the use of internal forwarder DNS servers are to perform one of the following functions:  Internal inter-namespace name resolution (via conditional forwarder entries), or  External inter-namespace name resolution (via non-conditional or conditional forwarder entries), or  A combination of both internal and external inter-namespace name resolution When determining the requirements for one or more internal forwarder DNS servers, consider the following:  If an organisation has multiple internal DNS namespaces, managed within the boundaries of more than one DNS server infrastructure, then a dedicated forwarder can be used to bridge each DNS server infrastructure and thus the namespaces that reside within the boundaries of each DNS server infrastructure.  It is possible to configure the forwarder to support all internal name resolution requirements between all of the DNS server infrastructures it connects, and not just support the name resolution requirements of one DNS server infrastructure.  It is possible to use a dedicated forwarder DNS server to bridge the name resolution requirements from within an internal network out to the Internet. Using a dedicated forwarder DNS server can thus permit control over the path for name resolution traffic from within an organisation out to the Internet. Without any control over this path, it is possible for internal DNS servers, using root hints, to expose internal, and potentially sensitive, DNS data to the Internet.  With a dedicated forwarder DNS server, it is possible to exert control over access to the Internet from within an internal network, by positioning the forwarder DNS server within, for example, a firewall-partitioned network (DMZ) for an organisation.  The security benefits associated with this scenario compliment any requirements to control access to the Internet based upon restrictions on connection costs and / or available bandwidths for Internet network links. Channelling all name resolution requests through a dedicated forwarder DNS server thus permits control over the source of Internet-bound name resolution traffic.

Page 196 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 An advantage to the use of a dedicated forwarder DNS server is that, over a period, the server will develop a large cache of name resolutions. As DNS server will first attempt to resolve name queries received using any primary or secondary zones and its cache, where a cached entry is authoritative for the name query, this will negate the requirement to generate network traffic for name resolution, and thus reduce the time required to resolve name queries.  A strict internal forwarder DNS server, configured to handle outbound name queries only, will typically reside at the boundary of a DNS infrastructure. It hence should only receive name queries that are external to the DNS infrastructure, and not queries for resource records held within the DNS infrastructure. Thus, a strict internal forwarder DNS server, configured to handle outbound name queries only, will not require local DNS zones.  However, if there is a requirement for the internal forwarder DNS server to handle name queries originating externally to the internal DNS infrastructure, then it may require the local hosting and use of DNS zones.  A recommended configuration for this scenario is to use the “split DNS” solution. This solution involves the use of separate forwarder DNS servers within, for example, a partitioned network, or DMZ. One forwarder DNS server is dedicated for internal use only, and will hence only support name resolution queries received from internal clients. The other forwarder DNS server is dedicated for external use only, and will hence only support name resolution queries received from external clients on, for example, the Internet. The external forwarder DNS server will only host resource records pointing to, for example, other servers, and services exposed to the Internet, such as web servers, and portals.  Note that it is a security hazard to host local DNS zone data on a strict external forwarder DNS server, as compromise of this server from an external network would allow access to this sensitive data. See later for the security implications and considerations associated with the handling of name queries originating from a DNS client external to the internal DNS infrastructure, and the storage of DNS zone data on strict internal forwarder DNS servers. Use the above information to execute an analysis to determine and document the requirement for the use of internal forwarder DNS servers, to support internal and / or external inter-namespace name resolution. • Factor A57: Determination of the requirements for caching-only DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a name resolution strategy that employs name resolution pathways between DNS servers, and  Wishes to determine the requirements for the design and deployment of cachingonly DNS servers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A caching-only DNS server is the same as a standard DNS server with the one exception that a strict caching-only DNS server does not host any DNS zones at all. As a strict caching-only DNS server does not host any DNS zones, is not authoritative for any resource records. A caching-only DNS server instead supports name resolution queries via the use of its cache, configured forwarders and conditional forwarders, and / or configured root hints to an internal / external root DNS server.

Page 197 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

A strict caching-only DNS server (that has no forward or reverse lookup zones) hence:  Requires minimal server storage resources  May be installed and operated on any member server (does not require installation on a domain controller), and  Requires minimal management once configured. Consider the requirement for the design and deployment of a caching-only DNS server where it is possible to identify compliance with the following example criteria:  A DNS server is required to support a small number of DNS clients in a remote location connected by a low available bandwidth network link to other DNS servers. Also, the network bandwidth utilisation overheads (for an inter-location network link) associated with the requirement to replicate DNS zones hosted on a remote DNS server are prohibitive and would impact on the performance of other applications and users of the network link. However, as a strict caching-only DNS server will not host any secondary or stub DNS zones, there will be no requirement for frequent or occasional zone replication, respectively.  The overheads associated with server hardware costs (for a dedicated DNS server and storage requirements) are prohibitive / not feasible in relation to the number of DNS clients that the DNS server is to support. Configuration of the DNS server as a strict caching-only server, with no DNS zones, results in fewer utilisation requirements for hardware resources such as disk space (to store local DNS zone data), and network interfaces (to send and receive name queries to other DNS servers). Hence, it is feasible to install a caching-only DNS server on a server assigned a different primary role (such as a domain controller, a file and print server, and application server, and so on) which may utilise a large proportion of the server hardware resources such as CPU cycles, RAM, disk space and so on.  There is a requirement to support a few DNS clients that make infrequent name queries from within a small partition of a network infrastructure. The partitioned network infrastructure may be required to minimise inter-partition (for example, subnets) network traffic, and hence require the localisation of traffic where possible. Use of a local caching-only DNS server may hence assist in localising network traffic from name queries generated by the local DNS clients.  A caching-only DNS server, after a period of operation, will be able to resolve the majority of repeated name queries submitted by its DNS clients directly from cached entries. However, it is important to note that queries that cannot be resolved from the cache on this DNS server will be resolved via the use of forwarders / conditional forwarders or root hints to an internal root DNS server.  This requirement will hence generate network traffic within any network links between the caching-only DNS server and the forwarder / internal root DNS server, and thus the volume and frequency of this network traffic requires consideration.  There will be a decline in the volume and frequency of network usage by a cachingonly DNS server to resolve name queries over a period. However, the rate of decline depends upon the direction of the name queries received, the number of repeated and unique queries received, and the time to live values for cached entries. Using the above information, conduct an analysis to determine the following:  The requirements for the use of caching-only DNS servers within a DNS infrastructure  The potential locations where a caching-only DNS server may be implemented

Page 198 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor A58: Determination of the requirement for the use of stub zones ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of a name resolution strategy that employs name resolution pathways between DNS servers, and  Wishes to determine the requirements for the use of stub zones within a DNS infrastructure ♦ Factor Considerations: Where the criteria for the application of this factor can be identified within an organisation, then the following information should be considered A stub zone is a read-only copy of a zone that contains only resource records necessary to identify the authoritative DNS servers for that zone. Consider a stub zone to be similar to a delegated subdomain but created as a secondary zone. It is important to note that, firstly, the design concept for stub zones was not to replace the process of delegation for a subdomain, and secondly, Windows 2000 DNS does not support stub DNS zones. Stub zones function as a component of a name resolution strategy for intra-namespace name resolution down a namespace hierarchy. When determining the requirement for the use of stub zones:  Consider the use of stub zones where there is a requirement to reduce the number of referrals made by a client during an iterative query, and by a server during a recursive query from a client. Where a DNS namespace is considered to have a low ratio of parent domains to child domains, and hence primarily vertical in nature, then the use of stub zones can help to reduce the number of name queries that are required to be generated when resolving queries for child domains more than two or three layers deep.  Consider the use of stub zones where DNS servers hosting DNS zones for parent domains will receive frequent queries for host name to IP address resolution for hosts in child domain, this requires the use of stub zones for the child domains or the use of delegation records  Consider the use of stub zones on internal root DNS servers to permit their assistance in the routing of iterative name queries (received via root hints on internal DNS servers) for RRs in different namespaces.  Consider the use of stub zones where there is a requirement to keep resource records for delegated name servers up to date, with minimal manual intervention. The secondary zone characteristics of a stub zone permit zone updates from the primary zone, by zone transfer. However, note that it is not possible to configure a DNS notify list for stub zones, and instead it is necessary to update the stub zone manually by initiating a request for a zone transfer from the primary (master) zone.  When delegating sub-domains within a primary DNS zone, it is only possible to delegate to one domain level down. For example, within the primary DNS zone, “Natsum.com.”, it is possible to delegate authority for the “ChildA.Natsum.com.” domain (and corresponding DNS zone) to another DNS server. However, once done, it is not possible to delegate authority, within the primary DNS zone “Natsum.com.”, for a grandchild domain (e.g. “ChildB.ChildA.Natsum.com.”) because delegation is already in place for the “ChildA.Natsum.com.” namespace to another DNS server.

Page 199 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 In this scenario, an attempt to delegate an additional grandchild domain will display the following error message, as the DNS server will not write a name server record for the grandchild domain.

Figure 6.17: Windows Server 2003 DNS Error Dialog Box Generated When Attempting to Create a Grandchild Delegation  However, it is possible to create multiple stub zones on one DNS server for many child, grandchild, great grandchild (etc) domains, as they operate as independent zones. It is hence possible for one query to refer directly to a grandchild domain DNS zone without first referring to a child domain DNS zone, and hence the number of iterative and recursive queries are reduced. A stub zone will contain the following entries (as illustrated in figure 6.18 below):  Start of authority (SOA)  Name server (NS) resource records (RRs)  Glue (A) RRs (these records are used to glue zones together and provide an effective delegation and referral path for the other DNS servers to follow when resolving a name)  The IP address of one or more master DNS server to contact to update the stub zone record Note that, unlike the data for a secondary DNS zone, it is possible to store the data within a stub zone within an Active Directory application directory partition (ADP). Thus, dependent upon the scope of an ADP, the stub-zone data may be accessible by any DNS server installed on a domain controller. This hence includes server roles such as an internal root DNS servers that can take advantage of ADP-stored stub zone data for appropriate referrals without the requirement to host and replicate the stub zone data locally. The storage of stub zone data within an ADP also negates the requirement to establish a discrete replication topology for a stub zone of a primary DNS zone. Note that where stub-zone data (or primary DNS zone data) is stored within an ADP, there is still the requirement to create the DNS zone on the DNS server installed on a domain controller. Without the DNS zone, the DNS server will be unable to use the stub (or primary) zone, even though it is installed on a domain controller. Because of this requirement to create the DNS zones to access zone data stored within an ADP, a strict caching-only DNS server (with no zones at all) is not able to use ADPstored zone data for name resolution. The following illustrations depict the role of stub DNS zones within a Windows Server 2003 DNS infrastructure. These illustrations demonstrate the importance of the continued use of delegation even where stub zones are used (figures 6.18 and 6.19), and how stub zones can reduce the number of iterative and recursive queries made (figures 6.20, 6.21, and 6.22) by DNS clients and servers respectively:

Page 200 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“.”

Step 2: Referral to DNSServer3 as NS for ChildA zone

Client

“com.”

Step1: Client wishes to resolve Host3 to IP address to access \\Host3.ChildA.Natsum.com\ share and sends iterative query to DNSServer2.natsum.com

2

5

“Natsum.com.”

1

Step 5: Client accesses files in \\Host3.ChildA.Natsum.com\ share

DNSServer1

DNSServer2

ZONE TRANSFER
Primary Zone for Natsum.com: @ IN SOA DNSServer1. admin. ... ; Zone NS records @ NS DNSServer1.Natsum.com @ NS DNSServer2.Natsum.com ; Delegated sub-zone : ChildA NS DNSServer3.Natsum.com ; End Delegation ; Zone records DNSServer1 A 192.168.2.55 DNSServer2 A 192.168.2.56 DNSServer3 A 192.168.2.57 Secondary Zone for Natsum.com: @ IN SOA DNSServer2. admin. ... ; Zone NS records @ NS DNSServer1.Natsum.com @ NS DNSServer2.Natsum.com ; Delegated sub-zone : ChildA NS DNSServer3.Natsum.com ; End Delegation ; Zone records DNSServer1 A 192.168.2.55 DNSServer2 A 192.168.2.56 DNSServer3 A 192.168.2.57

Host3 192.168.2.157

ChildA.Natsum.com

DNSServer3

4

Step 4: DNSServer3 returns IP address for Host3.ChildA.Natsum.com 192.168.2.157

3

Step 3: Query to DNSServer3 for: IP address for Host3.ChildA.Natsum.com

© 2 0 0 4 MU S T A N S H I

R

BHAR

MAL

Primary Zone for ChildA.Natsum.com: @ IN SOA DNSServer3. admin. ... ; Zone NS records @ NS DNSServer3.Natsum.com ; Zone records Host1 A 192.168.2.155 Host2 A 192.168.2.156 Host3 A 192.168.2.157

Figure 6.18: Illustration of DNS Zone Delegation from within the Primary Zone for “Natsum.com.” to “ChildA.Natsum.com.”, Hosted on DNSServer3 The delegated zone record that is within the primary zone file transfers, by zone transfer, to a secondary zone for “Natsum.com.” hosted on DNSServer2. Hence, DNSServer2 is aware of the fact that DNSServer3 is authoritative for the DNS zone for the domain “ChildA.Natsum.com.”.

Page 201 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“.”

DNSServer2 returns error as has no knowledge of DNS domain “ChildA”

Client

“com.”

Step1: Client wishes to resolve Host3 to IP address to access \\Host3.ChildA.Natsum.com\ share and sends iterative query to DNSServer2.natsum.com

2

“Natsum.com.”

1
Client cannot contact host3.childa.natsum.com

DNSServer1

DNSServer2

ZONE TRANSFER
Primary Zone for Natsum.com: @ IN SOA DNSServer1. admin. ... ; Zone NS records @ NS DNSServer1.Natsum.com @ NS DNSServer2.Natsum.com ; Zone records DNSServer1 A 192.168.2.55 DNSServer2 A 192.168.2.56 DNSServer3 A 192.168.2.57

Host3.ChildA.Natsum.com. 192.168.2.157

Secondary Zone for Natsum.com: @ IN SOA DNSServer2. admin. ... ; Zone NS records @ NS DNSServer1.Natsum.com @ NS DNSServer2.Natsum.com ; Zone records DNSServer1 A 192.168.2.55 DNSServer2 A 192.168.2.56 DNSServer3 A 192.168.2.57

Stub Zone for ChildA.Natsum.com: @ IN SOA DNSServer3. admin. ... ; Zone NS records @ NS DNSServer3.Natsum.com DNSServer3.Natsum.com A 192.168.2.57

Start of Authority record for this Stub zone Name Server Records for this Stub zone Glue (A) resource record for this Stub zone

ZONE TRANSFER ChildA.Natsum.com
DNSServer3

Primary Zone for ChildA.Natsum.com ; Zone NS records @ NS DNSServer3.Natsum.com ; Zone records Host1 A 192.168.2.155 Host2 A 192.168.2.156 Host3 A 192.168.2.157

© 2004 MU STANSHI R BHAR MAL

Figure 6.19: Illustration of DNS Stub Zone Use DNSServer1 has a stub zone configured for the DNS zone “ChildA.Natsum.com.” and hence has knowledge of the DNS domain “ChildA.Natsum.com.”, and the name server for that zone (DNSServer3). In the above illustration, as DNSServer1 does not have a delegation for the “ChildA.Natsum.com.” sub-zone configured within the primary zone for “Natsum.com.”, DNSServer2 has no information about this sub-domain for “Natsum.com.” via the zone transfer for this primary zone. Thus, a client for DNSServer2 wishing to locate a host in the “ChildA.Natsum.com.” domain will not be able to receive a referral to DNSServer3. The options to resolve this scenario would be to either create a delegation for “ChildA.Natsum.com.” within the “Natsum.com.” primary zone and hence transfer this to the appropriate secondary zone on DNSServer2, or create another stub zone on DNSServer2 for the “ChildA.Natsum.com.” domain. The first option is viable where transfers from the primary zone “Natsum.com.” take place to many other DNS servers within the DNS infrastructure supporting the “Natsum.com.” namespace.

Page 202 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

However, where zone transfers of the “Natsum.com.” zone are only to one or two other DNS servers, then it may be feasible to create stub zones on these DNS servers for the “ChildA.Natsum.com.” zone. Note: A stub zone (unlike a secondary zone) cannot become a master zone and allow zone transfers of that zone to a secondary zone on a different DNS server.
Step1: Client wishes to resolve Host3.ChildC.ChildB.ChildA.Natsum. com to an IP address to access \\Host3\share and sends iterative query to DNSServer1.Natsum.com Step2: DNSServer1 sends a referral to the client to DNSServer2 via delegation record for ChildA.Natsum.com Client Step 9: Client contacts Host3.ChildC.ChildB.ChildA. Natsum.com to access the required resources on this host

“.” “com.”

1 2
3
Step 3: Client sends query to DNSServer2 for IP address for Host3.ChildC.ChildB. ChildA.Natsum.com

9
Host3.ChildC.ChildB.ChildA.Natsum.com. 192.168.2.157

“Natsum.com.”

DNSServer1

4

5
Primary Zone for Natsum.com: @ IN SOA DNSServer1. admin. ... ; Zone NS records @ NS DNSServer1.Natsum.com ; Delegated sub-zone : ChildA NS DNSServer2.Natsum.com ; End Delegation ; Zone records DNSServer1 A 192.168.2.55 DNSServer2 A 192.168.2.56 DNSServer3 A 192.168.2.57 DNSServer4 A 192.168.2.58 Step 4: DNSServer2 sends a referral to the client to DNSServer3 via delegation record for ChildB.Natsum.com Step 5: Client sends query to DNSServer3 for IP address for Host3.ChildC.ChildB. ChildA.Natsum.com

Step 8: DNSServer4 sends client IP address for Host3.ChildC. ChildB.ChildA. Natsum.com

6

7

8

DNSServer2

ChildA.Natsum. com

Primary Zone for ChildA.Natsum.com ; Zone NS records @ NS DNSServer2.Natsum.com ; Delegated sub-zone : ChildB NS DNSServer3.Natsum.com ; End Delegation ; Zone records Host1 A 192.168.2.155

Step 6: DNSServer3 sends a referral to the client to DNSServer4 via delegation record for ChildC.Natsum.com DNSServer3

ChildB.ChildA. Natsum.com

Step 7: Client sends query to DNSServer4 for IP address for Host3.ChildC.ChildB. ChildA.Natsum.com

Primary Zone for ChildB.ChildA.Natsum.com ; Zone NS records @ NS DNSServer3.Natsum.com ; Delegated sub-zone : ChildC NS DNSServer4.Natsum.com ; End Delegation ; Zone records Host2 A 192.168.2.156

DNSServer3

ChildC.ChildB. ChildA.Natsum.com

© 2004 MUS TANS HI

R

BHAR

MAL

Primary Zone for ChildC.ChildB.ChildA.Natsum.com ; Zone NS records @ NS DNSServer4.Natsum.com ; Zone records Host3 A 192.168.2.157

Figure 6.20: Example of Normal Iterative Name Resolution Query This query uses delegation records on DNS servers, which requires a client to make four name queries before receiving the required IP address.

Page 203 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Step 1: Client wishes to resolve Host3.ChildC.ChildB.ChildA.Natsum.com to an IP address to access \\Host3\share and sends iterative query to DNSServer1.Natsum.com

Step 2: DNSServer1 sends a referral to the client to DNSServer2 via delegation record for ChildA.Natsum.com

“.” “com.”

1 2 9
Client

Step 10: Client contacts Host3.ChildC.ChildB.ChildA. Natsum.com to access the required resources on this host

10
“Natsum.com.”
DNSServer1 Host3.ChildC.ChildB.ChildA.Natsum.com. 192.168.2.157 Step 9: DNSServer1 sends client IP address for Host3.ChildC.ChildB.Child A.Natsum.com

Primary Zone for Natsum.com: @ IN SOA DNSServer1. admin. ... ; Zone NS records @ NS DNSServer1.Natsum.com ; Delegated sub-zone : ChildA NS DNSServer2.Natsum.com ; End Delegation ; Zone records DNSServer1 A 192.168.2.55 DNSServer2 A 192.168.2.56 DNSServer3 A 192.168.2.57 DNSServer4 A 192.168.2.58 DNSServer2

3

4

6

5

DNSServer3

7

8

DNSServer3

ChildA.Natsum. com

ChildB.ChildA. Natsum.com

ChildC.ChildB. ChildA.Natsum.com

Primary Zone for ChildA.Natsum.com ; Zone NS records @ NS DNSServer2.Natsum.com ; Delegated sub-zone : ChildB NS DNSServer3.Natsum.com ; End Delegation ; Zone records Host1 A 192.168.2.155

Primary Zone for ChildB.ChildA.Natsum.com ; Zone NS records @ NS DNSServer3.Natsum.com ; Delegated sub-zone : ChildC NS DNSServer4.Natsum.com ; End Delegation ; Zone records Host2 A 192.168.2.156

Primary Zone for ChildC.ChildB.ChildA.Natsum.com ; Zone NS records @ NS DNSServer4.Natsum.com ; Zone records Host3 A 192.168.2.157

© 2004 MUS

T ANS HI R

BH

AR MA L

Figure 6.21: Example of Normal Recursive Name Resolution In this example, the DNS server sends iterative queries to other DNS servers, on behalf of the DNS client, and thus is the only DNS server the client needs to contact. In this example, the client needs to make only one recursive name query, but the DNS server first contacted (DNSServer1) needs to make three iterative name resolution queries on behalf of the client.

Page 204 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“.” “com.”

1

Step 1: Client wishes to resolve Host3.ChildC.ChildB.ChildA.Natsum. com to an IP address to access \\Host3\share and sends iterative query to DNSServer1.Natsum.com Client

Step 5: Client contacts Host3.ChildC.ChildB.ChildA. Natsum.com

5
Host3.ChildC.ChildB.ChildA.Natsum.com. 192.168.2.157

“Natsum.com.”

2
Step 2: DNSServer1 sends a referral to the client directly to DNSServer4 via referencing the stub zone for ChildC.ChildB.ChildA.Natsum .com Step 3: Client sends query to DNSServer4 for IP address for Host3.ChildC.ChildB.ChildA.Natsum.com

Step 4: DNSServer3 returns IP address for Host3.ChildC.ChildB.ChildA. Natsum.com 192.168.2.157

DNSServer1

Primary Zone for Natsum.com: @ IN SOA DNSServer1. admin. ... ; Zone NS records @ NS DNSServer1.Natsum.com ; Zone records DNSServer1 A 192.168.2.55 DNSServer2 A 192.168.2.56 DNSServer3 A 192.168.2.57 DNSServer4 A 192.168.2.58

4
DNSServer2

ChildA.Natsum. com

3

Zone Transfer
Stub Zone for ChildA.Natsum.com: @ IN SOA DNSServer2. admin. ... ; Zone NS records @ NS DNSServer2.Natsum.com DNSServer2.Natsum.com A 192.169.2.56 Primary Zone for ChildA.Natsum.com ; Zone NS records @ NS DNSServer2.Natsum.com ; Delegated sub-zone : ChildB NS DNSServer3.Natsum.com ; End Delegation ; Zone records Host1 A 192.168.2.155

DNSServer3

ChildB.ChildA. Natsum.com

Zone Transfer
Stub Zone for ChildB.ChildA.Natsum.com: @ IN SOA DNSServer3. admin. ... ; Zone NS records @ NS DNSServer3.Natsum.com DNSServer3.Natsum.com A 192.169.2.57 Primary Zone for ChildB.ChildA.Natsum.com ; Zone NS records @ NS DNSServer3.Natsum.com ; Delegated sub-zone : ChildC NS DNSServer4.Natsum.com ; End Delegation ; Zone records Host2 A 192.168.2.156

DNSServer3

ChildC.ChildB. ChildA.Natsum.com

Zone Transfer
Stub Zone for ChildC.ChildB.ChildA.Natsum.com: @ IN SOA DNSServer4. admin. ... ; Zone NS records @ NS DNSServer4.Natsum.com DNSServer4.Natsum.com A 192.169.2.57 Primary Zone for ChildC.ChildB.ChildA.Natsum.com ; Zone NS records @ NS DNSServer4.Natsum.com ; Zone records Host3 A 192.168.2.157
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.22: Example of an Iterative Query from a Client to a DNS Server In this example, the DNS server (DNSServer1) has stub zones for each of the three child domains (ChildA, ChildB, and ChildC). Using the stub zone records, DNSServer1 is able to refer the iterative name query from the DNS client directly to DNSServer4. This hence, for this example, halves the number of name resolution queries that the client has to create and send in order to receive the IP address for the target host, Host3. Using the above information and examples, execute the following:  Determine and document the requirements for the use stub zones, identifying the reasons to justify their design and deployment within a DNS infrastructure  Determine and document the DNS zones to be duplicated on other DNS servers as stub zones as a component of a name resolution strategy  Identify, where possible, the DNS servers that would be suited to host stub zones

Page 205 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

5.9.6.1.3.

Determination of the Design Requirements for the DNS Zones

Consider the following information when determining the design requirements for the DNS zones to support the defined scope of the Active Directory infrastructure: • Factor A59: Determination of the requirements to partition a DNS namespace into multiple DNS zones ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for one or more DNS namespaces, and  Wishes to determine the requirements for the partitioning of a DNS namespace into multiple DNS zones ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A DNS zone is a contiguous portion of a DNS namespace that is authoritative for all resource records aligned to that portion of the DNS namespace. A DNS zones does not necessarily have to conform to the entire DNS namespace or only a single domain within the namespace, but can encompass multiple domains within a namespace, as long as they are contiguous. Delegation is the term used for the process of partitioning a DNS namespace into multiple DNS zones. The potential for the partitioning of a DNS namespace is dependent upon the vertical and horizontal depth and breadth of the DNS namespace. Using the ratio of parent domains to child domains, a DNS namespace may be classed as either horizontal (a high ratio of parent domains to child domains), or vertical (a low ratio of parent domains to child domains). In the following illustrations, it is possible to partition the depicted DNS namespace into one DNS zone, or multiple DNS zones via the delegation of subdomains:
“.”

“com.”

“A.com.”

B.A.com.

C.A.com.

D.B.A.com.

E.C.A.com.
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 6.23: Example of a DNS Namespace with Four Layers

Page 206 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“.”

“com.”

“A.com.”

B.A.com.

C.A.com.

D.B.A.com.

E.C.A.com.

© 2004 MUSTANSHI

R

BHAR

MAL

Figure 6.24: Example of a Single Zone for a DNS Namespace with Four Layers In this example, the DNS zone “A.com.” is authoritative for all resource records held within “A.com.” and all subdomains of “A.com.”
“.” Delegated Sub-Domains

“com.”

“A.com.”

B.A.com.

C.A.com.

D.B.A.com.

E.C.A.com.

© 2 0 0 4 MU S TA NSH I

R

BHAR

MAL

Figure 6.25: Example of a Delegated DNS zone (“A.com.”) Note that it is possible to represent the delegated DNS subdomains as DNS zones on the same DNS server, but most organisations will host these delegated zones on different DNS servers within a DNS infrastructure for an organisation. When determining the requirements for the delegation of a multiple domain DNS namespace into subdomains and respective DNS zones, this design methodology provides the following example criteria to qualify the use of delegation:  There is a requirement to permit autonomous management by a division for a subdomain / contiguous portion of a DNS namespace that will support a corresponding forest / tree / domain infrastructure owned by that division.  There is a requirement to distribute a subdomain, or a contiguous portion of a DNS namespace, to multiple DNS servers within a DNS infrastructure. The DNS servers could support, for example, one or more geographical locations, where the DNS namespace supports locally represented components of an Active Directory infrastructure.  The depth of a DNS namespace will influence the requirement to delegate subdomains within the namespace. Delegate vertical namespaces where it is not

Page 207 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

possible to allow full replication of an entire namespace across all DNS servers, based upon the potential impact on the network infrastructure from the replication traffic.  There is a requirement to map the DNS namespaces to the subnet component of the TCP/IP architecture for an organisation and then delegate management of domains within a DNS namespace based upon the boundaries for the subnets. For example, a network infrastructure containing one or a collection of TCP/IP subnets supports each Active Directory domain. The onus on subnet management lies with the respective domain owners, and hence, delegated DNS domains from a DNS namespace permit the concurrent management of the DNS zones for that domain and all TCP/IP addresses used within that DNS zone.  There is a requirement to map the DNS namespaces to the Site infrastructure for an Active Directory forest, and delegate management of domains within a DNS namespace based upon the boundaries of the Sites and the subnets held within each Site. Note that this approach requires that the boundary for a Site entirely encompass one or more domains represented within a DNS namespace for an Active Directory infrastructure. Where this is the case, it is possible to delegate the corresponding DNS domains into DNS zones for representation and management by domain owners within a Site. The delegation of a DNS namespace into multiple subdomains and corresponding DNS zones supports:  The distribution of administrative tasks in an organisation with a decentralised IT administration model  The load balancing and localisation of name resolution traffic between DNS clients and DNS servers Partitioning of a DNS namespace into multiple zones, logically and physically distributed amongst multiple DNS servers, can assist in the reduction of broadcast traffic between local subnets. However, partitioning of DNS namespaces can increase local client-server and server-server network traffic. The impact of this requires assessment, especially where DNS traffic will cross routers on an internal network infrastructure. Where the scope for partitioned DNS network traffic will cross high latency or WAN links, consider the impact of the following types of DNS traffic upon these network links:  Client to server DNS traffic generated for iterative name queries and dynamic updates to zone databases  Server to server DNS traffic generated for zone transfers, iterative and recursive name queries, use of WINS lookup, dynamic updates from a DHCP server, and so on The delegation of a domain or contiguous portion of a DNS namespace within a parent domain creates name server record within the parent DNS zone. The name server record points to a DNS server that will host the delegated domain or contiguous portion of a DNS namespace. Hence, if the DNS server hosting the parent zone receives a name resolution query for a host with a fully qualified domain name within a delegated subdomain of a DNS namespace, the DNS server will create a referral for the resolver to the appropriate name server that is authoritative for the delegated subdomain / contiguous portion of a DNS namespace. Where there is a requirement to use WINS lookup to resolve the host name component of a FDQN that is not stored within a DNS zone database, but is instead stored within

Page 208 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Windows 2000 / Windows Server 2003 WINS database, then a multiple domain DNS zone must be partitioned into multiple DNS zones. A Windows 2000 / Windows Server 2003 WINS server relies upon a resolver to append a domain namespace, whilst the WINS server only resolves the host name. It is only possible to create a WINS lookup resource record within the root of a DNS zone and hence it does not apply to sub-domains within a DNS zone. For example, a DNS zone, “Natsum.com.”, (with a sub-domain of “A.Natsum.com.”), is configured to use WINS lookup. The WINS server has an entry (static or automatic) for a computer named Host1, which does not have a corresponding entry within the DNS server infrastructure. A name query sent to a DNS server, authoritative for the “Natsum.com.” DNS zone, to resolve a FQDN of “Host1.Natsum.com.” will be successfully resolved, via the WINS server. However, a name query sent to resolve a FQDN of “Host1.A.Natsum.com.” would fail to be resolved. If, however, the sub-domain “A.Natsum.com.” was partitioned into a separate DNS zone (with an appropriate delegation within the “Natsum.com.” zone), and this new DNS zone was configured to use WINS lookup, then the name query for “Host1.A.Natsum.com.” would be successful resolved via the WINS server. Using the above information and examples, execute the following:  Determine and document the DNS namespaces to be partitioned into two or more DNS zones, and the reasons to justify the partitioning of the namespace into multiple DNS zones  Determine and document the DNS zones to be further partitioned into sub zones, and the reasons to justify the delegation of child domains within a zone into multiple independent zones  Determine and document the total number of DNS zones required for each DNS namespace • Factor A60: Determination of the types of DNS zones required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to design a DNS infrastructure to support the defined scope of the Active Directory infrastructure, and  Wishes to determine the types of zones required for design and implementation within the DNS infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Most DNS server software currently in use will support, at a minimum, primary and secondary DNS zones. However, within a Windows Server 2003 DNS server infrastructure, it is possible to create the following three types of DNS zones on a DNS server:  A primary forward or reverse lookup zone  A secondary forward or reverse lookup zone  A stub forward or reverse lookup zone (see “determination of the design requirements for a name resolution strategy” for the considerations in the use of stub zones)

Page 209 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Forward lookup zones provide name resolution services where the IP address for a host is required based upon a supplied host name, alias name, service locator name, GUID, and so on that will match a resource record within a zone. Most DNS clients and applications require the name resolution services provided by forward lookup zones. Reverse lookup zones provide name resolution services where the name of a host is required based upon a supplied IP address for the host by a client or an application. The design and deployment of reverse lookup zones are strictly optional and not required within a DNS infrastructure to support the defined scope of the Active Directory infrastructure. When determining the requirement for the use of reverse lookup zones, consider, for example, the requirement by applications to perform security checks where a server will grant access to a client based upon client host names. When a client contacts a server and requests access, the server can request a name resolution of the IP address presented to the server by a client to a host name for the client. Where the host name matches the access control entry, the server may grant access to the client. There may also be a requirement for reverse lookup zones to support the use of common troubleshooting tools, such as the command line tool nslookup.exe. This tool uses reverse lookup zones to perform name resolution queries against given IP addresses. A primary DNS zone is a writeable zone that can be authoritative for the resource records held within the database for the zone. The writeable nature of a primary zone implies a greater management and server hardware resource overhead than for a readonly zone such as a secondary or stub zone. A secondary DNS zone is a read-only copy of a primary DNS zone. The standard process of zone transfer keeps the secondary zone up to date with the source primary zone. The functions of secondary zones are to reduce the overheads on a DNS server hosting a primary zone and localise name resolution traffic, by allowing a DNS server hosting a secondary zone to respond authoritatively to name resolution requests from local DNS clients. Using the above information, determine and document the requirements for the use of forward and reverse lookup primary and secondary DNS zones. See later, within the factor that discusses zone replication, for the considerations for the use of secondary DNS zones. • Factor A61: Determination of the design requirements for DNS zone database storage ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design a DNS infrastructure to support the defined scope of the Active Directory infrastructure, and  Wishes to determine the design requirements for the storage of DNS zone data ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Most DNS server software currently in use will only permit the storage of DNS zone data as flat text files. However, a Windows Server 2003 DNS infrastructure supports the following four options for the storage of DNS zone data (assuming an Active Directory infrastructure is present):  Storage within flat DNS text files suffixed with “.dns”

Page 210 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Storage within default Windows Server 2003 Active Directory application directory partitions (ADPs) for the DNS server application  Storage within custom Windows Server 2003 Active Directory application directory partitions (ADPs) within a forest  Storage within the legacy Active Directory location (within the domain partition, in the “cn=MicrosoftDNS,cn=System” container) and hence replicated to all domain controllers within the domain. This option also provides backward support for legacy Windows 2000 DNS servers operating on Windows 2000 domain controllers (in a “Windows 2000 mixed” or “Windows 2000 native” functional-level domain). All DNS zones (primary, secondary, and stub) can be stored as standard DNS text files. The default location for these files is in the “%systemroot%\system32\dns\” folder on a Windows Server 2003 DNS server. The use of the standard text files with Windows Server 2003 DNS server software is associated with the following advantages:  Dynamic updates to a primary zone held as a text file are written as fast as to transaction log files, but do not require further writing to the Active Directory database file  There is an associated reduction in the hardware resource utilisation of the DNS server  It is possible to install the DNS server service on any Windows Server 2003 member server and does not require installation on a domain controller The use of the standard text files with Windows Server 2003 DNS server software is associated with the following disadvantages:  A limitation in the scope of queries to the text files. If the zone data was stored in the Active Directory, non-DNS clients using LDAP can query the data. It is only possible for a DNS server to query the DNS zone data held within a text zone file, or for a query to be made via a direct interaction with the text zone file  A DNS zone stored as a text file is inherently less secure than stored within the Active Directory infrastructure for an organisation. Each entry within a DNS zone stored within the Active Directory is created as an object, and hence receives a default security descriptor  Replication of a text zone file would use an additional replication topology to Active Directory replication. Only a single replication topology is required for a DNS zone stored in the Active Directory. It is possible to create two DNS application directory partitions within a Windows Server 2003 Active Directory forest. Note that it is only possible for Windows Server 2003 DNS servers, installed on domain controllers within a Windows Server 2003 Active Directory infrastructure, to utilise the DNS zone data stored within these DNS application directory partitions. These DNS application directory partitions are:  ForestDNSZones (DN is: DC=ForestDNSZones,DC=<forest_root_domain_name>)  DomainDNSZones (DN is: DC=DomainDNSZones,DC=<domain_name>) When the first Windows Server 2003 DNS server starts up within a Windows Server 2003 Active Directory forest, it will attempt to automatically create these partitions, using the context of the logged on user account. Successful creation of these

Page 211 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

application directory partitions relies upon membership of the Enterprise Admins group in the forest root domain. It is possible to disable the automatic creation of these two DNS application directory partitions by disabling the following registry key on each Windows Server 2003 DNS server:  Key Name: EnableDirectoryPartitions  Key: “HKLM\System\CurrentControlSet\Services\DNS\Parameters”  Type: REG_DWORD  Value: 0x0  Valid Range: 0x0 (disable) and 0x1 (enable). Note that it is also possible to use the command line tool, DnsCmd, to create the default DNS partitions within an Active Directory forest using the following switch: “DnsCmd <DNS Server Name> /CreateBuiltinDirectoryPartitions <Option>” The option for this switch must be one of the following three:  /Domain - Creates the built-in domain-wide DNS directory partition for the Active Directory domain where the DNS server specified by Server Name is located.  /Forest - Creates the built-in forest-wide DNS directory partition for the Active Directory forest where the DNS server specified by Server Name is located.  /AllDomains - Creates the built-in domain-wide DNS directory partitions in each domain in the Active Directory forest hosting the user account for the user running this command. This operation ignores the Server Name argument. The selection of the required DNS application directory partition (ADP) for the storage of the records within a DNS zone depends upon the required scope for use of the DNS zone resource records. If the DNS zone data is to be available to all of the DNS servers operating on domain controllers within the forest, then the DNS zone data may be stored in the “ForestDNSZones” application directory partition. If the DNS zone data is to be available to all of the DNS servers operating on domain controllers within the forest, then the DNS zone data may be stored in the “DomainDNSZones” application directory partition. Note that if there is the requirement to support Windows 2000 DNS servers running on Windows 2000 domain controllers within a Windows Server 2003 Active Directory infrastructure, then the DNS zone data can be stored in the legacy Active Directory location of the domain partition. Note that this is the default Active Directory storage option presented by the “New Zone Wizard” following the selection of the option to create a primary or stub Active Directory-integrated zone, when the domain in which the DNS server resides is either in the “Windows 2000 mixed” or in the “Windows 2000 native” domain functional-level. After raising the functional-level for a domain to “Windows Server 2003”, this option is still available for selection, but not presented as the default option by the “New Zone Wizard”. The legacy Active Directory domain partition location, for example, in the “Natsum.com.” domain, for storage of the DNS data is within the “MicrosoftDNS”

Page 212 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

container, within the “System” container for the domain (distinguished name: “cn=MicrosoftDNS,cn=System,dc=Natsum,dc=com”). However, the scope of replication of the DNS zone data stored here is to all domain controllers (Windows Server 2003 and Windows 2000) within the domain, and not just the DNS servers (running on Windows Server 2003 domain controllers) within the domain (scope of the “DomainDNSZones” application directory partition) or the forest (scope of the “ForestDNSZones” application directory partition). Only primary and stub DNS zones can be stored within either the default or custom DNS application directory partitions for a Windows Server 2003 Active Directory forest, or in the legacy (domain) partition. Note that the storage of primary DNS zone data within an Active Directory default of custom DNS ADP creates fault-tolerance for zone updates. A primary DNS zone stored in flat text files may only be updated on a single DNS server, which then notifies (where configured) all other secondary DNS servers (where configured) of the updates to the zone. Failure of this one DNS server that hosts the primary DNS zone may lead to delays in zone updates and so on. However, when a primary DNS zone is stored within an Active Directory ADP, any DNS server installed on a domain controller within the replication scope of the ADP may update the DNS zone. When using stub zones configured to store their data within an Active Directory ADP, consider the update requirements for the stub zones where multiple masters for the stub zone exist within a DNS infrastructure. For example, an administrator creates a stub zone for a DNS zone, “Natsum.com.” from one of three master DNS servers for this zone. The data for the stub zone is stored within an Active Directory ADP. DNS servers in two geographically remote locations (London and New York) load the stub zone from the Active Directory ADP. Each location contains one of the master DNS servers for the DNS zone “Natsum.com.”. The list of master servers for the stub zone is stored within the stub zone data, and hence, it is feasible for a DNS server in London that hosts the stub zone to attempt to retrieve updates for the stub zone from a master server in New York, and not the master server in London. Hence, to localise the updates to the stub zone, it is possible to configure a local list of master servers for a locally hosted stub zone, via the selection of the checkbox “Use the above list as a local list of masters” on the General tabbed page of the Properties dialog box for the stub zone. This list will override the list of master servers for the stub zone stored within the Active Directory. However, the DNS server retains, in memory, the list of master servers stored within the Active Directory in case an administrator clears the checkbox. The use of the default DNS ADPs for zone data storage is associated with the following advantages:  Where DNS zone data is stored within either the “ForestDNSZones” or the “DomainDNSZones” ADP, the Global Catalog for the forest does not hold any copies of this data. This hence minimises the replication overhead associated with the integration of DNS within the Active Directory.  If the scope for the use and replication of a DNS zone is limited to DNS servers within the domain or a forest, and the appropriate DNS ADP is used, there is no requirement to configure and manage zone transfers between the DNS servers for a particular DNS zone.

Page 213 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Replication of the DNS zone data between the DNS servers within the scope of the default ADP uses the Active Directory replication topology. Hence, there is not requirement to design a parallel DNS replication topology and there is no extra replication traffic between the DNS servers. The use of the default DNS ADPs for zone data storage is associated with the following disadvantages:  The DNS servers must operate on Windows Server 2003 domain controllers and cannot operate on Windows Server 2003 member servers or Windows 2000 domain controllers  Corruption of a DNS ADP will result in the failure of the DNS server service and unavailability of DNZ zone data for all zones stored within the ADP. To avoid this scenario, take the precaution of performing zone transfers out of the ADP to secondary zones stored as flat DNS text files on one or more other DNS servers within the organisation.  The Active Directory represents every resource record within a DNS zone stored within an ADP as an object. Hence, each resource record within ADP will occupy a larger amount of disk space than a corresponding single line entry within a text file for a DNS zone. This may become significant where there are many thousands of resource records for a DNS zone. It is possible to create custom ADPs within an Active Directory forest to store DNS zone data. To create custom ADPs, it is necessary to use the security context for a user account that is either a member of the Enterprise Admins group of the forest root domain, or has been delegated the appropriate rights and permissions. (See the Forest Plan process, “design Application Directory Partitions within a forest”, for details). It is possible to use the command line tool, dnscmd, to create custom ADPs for the DNS server service, using the following switch: “DnsCmd <DNS Server Name> /CreateDirectoryPartition <FQDN of Partition>” Note that when creating the custom DNS application directory partition using this command line tool, omit the “dc=” prefix for the name of the application directory partition. Note that it is possible for a custom ADP to hold the DNS zone data for multiple zones. The use of a custom ADP to store DNS zone data is associated with the following advantages:  It is possible to replicate the DNS zone data to only a specific set of Windows Server 2003 domain controllers that operate the DNS server service. The scope of replication is limited to the forest boundary, but, unlike the default DNS “DomainDNSZones” and “ForestDNSZones” ADPs, it does not necessarily require replication to all domain controllers within the domain or forest, respectively.  Similar to the default DNS application directory partitions, DNS zone data held within a custom DNS application directory partition is not replicated to the Global Catalog for the forest, thus reducing unnecessary replication traffic and data storage requirements for Global Catalog servers.  The use of a custom ADP to store DNS zone data is suitable for small DNS zones dedicated for the use of localised directory-enabled applications and services that require DNS name resolution services or can use LDAP to make direct queries to the ADP.

Page 214 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The use of a custom ADP to store DNS zone data is associated with the following advantages:  There is an administrative overhead associated with a custom ADP where the replication scope may change on a frequent basis. The removal or addition of domain controllers within a domain or forest automatically updates the replication scope for a DNS zone that has its data stored within a domain or forest DNS ADP.  The DNS zone data is only accessible by Windows Server 2003 DNS servers operating on Windows Server 2003 domain controllers.  Because a custom ADP can hold the zone data for multiple DNS zones, all zones stored within a single custom ADP would share the same replication topology defined for the custom ADP.  The Active Directory represents every resource record within a DNS zone stored within an ADP as an object. Hence, each resource record within ADP will occupy a larger amount of disk space than a corresponding single line entry within a text file for a DNS zone. This may become significant where there are many thousands of resource records for a DNS zone. The scope for use, integration, replication, and the fault tolerance requirements for a DNS zone, will influence the choice of the DNS zone storage option. For example, where all DNS servers within a forest operate on domain controllers and all DNS servers require a copy of a DNS zone, then it would be simpler to store the DNS zone data in the default “ForestDNSZones” ADP. Where, for example, a DNS zone has a very specific scope for use, and fault tolerance of the DNS zone is required, then it may be simpler to store the DNS zone data as standard DNS text files and allow zone transfers between the required DNS servers. Alternatively, it is possible to create a custom ADP to store the DNS zone data. Where for example, integration is required between legacy (Windows 2000) or third party (e.g. BIND) DNS servers and Windows Server 2003 DNS servers, then the use of standard DNS text files to store DNS zone data is preferable. Using the above information and examples, execute the following:  Determine and document the required DNS zone database storage options for all DNS servers within the scope of this process  Determine and document the requirements for the use of any default or custom DNS application directory partitions for the storage of DNS zone data  Determine and document the requirements to support Windows 2000 DNS servers operating on Windows 2000 domain controllers that require access to Active Directory-integrated DNS zones, and hence requires the storage of the DNS zones within the legacy “dc=MicrosoftDNS,dc=System,dc=<domain>,dc=<domain>”.  Determine and document the requirements for the use of local lists of master DNS servers for Active Directory-integrated stub zones • Factor A62: Determination of the design requirements for the creation and population of primary DNS zones ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the creation and population of primary DNS zones for the DNS infrastructure

Page 215 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to either manually create a primary DNS zone, to support an Active Directory domain, or use the Active Directory Installation Wizard (DCPROMO) to create the zone automatically. This design methodology strongly recommends that where there is no existing DNS infrastructure then the Active Directory Installation Wizard (DCPROMO) automatically install and configure a local DNS server and zone to support the Active Directory domain. Select this option within the “DNS Registration Diagnostics” page for the Active Directory Installation Wizard. Using the DNS client configuration for the server running DCPROMO, the wizard will attempt to locate a suitable DNS server that is capable of supporting the required Active Directory domain. If the wizard locates a suitable DNS server, the “DNS Registration Diagnostics” page prompts the administrator to either verify if the located DNS server will be authoritative for the required domain or, if necessary, choose to install and configure DNS on the server running DCPROMO. Selection of the first option prompts the DCPROMO wizard to either create the DNS zone for the domain been created (if it does not exist) or where it already exists, populate the DNS zone with the appropriate service location (SRV) resource records to support the Active Directory domain. Selection of the second option prompts the wizard to install the DNS server on the server that runs the wizard, and configure the server's preferred DNS server setting to use the new local DNS server. If the DCPROMO wizard is not to create and populate a primary DNS zone on an existing DNS server within a DNS infrastructure, then the service location (SRV) resource records (RRs) to support the intended Active Directory domain will require manual creation. The authoritative primary DNS zone for the SRV locator resource records must have either the same domain name as the Active Directory domain DCPROMO is to create, or that of a parent domain. For example, if the name for the domain DCPROMO is to create is “ChildA.Natsum.com.”, then the authoritative DNS zone could be “ChildA.Natsum.com.”, “Natsum.com.”, or “com.” The following table lists the service resource records that require creation, depending upon the role of the domain controller within the forest:
Role of domain controller in forest First domain controller in a new child domain First domain controller in a new tree Additional domain controller in an existing domain SRV resource record _ldap._tcp.dc._mcdcs.ParentActiveDirectoryDomainDNSName _ldap._tcp.dc._mcdcs.ForestRootDomainDNSName _ldap._tcp.dc._mcdcs.ActiveDirectoryDomainDNSName

Table 6.3: List of SRV RRs That Require Creation for a Primary DNS Zone Where required, use the “netlogon.dns” file, created by DCPROMO and stored on the new domain controller in the “%systemroot%\system32\Config” folder, to import the required SRV RRs into the appropriate DNS zone. When determining the design requirements for the ongoing population and management of a primary DNS zone, consider the following:

Page 216 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Following the creation and initial population of a primary DNS zone with the minimum mandatory SRV RRs required to support an Active Directory domain, the next step is to determine how all other RRs that the zone will hold will be created and managed within this DNS zone.  There are two possible options for the population and maintenance of primary DNS zones. The first option is to create and maintain all zone RRs manually, and the second option is to have these tasks performed automatically, using a DNS standard (RFC 2136) known as “Dynamic Updates”.  The next factor discusses the considerations for the requirement, use, and configuration of dynamic updates for DNS zones. Using the above information, execute the following:  Determine and document the requirements to manually update existing primary DNS zones with the appropriate Active Directory service location (SRV) RRs, or  Determine and document the requirements to use the Active Directory installation wizard (DCPROMO) to automatically populate an existing primary DNS zone for a domain with the appropriate Active Directory service location (SRV) RRs, or  Determine and document the requirements to use the Active Directory installation wizard (DCPROMO) to create the primary DNS zone for a domain on a DNS server, and then populate that zone with the appropriate Active Directory service location (SRV) RRs • Factor A63: Determination of the design requirements for the configuration of dynamic updates for primary DNS zones ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the configuration of dynamic updates on primary DNS zones ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to configure dynamic updates on a per zone basis and only for primary forward lookup or reverse lookup DNS zones. Note that not all DNS server software currently in use support dynamic zone updates. Windows Server 2003 DNS server software supports dynamic updates and allows for three security modes to ensure the integrity for the data within the zone. Windows 2000 / Windows XP Professional workstations, Windows 2000 / Windows Server 2003 member servers and Windows 2000 / Windows Server 2003 domain controllers can all dynamically register resource records into a primary DNS zone configured to allow dynamic updates. The cluster service on a Windows 2000 or Windows Server 2003 cluster will dynamically register “A” or “PTR” resource records for the cluster nodes. Note that only domain controllers register (via the Netlogon service) the following forward lookup resource records:  LDAP-specific service (SRV) RRs  Kerberos Version 5 protocol-specific SRV RRs  Single “A” RR of the domain name for the domain controller

Page 217 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

It is possible to either allow workstations themselves to register their host “A” resource records within a primary DNS zone, or allow Windows 2000 / Windows Server 2003 DHCP servers providing workstations with IP address leases to perform this task. The selection of either option will influence the execution of the RR registration renewal and cleanup processes. Workstations configured with static IP addresses can only dynamically update a primary DNS zone (configured to allow dynamic updates) if the DHCP client service is running on the workstation and when:  The workstation starts up  The static IP address is changed  There is a change in the per-adapter domain name Remote Access Service (RAS) clients operate in a similar mode as statically configured clients. A RAS client will attempt to delete both the “A” and “PTR” RRs before terminating a dial-up connection. However, if this fails, or the dial-up connection unexpectedly fails, then the RRs will become stale records. In this scenario, the Windows 2000 / Windows Server 2003 RAS server will attempt to deregister the PTR RR on behalf of the client. Consider the potential for name conflicts during dynamic registration. If a client registers a name already registered to another computer’s IP address, then by default, the client deletes the existing registration record and registers its own records. This action is based upon the assumption that the IP address the new client wishes to register is no longer assigned / associated with the computer that the existing registration refers to, and hence it is safe to delete the current registration record. The default behaviour is configurable via a registry setting on a Windows DNS client. The refresh renewal period, for a primary DNS zone configured to allow dynamic updates, is set to a default of 24 hours. Client computers will hence re-register their records within a DNS zone every 24 hours. A Windows 2000 / Windows Server 2003 DHCP server that has registered “A” and “PTR” RRs will re-register these records when the client IP lease is renewed by the client (when fifty-percent of the lease duration is reached). The registering computer (DHCP client or server) performs dynamic cleanup of RRs within a primary DNS zone configured to allow dynamic updates. A Windows 2000 / Windows Server 2003 DHCP server will remove a registered “PTR” RR when an IP lease for a client expires, and will remove a registered “A” RR if configured to “discard forward lookups when leases expire”. When determining the requirements for the use of dynamics updates for DNS zones, determine which one of the following available update policy options, that determine how this zone handles DNS dynamic updates, are required:  For standard (non-Active Directory integrated) primary zones, it is possible to only select the option to enable or disable all updates  However, for Active Directory-integrated zones, it is possible to select the additional option to allow only secure updates Note that allowing non-secure DNS zone updates represents a significant security risk, as it permits a DNS zone to accept updates from un-trusted / un-checked sources. The consequences associated with this are that an attacker could flood a DNS zone with false records to accomplish one of the following three objectives:  To provide misleading IP addresses to DNS clients, hence causing misdirection to unauthorised DNS servers, and hence a denial of service attack

Page 218 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 To produce a denial of service attack via generating an excessive number (for example, tens or hundreds of thousands) of RRs within a DNS zone, thus reducing the performance of a DNS server, with respect to:  The requirement to accept and process each update, and  The requirement to replicate these DNS zone RRs to other DNS servers, hence also causing a decrease in the performance of the supporting network infrastructure  To produce a denial of service attack by exhausting all available disk space on a DNS server via the population of a excessive number of RRs within a zone Note that where there is a requirement to use a mixed DNS server infrastructure, with respect to the DNS server software platforms, then consider the configuration of all DNS servers to accept only secure DNS zone updates, where possible. Using the above information, execute the following:  Determine and document the requirements for the use of dynamic updates for primary DNS zones  Determine and document the primary DNS zones to be configured to allow dynamic updates  Determine and document the security requirements for the use of dynamic updates of DNS zones 5.9.6.1.4. Determination of the Design Requirements for DNS Zone Replication

Consider the following information when determining the requirements for the replication of DNS zones between multiple DNS servers within a DNS infrastructure: • Factor A64: Determination of the design requirements for DNS zone replication ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the creation of, or continued support for, multiple DNS zones, and  Wishes to determine the design requirements for the replication of all or some of these DNS zones to multiple DNS servers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The following reasons justify the design for the replication of DNS zones to multiple DNS servers within a DNS server infrastructure:  For fault tolerance and speed of recovery of DNS zone data  To permit load balancing of DNS name queries to a particular DNS zone by creating multiple authoritative DNS servers for a zone  To localise DNS name queries in a geographic location for an organisation and prevent such queries from crossing low available bandwidth inter-location network links

Page 219 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The design for fault tolerance of a DNS zone is critical where any disruptions to the name resolution service provided by that zone can directly affect the business continuity of an organisation. Replicating a DNS zone to multiple DNS servers permits recovery from server-specific disasters such as irrecoverable server hardware or software failure, and recovery from site-specific disasters such as fires, floods, burglary, and so on. Site-specific fault tolerance relies upon the replication of a DNS zone to one or more DNS servers in different physical locations. Service level agreements for a DNS server infrastructure may dictate the requirements for the replication of mission-critical DNS zones to meet fault-tolerance thresholds. DNS zones with many hundreds or even thousands of resource records may receive a high frequency and volume of updates, deletions, and name resolution queries. Distributing the workload for these zone activities across multiple DNS servers will enhance the performance of the DNS servers hosting these zones, and the speed of name resolution for DNS clients. Note that a secondary DNS zone is a read-only copy of a primary DNS zone, and hence cannot modify the zone database. A DNS server hosting a secondary DNS zone can hence only assist in the distribution of name resolution queries. Only a primary DNS zone can perform updates and deletions (“write and delete” activities) to the database for a DNS zone. The distribution of update and deletion activities for a DNS zone can only be accomplished via the use of Active Directory integrated (and hence primary) DNS zones, where any Windows Server 2003 DNS server on a Windows Server 2003 domain controller that receives a replica of a DNS zone can update and modify the zone RRs. Where an organisation has multiple geographically distributed physical locations, connected by low available bandwidth network links, it is important to prevent DNS clients within remote location from sending requests for updates, deletions, and name resolution queries across such network links. Localisation of a DNS zone is hence necessary where the scope of application of the DNS zone extends to multiple geographical locations for an organisation. Localisation of a DNS zone also enhances the speed of name resolution for DNS clients of that DNS zone. Note however that where the mode of replication of a DNS zone is selected to be primary to secondary (master to slave), then there will be network traffic generated to the remote location from a remote master DNS server hosting the primary DNS zone or another secondary DNS zone copy of the primary zone. However, where the mode of replication of a DNS zone is set to use Active Directory integrated (multi-master replication) DNS zones, all routine Active Directory replication traffic to a local domain controller in a remote Site will also handle all DNS zone replication traffic. Note that the use of a caching-only DNS server may be more suitable for a remote location linked to other physical locations for an organisation via low bandwidth network links. The “considerations for the determination of the requirements for a name resolution strategy” discusses the use of caching-only DNS servers. Using the above information, execute the following:  Determine and document the requirements for the replication of a DNS zone to one or more other DNS servers

Page 220 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the DNS zones that will require replication, and the minimum number of replicas required (based upon the function and scope of a DNS zone)  Determine and document the requirements for the physical distribution of the DNS zone replicas within the organisation • Factor A65: Determination of the design requirements for a DNS zone replication topology ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of multiple DNS zones  Has identified the requirements for the replication of one or more of these DNS zones to two or more DNS servers, and  Wishes to determine the design requirement for a DNS zone replication topology, for each DNS zone that requires replication to one or more DNS servers within a DNS server infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Following the identification of the DNS zones that require replication to one or more DNS servers, it is necessary to determine the design requirements for a replication topology for each in-scope DNS zone. When determining the design requirements for a DNS zone replication topology, this design methodology proposes execution of the following approach:  Determine the distribution of DNS clients for a DNS namespace within an organisation  Determine the impact of the selected storage option for a DNS zone on the design of a replication topology  Identify the DNS servers required to participate within a DNS zone replication topology and hence host a replica of a DNS zone  Understand the considerations for the following:  The geographical distribution of the DNS servers to receive and host replicas of a DNS zone, and  The impact of DNS zone replication on the levels of available bandwidth within network links, between the remote DNS servers included within the replication topology for a DNS zone  Understand the considerations for the presence of variances within the DNS server software and version of software for each DNS server to receive and host replicas of a DNS zone  Understand the considerations for the impact of the requirement to host a replica of a DNS zone on the design for the capacity and performance planning of a DNS server When determining the requirements for the localisation of DNS zone data, consider the following:

Page 221 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 To fulfil the requirement to prevent name resolution queries from affecting the performance of a supporting network infrastructure for an organisation, it is necessary to replicate a DNS zone to the appropriate local DNS servers, and hence localise network traffic for name resolution queries.  To identify the DNS servers to host copies of DNS zone for this requirement, it is hence necessary to identify the distribution of the primary DNS clients for a DNS zone.  As DNS zones (for this process) will map to Active Directory domains, the geographical distribution of a domain (via the domain controllers for that domain) provides guidance for the identification of the appropriate DNS clients.  Another consideration for the localisation of name resolution queries is the requirement for name resolution between DNS namespaces. The earlier factor (considerations for the determination of the requirements for name resolution within and between DNS namespaces) discusses the considerations that will influence the design of name resolution within and between DNS namespaces. This will influence the design for the replication of DNS zones, where there is a requirement to replicate a DNS zone for a DNS namespace to a DNS server that will receive frequent name resolution queries for RRs within that zone.  Note that is may not be feasible, depending upon the number of DNS namespaces and zones a DNS infrastructure supports, to replicate all DNS zones to all DNS servers, and hence make all DNS servers authoritative for all RRs within all zones for all namespaces.  Hence, this design methodology provides the following selection criteria to assist an organisation in the determination of the feasibility for the replication of a DNS zone to a DNS server, which does not primarily support name resolution queries for RRs within that zone:  The DNS server to receive a replica of a DNS zone does receive a large volume of frequent queries from local DNS clients for RRs within that DNS zone. The volume and frequency of name resolution queries received by that DNS server from local DNS clients for that DNS zone would, if not locally hosted, require iterative or recursive resolution to a remote DNS server. This would hence directly influence the levels of available bandwidth within associated network links.  Where the latencies associated with inter-location low bandwidth network links can directly influence the performance for name resolution queries for a particular DNS zone, consider the replication of a copy of that DNS zone to a local DNS server.  For example, a geographical location for an organisation supports applications that generate name resolution queries for RRs within a DNS zone. The latency associated with the iterative or recursive resolution of the name resolution queries across inter-location network links may directly affect the performance of an application. Note that the selected storage option for the DNS zone data of a DNS zone directly influences the replication topology for the DNS zone. Zone data held within flat “*.dns” files will require the use of DNS zone transfers to establish a multiple replica infrastructure for a DNS zone. A discrete replication topology is required for each DNS zone that requires replication using zone transfers from a master to a slave DNS server. Zone data stored within a default or custom application directory partition (ADP) of a Windows Server 2003 Active Directory forest will use the multi-master Active Directory

Page 222 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

replication model to replicate the DNS zone to those domain controllers within the naming context replica list of the selected ADP. When identifying the DNS servers that are to host replicas of a DNS zone, consider the current, and proposed network scope for these servers, and the objectives for the replication of a DNS zone. For example, it may not be valid to replicate a DNS zone that supports a namespace such as “Natsum.com.” to a DNS server that currently only supports DNS clients for DNS namespaces “A.B.C.com.” and “X.Y.Z.com.” if, within the network scope for this DNS server, there are no DNS clients that will generate queries for RRs within the “Natsum.com.” namespace. In this scenario, the replicated DNS zone for “Natsum.com.” will be redundant, with respect to the support for the distribution of name resolution queries. However, if the objective for the replication of the DNS zone to this server is not to distribute name resolution queries for the “Natsum.com.” namespace, but to provide fault-tolerance (against server or site-specific disasters), then this represents a valid inclusion of this server within the replication topology for this DNS zone. Where there is a requirement to provide fault-tolerance for DNS zone data against sitespecific disasters, consider the replication of the DNS zone(s) to DNS servers hosted within, for example, one or more disaster recovery (DR) locations for an organisation. When considering the replication of DNS zones to remote DNS servers, consider the potential replication latencies that may be associated with the replication topology for a DNS zone, and the potential impact of the replication traffic on low available bandwidth inter-Site network links. For replication topologies based upon zone transfers, changes made to a primary zone / received by a master DNS server may take time to propagate to secondary zones on remote DNS servers, as the design for change notification for a DNS zone will influence the replication intervals. For DNS zones stored within an Active Directory ADP (and thus a virtual DNS zone replication topology), inter-Site replication schedules and intervals will influence the replication latencies for DNS zone data replicated to remote DNS servers operating on remote domain controllers. Replication traffic for zone transfers generates a larger volume of replication traffic than zone replication via the Active Directory. It is important to assess the potential volume of replication traffic for zone transfers between remote DNS servers across inter-Site network links. This information will permit an analysis of the impact of the replication traffic on the levels of available bandwidth for the inter-Site network links. Consider the differences in the zone transfer capabilities of different DNS server software when identifying DNS servers to participate within a DNS zone replication topology, within a mixed DNS server software infrastructure. Consider, for example the following:  When transferring a zone between two Windows 2000 / Windows Server 2003 DNS servers, the DNS Server service always uses a fast transfer method that uses compression. This method includes multiple resource records (RRs) in each message sent to complete the transfer of the zone between servers.  For DNS servers running Windows Server 2003, this is the default method used when initiating transfer with other DNS server implementations. However, not all DNS server software supports this fast transfer method such as version of the BIND DNS server software prior to version 4.9.4.

Page 223 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 To accommodate zone transfers to these BIND DNS servers from a Windows Server 2003 DNS server primary zone, it is necessary to disable fast zone transfers (enabled by default). Configure this by selecting the “BIND Secondaries” checkbox in the “Advanced” tabbed page for the “Properties” dialog box for a Windows Server 2003 DNS server.  Not all DNS server software support incremental zone transfers (IXFR) (described in the Request for Comments (RFC) 1995 as an additional standard for replicating DNS zones).  IXFR allows for a more efficient method for zone transfers between two DNS servers that support this protocol, because it only sends the new or modified resource records (RRs) and other changes to the zone and not the whole zone and all data stored within the zone (all zone (AXFR)). The use of IXFR allows for faster DNS zone transfers that generate less network traffic.  The DNS server software for Windows 2000, Windows Server 2003, and BIND version 8.2.2 and later all support the IXFR zone transfer protocol. When considering replication of DNS zones to one or more other DNS servers, it is important to consider the impact of the replication process on the hardware storage and resource requirements for the destination DNS servers. The impact of the requirement to host a replica of DNS zone on a DNS server that is currently hosting, for example, several large DNS zones that receive frequent and large volumes of changes, may be manifested in slower responses to name resolution queries from DNS clients as hardware resources become heavily utilised. Hence, when determining the target DNS servers to host replicas of a DNS zone, consider the current hardware storage and resource utilisation statistics for that server prior to inclusion of that DNS server within the replication topology for a DNS zone. Use the above information to execute an analysis to determine the design requirements for a DNS zone replication topology. • Factor A66: Determination of the configuration requirements for a DNS zone replication topology ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation is to replicate one or more DNS zones to one or more other DNS servers within a DNS server infrastructure, and wishes to determine the configuration requirements for a replication topology. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: By default, upon creation of a primary zone, this zone does not permit zone transfers to other secondary zones on different DNS servers. This is a default security precaution to prevent an unauthorised DNS server from receiving a copy of the zone data. When determining the configuration requirements for zone transfers, consider the following security factors:  Selecting the “Allow zone transfers” checkbox in the “Zone Transfers” tabbed page of the Properties dialog box for a DNS zone permits selection of one of three of the following options to “allow zone transfers”:  To any server  Only to servers listed in the Name Servers tab (of the DNS zone)

Page 224 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Only to the following servers  The selection of the first option (“to any server”) is the least secure option, and should only be selected where, for example, the DNS zone:  Contains non-sensitive resource records, which if compromised, would not be considered a security breach (note: this option is highly unlikely in the majority of organisations)  The DNS server is located on a restricted network, with no access from external networks, such as the Internet, and so on  The selection of the second option (“only to servers listed in the Name Servers tab”) is more secure, but is only viable where, for example:  The required scope of replication of the DNS zone is adequately represented by the list of name server resource records for the DNS zone  A DNS zone has “hidden DNS servers” (not represented as NS RRs) (see later for details, in the section to determine the design requirements for DNS servers), but there is no requirement to replicate the DNS zone to these DNS servers  The selection of the third option (“only to the following servers”) is the most secure option, as the “following servers” are those listed as IP addresses in the Zone Transfers tabbed page. Note that the DNS zone does not represent the IP addresses listed for zone transfers as RRs within the DNS zone, unlike the NS RRs. Windows-based DNS servers support the “DNS Notify” (RFC 1996) update to the original DNS standard. A “notify list” is configurable for each master DNS zone that requires replication to one or more other secondary DNS servers. Enabling notification for a DNS zone allows the automatic push of updates to the secondary DNS servers for that zone. If this option is disabled, the secondary DNS servers for this zone will not receive notifications of any changes to the master zone. In some instances, it may be desirable to disable notification of zone updates to secondary DNS servers. For example, disable notification of zone updates to reduce the impact of frequent and large volume zone transfers between two DNS servers on available bandwidth on a low bandwidth network link. In this scenario, it will be necessary to use either manual intervention to initiate a pull from the secondary DNS server of zone updates or, create a scheduled batch file to trigger zone transfers. It is possible to create a batch file using the command line tool, DNSCMD.exe, and the following switch: “Dnscmd <DNS_Server_Name> /ZoneRefresh <zone_name>” When enabling zone notifications, the following two options are available upon selection of the “Automatically notify:” checkbox:  “Servers listed in the Name Servers tab”. Only select this option if it matches the corresponding selected option to restrict the scope of zone replication to the servers listed in the Name Servers tab.  “The following servers” <IP Addresses>. Only select this option if it matches the corresponding selected option to restrict the scope of zone replication to a list of IP addresses for DNS servers. For DNS zones stored within an Active Directory ADP, the list of DNS servers to receive a copy of the DNS zone is an attribute of the ADP. For example, if the default ForestDNSZones ADP or DomainDNSZones ADP is used to store the DNS zone, then

Page 225 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

the DNS zone is automatically replicated to all domain controllers within the forest or the domain in which the DNS server, on which the DNS zone is created, is a member of, respectively. It is not possible to alter the replication topology for these default ADPs. However, where a DNS zone is stored within a custom ADP, then it is necessary to customise the list of DNS servers to receive a copy of the DNS zone. This is possible using the command line tool, DNSCMD.exe, and the following switch: “dnscmd <DNS_Server_Name> /EnlistDirectoryPartition <FQDN_of_ADP>” - this command adds the specified DNS server to the partition replication scope “dnscmd <DNS_Server_Name> /UnenlistDirectoryPartition <FQDN_of_ADP>” - this command removes the specified DNS server from the partition replication scope The Start of Authority (SOA) resource record for a DNS zone controls certain zone replication parameters for the DNS zone. When determining the configuration requirements for these parameters (for inclusion within a standard configuration for DNS servers), consider the following information:  The “Refresh Interval” field (not to be confused with the refresh interval used in the configuration of scavenging and aging) indicates, to a secondary DNS server that will host the DNS zone, the interval between attempts to renew the DNS zone from a master DNS server. The default refresh interval is fifteen minutes. Use the default refresh interval within the standard configuration for all standard DNS servers, and only consider the modification of this refresh interval where the following examples of specific requirements are identifiable within an organisation:  There is a requirement to decrease the frequency of zone refresh requests by secondary DNS servers, especially where a very low ratio of master to secondary servers exists. In this scenario, the performance of a master server configured to perform zone transfers to multiple secondary servers may decrease where it is required to service multiple and frequent zone refresh requests. Increasing the zone refresh interval in this scenario may hence increase the performance of the master DNS server.  There is a requirement to decrease the frequency of zone refreshes, as there may be the requirement to replicate zone data across low available bandwidth inter-location network links (WAN and so on). Frequent request for zone renewal may have an impact on the available bandwidth levels within a WAN link, especially with the direction of a large number of requests to, for example, a single location where the master DNS server for the zone resides. Increasing the zone refresh interval in this scenario may hence decrease the volume and frequency of zone replication traffic.  There is a requirement to decrease the frequency of zone refreshes, as the data within the DNS zone changes very infrequently and hence negates the requirement for frequent zone replication to secondary DNS servers. Increasing the zone refresh interval in this scenario may hence retain DNS zone database convergence without any overheads in replication and utilisation of server hardware resources.  There is a requirement to increase the frequency of zone refreshes where, for example, a large volume of updates are received by the DNS zone, at the master DNS server, on a very frequent basis, and the default refresh interval of fifteen minutes is resulting in name resolution failures due to divergent zone databases on the secondary DNS servers. As this scenario is quite rare within the majority of organisations, only consider decreasing the refresh interval where this, or a similar scenario, is identifiable within an organisation. Note that decreasing the refresh interval may correspond with a decrease in the performance of the

Page 226 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

master DNS server(s) and an increase in the volume and frequency of network traffic for zone replication.  The “Retry Interval” field within the SOA resource record indicates, to a secondary DNS server that will host the DNS zone, the minimum interval between attempts to retry a failed zone replication from a master DNS server. The default value for the retry interval, typically set to less than the refresh interval, is ten minutes. Use the default retry interval within the standard configuration for all standard DNS servers, and only consider the modification of this retry interval where the following examples of specific requirements are identifiable within an organisation:  There is a requirement to ensure consistent results for name queries directed at resource records hosted by secondary DNS servers. Where, for example, zone transfers to a secondary DNS server must travel across unstable or inconsistent WAN links, the frequency of zone transfer failures may be high. This may consequently result in divergent DNS zone databases that fail name resolution queries for un-transferred resource records. A long interval between attempts to retry zone transfers by a secondary server may compound name resolution failures. Hence, where this type of scenario is identifiable within an organisation, consider decreasing the retry interval.  There is a requirement to reduce the frequency of zone refreshes (to meet any of the example requirements identified above for the zone refresh interval). Hence, consider increasing the corresponding retry interval to match a longer refresh interval.  The “Expires after” interval within the SOA resource record indicates, to a secondary DNS server that will host the DNS zone, the minimum interval after which the DNS zone is expired where attempts to refresh and retry refreshes fail for the duration of the “Expires after” interval. The default value for the “Expires after” interval is twentyfour hours. Hence, for example, a DNS zone was successful refreshed by a secondary DNS server from a master DNS server at 12 noon on Monday. However, if all subsequent attempts to refresh and retry refreshes to the DNS zone between 12:15pm on Monday and 11:59:59am on Tuesday fail, then at 12 noon on Tuesday, the DNS zone is expired on the secondary DNS server. The DNS zone will remain in the “expired” state until a successful zone transfer from a master DNS server reinstates the DNS zone on the secondary DNS server. Use the default value for the “Expires after” interval within the standard configuration for all standard DNS servers, and only consider the modification of this expiry interval where the following examples of specific requirements are identifiable within an organisation:  There is a requirement to migrate or upgrade a master DNS server, and it may be out of commission for longer than twenty-four hours as it undergoes hardware, operating system, and software upgrades, and stabilisation testing prior to re-introduction into the production environment. If the default expiry interval was in effect for DNS zones on this server that are replicated to secondary DNS server, the replicated zones would expire prior to re-introduction of the master DNS server into the production environment. The expiry of the zone prevents its use by the secondary DNS server of that zone in name resolution. Thus, increasing the “Expires after” interval within the SOA record for the DNS zone, prior to the last replication of the zone before the removal of the master DNS server from the network will ensure that all secondary copies of that zone remain in use until re-introduction of the master DNS server into the production environment.  There is a requirement to create one or more temporary distributed DNS zones during, for example a migration or testing phase, and the lifespan for the zone is to be only (for example) one working day (eight hours). Hence, following the creation of the DNS zone on a master DNS server, and replication to one or more secondary DNS servers, the master DNS server is decommissioned. As

Page 227 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

the secondary DNS servers will be unable to refresh the DNS zone, the zone will be in use only for “Expires after” interval (eight hours) following the initial replication of the zone.  The “Minimum (default) TTL:” field within the SOA resource record indicates, to a secondary DNS server that will host the DNS zone, the default minimum Time to Live (TTL) for resource records (that do not have a directly assigned TTL) within this zone and the minimum interval for caching negative responses to name queries. The default value for this interval is one hour. Use the default value for the “Minimum (default) TTL” interval within the standard configuration for all standard DNS servers, and only consider the modification of this TTL interval where the following examples of specific requirements are identifiable within an organisation:  There is a requirement to reduce incidences of name resolution failures for resource records (that do not have a directly assigned TTL) created, updated and deleted on a frequent basis (less than once hourly) on a master DNS server. DNS servers that cache the details of the resource records will preferentially use these records until their TTL expires. Decreasing the minimum (default), TTL for resource records, at the zone level, prompts the expiration of cached copies of these records sooner, and hence minimise name resolution failures.  There is a requirement to increase the performance of secondary DNS servers via the longer retention and use of cached copies of relatively static resource records (that do not have a directly assigned TTL) from a DNS zone. Name resolution via the use of cached entries is faster than reading the records from within a DNS zone database on a disk. Increasing the minimum (default), TTL for resource records, at the zone level, ensures the longer use of cached resource records by the DNS servers. Using the above information, execute the following:  Determine and document the requirements to restrict / un-restrict the scope of replication of DNS zones between DNS servers  Determine and document the requirements for the configuration of the “Notify List” for a DNS zone that is to be replicated to one or more other DNS servers  Determine and document the requirements for the configuration of the replica list for a custom or default ADP used to store DNS zone data  Determine and document the requirement to retain the default refresh, retry, expiry, and minimum TTL intervals within the SOA for a zone, or perform modifications of these intervals to meet specific requirements 5.9.6.1.5. Determination of the Design Requirements for the Integration of DNS with DHCP and / or WINS

Consider the following information when determining the requirements for the integration of DNS with a DHCP and / or WINS infrastructure: • Factor B31: Understanding the approach to determine the design requirements for the integration of DNS with DHCP and / or WINS ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the design requirements for the integration of DNS with DHCP and / or WINS. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 228 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

This design methodology proposes execution of the following approach to determine the requirements for the integration of DNS with DHCP and / or WINS:  Understand the prerequisites for the integration of a DNS server infrastructure with a DHCP or WINS server infrastructure  Determine the business and technical requirements for the integration of DNS with DHCP and / or WINS server infrastructures  Determine the technical configuration requirements for the integration for DNS with DHCP and / or WINS server infrastructures Note that as the integration of DNS with WINS is proprietary to Windows DNS and WINS servers, all appropriate considerations listed below for the integration of DNS with WINS are relevant only to the use of Windows (Windows 2000 or Windows Server 2003) DNS server software. • Factor B32: Understanding the prerequisites for the integration of a DNS server infrastructure with a DHCP and / or a WINS server infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the prerequisites for the integration of a DNS server infrastructure with a DHCP and / or a WINS server infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The Internet Draft, Interaction between DHCP and DNS by M. Stapp and Y. Rekhter (dhc-dhcp-dns-12.txt), is work in progress that outlines a protocol for the interaction of DHCP with DNS that builds upon dynamic DNS. This draft provides details of DHCP option 81 (client FQDN), which allows a DHCP client to provide a DHCP server (that supports this option) with its FQDN and instructions on how it would like the DHCP server to dynamically process any updates (where they exist) to a DNS server on its behalf. Microsoft Windows 2000 and Windows Server 2003 DHCP server supports option 81, and hence is capable of interacting with Windows 2000 / Windows Server 2003 DNS to update forward lookup (A) and reverse lookup (PTR) resource records for DHCP clients. Any legacy or third party DHCP server service that supports option 81 may thus be able to interact with a DNS server infrastructure that supports dynamic updates from clients and DHCP servers. The interaction between DNS and WINS is specific to Microsoft Windows 2000 / Windows Server 2003 DNS and WINS servers. It is only possible to create a WINS lookup resource record on a Windows DNS server. The WINS RR, when created within a DNS zone on a Windows DNS server, permits the DNS server to query a WINS server for an IP address to host name mapping. It is also possible to create a reverse lookup resource record for the use of WINS (a WINSR resource record). Due to the proprietary nature of this relationship between DNS and WINS, this may limit its scope of application within a mixed or non-Windows DNS environment. • Factor A67: Determination of the business and technical requirements for the integration of DNS with DHCP and / or WINS

Page 229 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the business and technical requirements for the integration of a DNS infrastructure with a DHCP and / or WINS infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes that it is only necessary to integrate a DNS infrastructure with a legacy or new Windows Server 2003 WINS server infrastructure where it is possible for an organisation to identify compliance with either or both of the following two requirements:  There is a requirement to retain a legacy or design a new Windows Server 2003 WINS server infrastructure to support legacy Windows clients or applications (such as Microsoft SMS 2.0) that rely upon a WINS infrastructure for registration of their NetBIOS names with their assigned IP addresses, and for name resolution within a NetBIOS namespace, and / or  There is a requirement to support a mixed environment, where some clients (e.g. UNIX clients) rely exclusively upon DNS for name resolution, whilst other clients rely exclusively upon WINS. Integration of a DNS infrastructure with a WINS infrastructure permits the DNS clients to query their designated DNS server for the IP address of a WINS client registered with a WINS server. Where it is possible to configure the use of DNS for name registration and name resolution for all clients within a network environment, then this design methodology advises against the use of WINS. Note that legacy Windows clients (Windows 95, 98, NT) cannot dynamically update a DNS zone with their name registration details. However, a DHCP server infrastructure, which supports option 81, can update name registration details for these legacy clients on their behalf. And thus, where there is already a legacy / third party DHCP server infrastructure that supports this option, or plans for a Windows Server 2003 DHCP server infrastructure, consider the exclusive use of DNS for name resolution, and the potential decommissioning of any legacy WINS infrastructures. In addition to the requirement, outlined above, this design methodology proposes that organisations consider the integration of DNS with DHCP where it is possible to identify compliance with the following example requirements:  There is a requirement to permit only secure updates to a DNS zone. This requirement may exist where, for example, there is a DHCP server infrastructure configured to issue IP address leases only to specific computers (scoped via reservations and user-specified and vendor-specified option classes). On the same network there may be other computers (for example, owned by contractors or other third-parties) that are given a computer account within an Active Directory infrastructure and static IP addresses, but are not to register within a DNS zone. Hence, the exclusive use of the DHCP server to update DNS zones with name registration details for the DHCP clients maintains the integrity of the DNS zone database.  As it is only possible to send updates to a DNS zone database to a primary DNS zone, there may be the requirement to centralise the updates where there is replication of a primary zone to one or more secondary DNS servers. The exclusive use of a DHCP server infrastructure to perform the updates to a primary DNS zone may assist in reducing network traffic from multiple DNS clients within a network infrastructure, especially where the DHCP and DNS clients are in remote locations to the DNS server hosting the primary DNS zone. Using the above information, execute the following:

Page 230 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the business and technical requirements for the integration of DNS with WINS for name resolution  Determine and document the business and technical requirements for the integration of DNS with DHCP for dynamic updates on behalf of DHCP clients using the example requirements listed, or other appropriate business / technical requirements of an organisation • Factor A68: Determination of the technical configuration requirements for the integration of DNS with a WINS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the integration of a DNS infrastructure with a WINS infrastructure, and  Wishes to determine the technical configuration design requirements to support this integration ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As it is only possible to integrate DNS with WINS at the DNS zone level, it is important to identify the forward and reverse lookup DNS zones that require integration. When determining the forward lookup DNS zones that require integration with WINS, identify those DNS zones that support the FQDN for legacy clients that are to retain the use of, or predominantly use, one or more WINS servers for name registration. Note when determining the DNS zones to be integrated with WINS that, as discussed within the considerations for the design requirements for DNS zones, the use of WNS by a DNS server for the forward lookup of host names is only possible from a root zone. Hence, for example, an administrator has configured a DNS zone (“A.com.”) to use WINS for forward lookups. This DNS zone has a child domain within the zone named “B.A.com.”. When the DNS server receives a query for a resource record with a FQDN of “Client1.A.com.”, it will query the WINS server for the “Client1” entry if this entry does not already exist with the “A.com.” zone. However, if the DNS server receives a query for a resource record with a FQDN of “Client2.B.A.com.”, then the DNS server cannot query the WINS server and will return a failure if a RR for “Client2.B.A.com.” does not exist with the “B.A.com.” subdomain of the DNS zone “A.com.”. If the DNS server is required to be able to resolve queries for the “B.A.com.” domain via WINS, then this domain will require representation within its own DNS zone, and not as a subdomain within the DNS zone “A.com.”. Consider the following information when determining which WINS servers each identified DNS zone will use for name resolution:  When determining the WINS servers required for each forward lookup DNS zone, if the organisation has more that one WINS infrastructure, then select those WINS servers within a WINS infrastructure that share a similar support scope as the DNS zone. The support scopes do not have to match exactly, but must ensure that the majority of host names within name resolution queries received by a DNS server will be present within the database for the selected WINS infrastructure.  Note that it is possible to configure each forward lookup DNS zone, which requires integration with WINS, with multiple WINS servers. The DNS server will initially contact the first WINS server listed at the top of the list of WINS servers. If this WINS server fails to respond (within the predetermined lookup timeout value), then the DNS server will contact the second WINS server on the list, and so on.

Page 231 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Define the order for the list of WINS servers according to geographic and network proximity to the DNS servers that will host a DNS zone configured for integration with WINS.  This may also require careful consideration where there is a requirement to replicate a WINS-integrated DNS zone to multiple DNS servers in multiple geographical locations.  In this scenario, it may be necessary to either select the checkbox “Do not replicate this record” within the WINS tabbed page of the “Properties” dialog box of a forward lookup DNS zone, or select the checkbox “Use local WINS resource record” on the secondary DNS server. Selecting either checkbox ensures that the WINS server entries are not replicated during the zone transfer process, and thus permits the independent configuration of WINS integration on DNS servers hosting secondary copies of a DNS zone. Note that selecting the checkbox “Do not replicate this record” on the primary DNS zone applies this configuration to all secondary DNS servers of that DNS zone. However, selecting the checkbox “Use local WINS resource record” on a secondary DNS server only applies a local new WINS server configuration.  Thus, in geographically remote locations, or locations in remote network proximity to each other, it is possible to configure the use of local WINS servers for name resolution, and hence prevent name resolution traffic from crossing low available bandwidth inter-location network links. If there is a mixed DNS server environment, and there is a requirement to replicate a primary forward lookup WINS-integrated DNS zone to mixed DNS servers, then select the “Do not replicate this record” checkbox to ensure no irregularities or errors in zone transfers to non-Windows DNS servers. It is possible to configure the following three other options for a forward lookup WINSintegrated DNS zone:  The configuration of the time to live (TTL) value for the WINS resource record itself  The value for the cache timeout, for a cached name resolution from a WINS server  A value for the lookup timeout when a DNS server queries a WINS server Note that these values are set per DNS zone and not per WINS server that a DNS server will query for a DNS zone. Consider the following information when determining the configuration requirements for these three options:  By default, the TTL value for a WINS resource record is not set. This value should only be set where there is a requirement for other DNS servers and some DNS clients to discard this record from their cache when, for example, the use of a WINS server for name resolution is a temporary solution during a migration phase.  By default, the cache timeout value for a WINS resource record has a value of 15 minutes, thus forcing a DNS server to discard a cached name query resolved by a WINS server after 15 minutes. When determining an appropriate cache timeout value, consider the fact that a longer cache timeout value will thus permit the longer retention of a cached name query within the DNS cache, and hence provide faster name resolution, less network traffic, and a reduction in the hardware resource utilisation on the WINS servers. However, where entries within a WINS database are subject to frequent changes, a longer cache timeout value may produce inaccurate name resolution responses from a DNS server.

Page 232 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 By default, the lookup timeout value for a WINS resource record has a value of 2 seconds. If a WINS server fails to respond authoritatively or non-authoritatively within two seconds, then the DNS server will query another WINS server (if the DNS zone is configured with a list of WINS servers). When determining an appropriate lookup timeout value, consider network latencies based upon network and geographic proximity of a WINS server to a DNS server, and the potential (hardware and software) resource utilisation levels on a WINS server (that may influence the time required to respond to a query). When determining the reverse lookup DNS zones that require integration with DNS, consider the following information:  A reverse lookup WINS-integrated DNS zone permits a DNS server to submit an IP address to a WINS server and request a host name. The presence of a WINS-R record at the zone root instructs the name server to use a NetBIOS node status (nbstat) request for any reverse lookup requests for IP addresses not represented by the PTR records within the reverse lookup zone.  When configuring the use of a reverse lookup WINS-integrated DNS zone, there is a requirement to stipulate the value for the field “domain name to be appended to returned name”. This requires careful consideration where a reverse lookup zone represents a TCP/IP subnet that contains PTR records for DNS clients with many different domain namespaces and FQDNs. In this scenario, the assignment of a domain name may produce errors in resolution.  For example, a reverse lookup zone (for example, “75.104.142.in-addr.arpa”) contains a PTR resource record for a DNS client (with a FQDN of “Client1.ChildA.Natsum.com.”) of “55”. A reverse lookup to this WINS-integrated DNS zone, configured to append the domain name of “Natsum.com.”, for the host name of the IP address “142.104.75.55” will return, via the WINS server, “Client1.Natsum.com.”  Hence, if accurate results for reverse lookups are a mandatory requirement, only integrate reverse lookup DNS zones with WINS where all of the hosts with IP addresses contained within the scope of the reverse lookup zone have the same domain name suffix. When determining the configuration requirements for a reverse lookup WINS-integrated DNS zone, consider the following information:  The same considerations for the configuration of the TTL value for the WINS-R resource record apply to a reverse lookup DNS zone as for a forward lookup DNS zone  The same considerations for the configuration of the cache timeout and lookup timeout values for the WINS-R resource record apply to a reverse lookup DNS zone as for a forward lookup DNS zone  There is one extra advanced option for the configuration of a WINS-integrated reverse lookup DNS zone. This is the option to submit the DNS domain name as the NetBIOS scope identifier. Only select this option where NetBIOS scopes are already in use within a network infrastructure.  When considering the replication of a reverse lookup DNS zone configured to use WINS, zone transfers to a secondary DNS server include the WINS-R resource record. If the secondary DNS server is required to use the same configuration within the WINS-R resource record (the domain name to be attached to all returned queries), then omit the LOCAL flag from the resource record. However, where the secondary DNS server is not a Microsoft DNS server, or where there is no requirement for the same configuration information within the WINS-R resource record by the secondary DNS server, use the "LOCAL" flag after the "WINS-R" flag.

Page 233 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Use of the LOCAL flag ensures that the WINS-R information will then not be included with the zone's resource records and hence not sent in the zone transfer. Using the above information, execute the following:  Determine and document the forward lookup DNS zones that will require integration with a WINS infrastructure for host name resolution.  Determine and document the WINS servers to be use for a forward lookup WINSintegrated DNS zone, and, where two or more WINS servers are required, their order within the list of WINS servers  Determine and document the requirements to select or deselect the “Do not replicate this record” checkbox on each required forward lookup WINS-integrated primary DNS zone that will require replication to one or more Windows or nonWindows secondary DNS servers.  Determine and document the requirements to select or deselect the “Use local WINS resource record” on a secondary DNS server that will host a copy of a forward lookup WINS-integrated DNS zone, to meet requirements for performance and / or interoperability  Determine and document the requirements to modify the default values for the TTL, cache and lookup timeout values for each required forward lookup WINS-integrated DNS zone, and where there is the requirement to modify these values, the required values for this configuration option  Determine and document the reverse lookup DNS zones that will require integration with a WINS infrastructure for IP address to host name resolution.  Determine and document the requirements to modify the default values for the TTL, cache and lookup timeout values for each required reverse lookup WINS-integrated DNS zone, and where there is the requirement to modify these values, the required values for this configuration option  Determine and document the requirement to select the option to submit the DNS domain name as the NetBIOS scope identifier for a reverse lookup WINS-integrated DNS zone • Factor A69: Determination of the technical configuration requirements for the integration of DNS with a DHCP infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the integration of a DNS infrastructure with a DHCP infrastructure, and  Wishes to determine the technical configuration design requirements to support this integration ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When enabled for integration with a DNS server that supports dynamic updates, it is possible for a Windows 2000 or Windows Server 2003 DHCP server to execute the following actions:  Either “dynamically update DNS A and PTR resource records only if requested by the DHCP clients” (the DHCP client provides this instruction to the DHCP server

Page 234 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

when the client provides the DHCP server with its FQDN, under the context of option 81), or “always dynamically update DNS A and PTR resource records”  Discard DNS A and PTR resource records upon deletion of the lease. This option is a useful method of ensuring the removal or resource records from the DNS zone database before they become stale. However, if the DHCP leases are quite short (for example, a few hours rather than days) this may subsequently generate a lot of network traffic and utilise server hardware resources on the DHCP and DNS servers.  Dynamically update DNS A and PTR resource records for DHCP clients that do not request updates (such as pre-Windows 2000 clients). This option is useful where an organisation has many legacy clients that are not capable to updating a DNS zone database and will hence rely on either manual entry of their hostname to IP address mapping, or a DHCP server that supports this option. Note that it is not possible to configure a Windows 2000 and Windows Server 2003 DHCP server to update only “A” or only “PTR” resource records. This may however occur indirectly if the appropriate DNS zones are not present or configured to disallow dynamic updates. Upon installation of a Windows 2000 and Windows Server 2003 DHCP server, by default, the DHCP server will “dynamically update DNS A and PTR resource records only if requested by the DHCP clients” and “Discard DNS A and PTR resource records when the lease is deleted”. Note that the integration of DHCP with DNS is not configured for specific DNS servers or DNS zones, as option 81 allows a DHCP server to use the FQDN of the client when determining the DNS zone to update on behalf of a client (where required). When determining the DHCP servers that require integration with a DNS infrastructure, consider the following information:  The DHCP servers that require configuration for integration with DNS must operate within the logical boundaries of the DNS namespace(s) that a DNS infrastructure supports  It is necessary to configure the DHCP clients of the DHCP servers with fully qualified domain names (FQDN) within the logical boundaries of the DNS namespace(s) supported by the DNS infrastructure Note that it is necessary to ensure each DHCP server, configured to support dynamic updates on behalf of their DHCP clients, is designated a DNS server capable of resolving any (in-scope) FQDN supplied to the DHCP server. If a designated DNS server for a DHCP server is unable to resolve a FQDN passed to a DHCP server, the DHCP server will be unable to locate the primary DNS zone to update based upon the FQDN. The default TTL value assigned to A and PTR resource records dynamically updated within a DNS zone by a Windows 2000 DHCP server is 900 seconds. SP4 for Windows 2000 permits configuration of the value of the TTL, via the support for the addition of the REG_DWORD registry entry “DynamicDNSTimeToLive” within the “HKLM\SYSTEM\CurrentControlSet\Services\DhcpServer\Parameters” key. Set the value for the data of this entry to the number of seconds required for the default TTL. Windows Server 2003 DHCP server provides an additional configuration option that permits the DHCP server to provide alternative credentials to the DNS server when performing updates on behalf of DHCP clients. This is an important consideration, as these credentials will own all records registered under these credentials at a DNS server.

Page 235 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When determining the requirements for securing DNS updates by DHCP servers, consider the following:  By default, a DHCP server that updates a resource record (RR), on behalf of a DHCP client, will become the owner of that RR.  This may cause issues where:  The DHCP server that initially registered the RRs on behalf of the DHCP clients is not available, and thus other DHCP servers, who now support the original DHCP client, cannot update or modify these RRs  A DHCP client, running a version of Windows earlier than Windows 2000, receive a Windows operating system upgrade to Windows 2000 or later, and as a result cannot take ownership of their RRs within a DNS zone  To overcome these difficulties, Active Directory provides a special built-in group named “DnsUpdateProxy”. The function of this group is to permit the shared ownership of RRs registered within a DNS zone by all members of that group. Hence, the addition of the computer accounts for multiple DHCP servers into this group permits each DHCP server to take ownership of a RR registered by peer DHCP servers, when required.  Note that the “DnsUpdateProxy” group does not hence infer security for DNS zone updates for an Active Directory integrated DNS zone that permits only secure updates, as it permits the sharing of RR ownership amongst members of the group.  Hence, where it is possible to identify compliance with the following criteria, this design methodology recommends the creation of a dedicated user account, to be the sole member of this group:  The DNS zones to be updated by a Windows Server 2003 DHCP server are configured to allow only secure dynamic updates  There is a requirement to configure a domain controller to function as a DHCP server. This scenario has major security implications as the DHCP Server service inherits the security permissions of the domain controller. This thus confers the authority to update or delete any DNS record registered in a secure Active Directory-integrated zone, including those RRS previously securely registered by other computers running Windows 2000 or a Windows Server 2003 operating system, including domain controllers). Hence, the compromise of this server could have serious consequences.  There is a requirement to configure a Windows Server 2003 DHCP server to perform DNS dynamic updates on behalf of DHCP clients  Where it is possible to identify compliance with one or more of these criteria, then configure all Windows Server 2003 DHCP servers to use this alternative credential when performing dynamic updates on behalf of DHCP clients.  It is possible to configure the Windows Server 2003 DHCP servers to use this alternative credential either:  Manually at a console  Automatically via a script that contains the netsh command: “netsh dhcp server set dnscredentials UserName Domain Password” Using the above information, execute the following:

Page 236 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the DHCP servers that will require configuration to perform dynamic updates on behalf of DHCP clients  For each identified DHCP server, determine and document the required configuration options for the integration with the DNS infrastructure  Where a Windows Server 2003 DHCP server is to be use to perform dynamic updates to a DNS infrastructure, determine and document the requirements for the configuration of alternative credentials for the DHCP server service, to perform the updates. 5.9.6.1.6. Determination of the Design Requirements for DNS Servers within a DNS Infrastructure

Consider the following information when determining the design requirements for DNS servers of a DNS infrastructure: • Factor B33: Understanding the approach to determine the design requirements for DNS servers within a DNS infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the design requirements for DNS servers within a DNS infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Note that the following approach for this step within this process assumes the use of the Windows Server 2003 DNS server software, or third party DNS server software with features and capabilities that match or supersede those of Windows Server 2003 DNS Server. The following approach builds upon the results of the analysis into the design requirements for the name resolution strategy that identified the following information, with respect to DNS server roles:  The requirements for the use of internal or external root DNS servers  The requirements for the use of internal forwarder DNS servers  The requirements for the use of caching-only DNS servers Hence, when determining the design requirements for the DNS servers within a DNS infrastructure, this design methodology proposes execution of the following approach  Understand and determine the DNS roles that will require design for the DNS infrastructure  Understand the use of actual or virtual DNS server roles  Understand the configuration options for (Windows Server 2003) DNS servers  Where it is possible to identify the requirements for the design and use of the standard DNS server role, then determine the following information:  The logical and physical placement requirements for the standard DNS servers  The number of standard DNS servers required, and minimum hardware specifications

Page 237 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The configuration requirements for the standard DNS server role  Where it is possible to identify the requirements for the design and use of the caching-only DNS server role, then determine the following information:  The logical and physical placement requirements for the caching-only DNS servers  The number of caching-only DNS servers required, and minimum hardware specifications  The configuration requirements for the caching-only DNS server role  Where it is possible to identify the requirements for the design and use of the internal forwarder DNS server role, then determine the following information:  The logical and physical placement requirements for the internal forwarder DNS servers  The number of internal forwarder DNS servers required, and minimum hardware specifications  The configuration requirements for the internal forwarder DNS server role  Where it is possible to identify the requirements for the design and use of the internal root DNS server role, then determine the following information:  The logical and physical placement requirements for the internal root DNS servers  The number of internal root DNS servers required, and minimum hardware specifications  The configuration requirements for the internal root DNS server role  Review the example provided by this design methodology for the modular approach to development of standard DNS server role configurations The above approach reflects the best practice methodology for the development of standard configurations for server roles, to ensure ease of deployment, management, and troubleshooting of the servers once operating within the production environment of an organisation. The approach proposes that the configurations to be identified as “baseline configuration options” (see factor “understanding the configuration options for (Windows Server 2003) DNS servers”) be used as templates for the four DNS server roles, with modifications (additions or deletions) to the configurations where required. Note that it is important to determine the logical and physical placement requirements for these DNS server roles, prior to their technical configuration requirements. This order of analysis will permit the requirements for the logical and physical placement of these DNS server roles to influence their technical configuration requirements. For example, the placement of a caching-only DNS server in a remote location, connected to another site via one WAN link, will influence the configuration of internal root server entries, or forwarder entries to internal forwarder DNS servers for this caching-only DNS server.

Page 238 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor A70: Determination of the required DNS server roles for a DNS server infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of two or more DNS servers, and  Wishes to determine the required DNS server roles for a DNS server infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A Windows Server 2003 DNS server (or third party DNS server that matches or exceeds the capabilities of a Windows Server 2003 DNS server) can perform one of the following four standard roles within an internal (to the organisation) DNS infrastructure:  A standard DNS server  A caching-only DNS server  An internal forwarder DNS server  An internal root DNS server The local DNS server configuration requirements for each of these four roles differ slightly with respect the:  Hosting and use of local DNS zones  The configuration and use of normal and conditional forwarder entries  The configuration and use of root hints to internal and external DNS servers The following table presents the characteristics this design methodology proposes for each DNS server role, within the context of the above configuration requirements:
DNS Server Role Use of DNS Zones (Primary, Secondary, and Stub Zones) A standard DNS server will have a combination of primary, secondary and stub zones A (strict) caching only DNS server will have no DNS zones at all Use of Forwarder Entries (Normal and / or Conditional) A standard DNS server may be configured with normal or conditional forwarder entries A caching only DNS server may be configured with normal or conditional forwarder entries An internal forwarder is not (ideally) configured with normal forwarder entries. It may, however, be configured with one or more conditional forwarder entries. Use of Root Hints (to Internal and / or External Root Servers) A standard DNS server may be configured with root hints to an internal or external root DNS server A caching only DNS server may be configured with root hints to an internal or external root DNS server An internal forwarder is typically configured with root hints to an external root DNS server

Standard DNS server

Caching Only DNS server

Internal Forwarder DNS server

An internal forwarder DNS server is not (ideally) configured with DNS zones, unless it is required to handle inbound name queries originating from outside of the internal DNS infrastructure

Page 239 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

DNS Server Role

Use of DNS Zones (Primary, Secondary, and Stub Zones) An internal root DNS server will be configured with a combination of primary, secondary or stub DNS zones

Use of Forwarder Entries (Normal and / or Conditional) An internal root DNS server is not (ideally) configured with normal forwarder entries. It may, however, be configured with one or more conditional forwarder entries.

Use of Root Hints (to Internal and / or External Root Servers) An internal root DNS server is not configured with root hints to any other internal or external DNS server

Internal Root DNS server

Table 6.4: Characteristics of the Four DNS Server Roles These proposed characteristics will influence the configuration requirements for each of these roles. An organisation may alter these characteristics to meet specific requirements, and thus alter the configuration of requirements for a DNS server role. Note that the use of one or more “standard” DNS servers will be required within any DNS infrastructure that will support the defined scope of the Active Directory infrastructure. However, the use of one or more caching-only DNS servers, and internal forwarder or root DNS servers, may not be required within all organisations, as the use of these DNS server roles depends upon the requirements of the name resolution strategy. See the results of the analysis into the design requirements for a name resolution strategy for details of the requirements for these DNS server roles. Using the above information, determine and document the DNS server roles required for a DNS server infrastructure. • Factor A71: Determination of the requirements for the design and use of actual or virtual DNS server roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of two or more DNS server roles, and  Wishes to determine the requirements for the design and use of actual or virtual DNS server roles ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A DNS server dedicated to performing only one DNS server role, such as an internal forwarder or root DNS server, represents an actual DNS server role. However, where a DNS server operates several roles, then each of these roles are virtual DNS server roles. It is possible to mix and match DNS server roles or dedicate DNS server roles to discrete DNS servers. The following table provides guidance as to the supported combinations of server roles and the roles that require isolation from other DNS server roles:

Page 240 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

DNS Server Roles Standard DNS server Caching Only DNS server Internal Forwarder DNS server

Caching-Only DNS server No – Caching-Only server does not host DNS zones

Internal Forwarder DNS server No – Internal forwarder server should not (ideally) host DNS zones Yes – Internal forwarder may be configured as a caching-only server

Internal Root DNS server Yes – If internal root DNS server requires the use of local DNS zones No – If internal root DNS may require the use of DNS zones No – Ideally internal forwarder should have minimal exposure to internal root DNS servers

Table 6.5: Supported Combinations of DNS Server Roles to Create Virtual DNS Servers Note that the use of a standard DNS server as an internal forwarder DNS server depends upon the location and function of the forwarder DNS server. If the forwarder DNS server requires configuration to both send outbound name queries to external DNS servers and receive inbound name queries from external DNS servers, then the server should, ideally, reside within a secure partition of the network, such as a DMZ. In this scenario, the hosting of DNS zones on this server, in a DMZ, that contain resource records for internal hosts may compromise the security of these hosts. If however, a particular forwarder DNS server is to only send outbound name queries to external DNS servers, and not receive inbound name queries, then it is possible (though not recommended) for this server to reside within the internal network. In which case, it is possible for this server to host DNS zones containing resource records for internal hosts, as long as one or a series of firewalls are present at the boundaries of the internal and external networks. The use of an internal root DNS server as an internal forwarder DNS server requires consideration of the same security principles outlined above. If the forwarder DNS server is to reside within a DMZ, it is advisable to use conditional forwarders (where required) for inbound name queries (where supported) from external DNS servers to a discrete internal root DNS server. It is not advisable to host the internal forwarder DNS server on an internal root DNS server, which is capable, by virtue of its role, of exposing all internal namespaces and hosts. When determining the use of actual versus virtual DNS server roles, consider the option to configure all DNS server roles with the baseline configuration options for the “standard” DNS server role (where applicable). Then, for each other specific DNS server role, apply role-specific configuration options as deltas to the “standard” DNS server role configuration. Using the above information, execute the following:  Determine and document the DNS server roles that the organisation may wish to host as actual (dedicated) DNS server roles  Determine and document the DNS server roles that the organisation may wish to host as virtual (multifunction) DNS server roles • Factor A72: Determination of the configuration requirements for (Windows Server 2003) DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to:

Page 241 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Understand the technical configuration options available for (Windows Server 2003) DNS servers, and  Identify the baseline configuration options for all DNS server roles ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to configure the following categories of options on a (Windows Server 2003) DNS server:  Server configuration options  DNS zone (forward and reverse lookup) configuration options When determining the design requirements for the configuration of server options, consider the following:  The configuration of the interfaces on which the DNS server will listen for name queries from DNS clients. This list may contain multiple IP addresses for a multihomed DNS server, for example an internal forwarder DNS server residing within a firewall-partitioned network. The variable nature of this configuration option requires the discrete design of this option for each DNS server, to include and / or exclude certain interfaces from the list, where appropriate.  The configuration of the TCP/IP protocol on each network interface that the DNS server will listen on, and use for name query resolution. Identify the configuration of the TCP/IP protocol for each network interface on each DNS server as one of the baseline configuration options for all DNS servers. However, due to the variable nature of this configuration requirement, the specific configuration details will require design for each network interface on each DNS server.  Consider the following information when determining the configuration requirements for each of the following properties of the TCP/IP protocol on each network interface:  The DNS server list: A Windows Server 2003 DNS server may point to itself as its primary or alternate DNS server, even if the DNS server service is installed on a Windows Server 2003 domain controller. (Note that this configuration generated the “island server” issue with Windows 2000 DNS servers installed on Windows 2000 domain controllers (see Microsoft Knowledge Base article 275278 for details)). This “island server” issue has been resolved in Windows Server 2003 DNS servers, which now register their DsaGuid._msdcs.<forestname> record with each DNS server that is a member of the domain. Because the alternate DNS server is only used by a DNS client when the primary DNS server is unavailable, when determining the selection of alternate DNS servers, consider the following: • Where possible, select an alternate DNS server on the same subnet as the primary DNS server to minimise inter-subnet network traffic • Where possible, select an alternate DNS server in closest network proximity to the primary DNS server if the primary DNS server is located in a remote location • Consider failures in routers and network links when determining alternate DNS servers. The primary DNS server may not be available due to a router or network link failure. If the network path to an alternate DNS server relies upon the same router / network links, then the failure will persist.

Page 242 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The configuration of the use of the primary DNS suffix and connection-specific suffixes for single label name queries, or the use of a DNS suffix search list (these options will be applied to all interfaces that use TCP/IP)  The configuration of a connection-specific DNS suffix  The configuration for the dynamic registration of the host name of the DNS server within the contexts of the primary and connection-specific DNS suffixes  The WINS server list, which may be used by the DNS server for WINS lookups, where configured on forward and reverse lookup DNS zones  Configuration requirements for forwarder and conditional forwarder entries for a DNS server, due to their variable nature, require discrete design for each DNS server, where appropriate. See the “considerations for the determination of the design requirements for a name resolutions strategy” for detailed considerations for the use of forwarder and conditional forwarder entries).  The configuration options for forwarder and conditional forwarder entries may include:  The entry of IP addresses of DNS servers for the default forwarder entry “All other DNS domains”  The entry of required (conditional) DNS suffixes and corresponding IP addresses of DNS servers able to assist in the resolution of those suffixes  The configuration of the time out value for attempts to contact a listed forwarder (default is 5 seconds)  The configuration of the DNS server to prevent recursion following the exhaustion of all relevant forwarder entries for a DNS domain when resolving a name query (default is to allow recursion)  The advanced server options which may require configuration include:  The disabling of recursion (default is to enable recursion). Note that disabling recursion prevents the DNS server from using any configured forwarder or conditional forwarder entries or root hints, as this would require the generation of a recursive name query. The configuration requirements for this option require discrete consideration for each DNS server, as it may be applicable to some, but not all DNS servers. Consider disabling recursion for a DNS server only where it is not to use any forwarder or conditional forwarder entries or root hints.  The option to configure the use of fast zone transfers to secondary BIND DNS servers (version 4.9.4 and later) (enabled by default) should be disabled only where BIND DNS servers are not used within the DNS infrastructure for the organisation, or earlier versions of BIND DNS servers are used that do not support fast zone transfers. The configuration requirements for this option require discrete consideration for each DNS server, as it may be applicable to some, but not all DNS servers, such as caching-only DNS servers.  The option to fail zone loading where the zone data is bad (disabled by default) should be enabled where the strict parsing of zone data is required prior to use of the zone data for resolution of name queries. The selection of this option can prevent subsequent errors in name resolution. The resource utilisation of server hardware will only be intensive during initial DNS service startup. This option requires the use of DNS zones on the DNS server, and hence the configuration requirements for this option requires discrete consideration for each DNS server as it may be applicable to some, but not all DNS servers, such as caching-only DNS servers.

Page 243 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Consider the option to use DNS Round Robin (enabled by default) alongside the requirements for subnet prioritisation on the DNS server itself, and on the DNS clients of the DNS server. The configuration requirements for this option require discrete consideration for each DNS server, as it may be applicable to some, but not all DNS servers, such as caching-only DNS servers. Note that it is possible to configure further advanced options for the DNS Round Robin service via the following registry keys: • It is possible to restrict the DNS Round Robin service to specific types of resource records, such as A, PTR, SRV, NS, MX, and so on, via the entry of the list of RR types in the REG_SZ registry entry “DoNotRoundRobinTypes”, which requires creation within the registry subkey “HKLM\System\CurrentControlSet\Services\DNS\Parameters”. • It is possible to disable the DNS Round Robin service via the modification of the data value of the REG_DWORD registry entry “RoundRobin” to 0 (default is 1). This registry entry requires creation within the registry subkey “HKLM\System\CurrentControlSet\Services\DNS\Parameters”.  Configure DNS server subnet prioritisation (enabled by default) via the selection or de-selection of the checkbox “Enable netmask ordering”. If DNS Round Robin is required, and one or more of the hosts for the single alias hostname are located on separate subnets, then consider disabling this feature if it compromises the Round Robin feature for host list ordering. Note that Windows NT 4.0 (SP4) and later Windows DNS clients use subnet prioritisation by default, and this supersedes DNS Round Robin list ordering. The configuration requirements for DNS server subnet prioritisation requires discrete consideration for each DNS server, in conjunction with the use of DNS Round Robin, as it may be applicable to some, but not all DNS servers.  The DNS server cache is, by default, protected against “cache pollution”. This option configures the DNS server to determine whether any returned responses are potentially polluting or insecure, and if so, discard those responses without storing them in the cache. For example, if a name query to another DNS server, for “test1.Natsum.com.” results in a referral resource record that contains a DNS domain name outside of the “Natsum.com.” namespace, such as “abcd.com.”, then the DNS server generating the original query would discard this RR. The configuration of protection against cache pollution is relevant for all DNS servers that will communicate with DNS servers external to the internal DNS infrastructure (or un-trusted by the internal DNS infrastructure), such as internal forwarder DNS servers. Internal standard DNS servers, which will not communicate with any external or un-trusted DNS servers, do not require configuration against cache pollution, as this adds a minor resource overhead to normal DNS operations. Do not consider disabling protection against cache pollution unless there is a justified requirement to do so. Identify this option as a baseline configuration option for all DNS servers, for use in either its default configuration, or in a custom configuration.  Name checking, by default, uses the Multibyte (UTF8) method, which permits all characters allowed when select Non RFC (ANSI) (see below), and the recognition and transformation of multibyte characters for representation using Unicode Transformation Format (UTF-8). Identify this option as a baseline configuration option for all DNS servers, for use in either its default configuration, or in a custom configuration. It is, however, possible to configure a Windows Server 2003 DNS server to use the following alternative name checking methods (warning: changing the default method for name checking on a DNS server may result in changes to the zone data in zones hosted by the DNS server): • Strict RFC (ANSI): This method uses strict name checking against the Internet host naming specifications defined within RFC 1123 (allows “A” to “Z”,

Page 244 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“a” to “z”, the hyphen (-), the asterisk (*) as a first label; and the underscore (_) as the first character in a label). Only use this method where there is a requirement to enforce compliance with RFC 1123 specifications, to support, for example, specific applications, or interoperability with other DNS infrastructures. • Non-RFC (ANSI): This method permits the use of non-standard host names that do not comply with the Internet host naming specifications defined within RFC 1123 (allows all characters allowed when select Strict RFC (ANSI), and allows the underscore (_) anywhere in a name). Do not use this method unless all namespaces within the internal DNS infrastructure are private and will never require registration for use on the Internet. • All names: This method permits the use of any characters, including UTF-8. Do not use this method unless all namespaces within the internal DNS infrastructure are private and will never require registration for use on the Internet.  The default boot method for initialising the DNS server service is from the Active Directory and the registry. It is possible to alter this default method, to boot the service from just the registry, or from a boot file. BIND DNS servers use a boot file (labelled “Named.boot”) to initialise the service. Identify this option as a baseline configuration option for all DNS servers, for use in either its default configuration, or in a custom configuration.  Only consider altering the default boot method for a Windows Server 2003 DNS server to use a boot file where the registry or Active Directory cannot provide the required parameters for service initialisation, but, for example, a BIND DNS boot file can.  If a Windows Server 2003 DNS server is required to boot from a BIND boot file, then the file must be in configured using the older BIND 4 format, and not the recent BIND 8 or 9 boot file format. Where the BIND boot file does not cater for all of the required service initialisation parameters, the registry on the Windows Server 2003 DNS server will be the alternative default source for these parameters and their values.  It is possible to configure scavenging and aging at the server level, to apply to resource records in all forward and reverse lookup DNS zones on a DNS server. By default, Windows Server 2003 DNS servers do not enable this feature. The configuration requirements for this option require discrete consideration for each DNS server, as it may be applicable to some, but not all DNS servers.  Consider the use of scavenging and aging where there is a requirement to:  Control the volume and frequency of registration refreshes by Windows DNS clients, and hence network traffic and workload on DNS servers  Remove stale records on DNS servers that are consuming disk space and server resources to maintain them. It is possible to observer this scenario, for example, in dynamic environments where resource records may be frequently registered with different DNS servers by roaming user with laptop computers.  Control the volume and frequency of zone replication initiated by updated / modified resource records  Control the consistency of name resolution requests via the removal of stale resource records held within the DNS zones  Enhance the performance of name resolution requests to DNS servers via the removal of stale resource records, thus reducing the size of the search scope

Page 245 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Remove all stale resource records that may be preventing the dynamic registration and use of a domain name or FQDN by another computer or device  When considering the use of scavenging and aging on Windows Server 2003 DNS servers, consider the following information:  To enable the scavenging and aging of stale resource records, the following prerequisites must be met: • The resource records that are stored within the DNS zones on a DNS server are either dynamically registered or modified (manually) to accommodate the scavenging and aging process. The manual modification of manually created resource records for scavenging and aging involves the selection of the checkbox “Delete this record when it becomes stale” in the properties dialog box for a resource record. It is also possible to prepare all resource records for scavenging and aging via the /AgeAllRecords switch with the “dnscmd.exe” command line tool. The /AgeAllRecords command forces a timestamp and therefore aging on all records at the specified node on the specified DNS server. This is for backward compatibility between the current version of DNScmd and previous releases where aging and scavenging were not supported. • Scavenging and aging must be enabled at both the server level (to apply to all forward and reverse lookup DNS zones on a DNS server) and at the zone level. Once enabled at the server level, each DNS zone will inherit the values for the no-refresh and refresh intervals (see below for details), but they can be overridden at the zone level, where required.  The use of scavenging and aging can delete all resource records that are marked for aging (have a timestamp configured). This can hence have disastrous consequences where there is a lack of understanding of the process and configuration requirements prior to configuration. In the event of the accidental deletion of a record, then in addition to the name resolution failures associated with the absence of the record, any user may re-create the record and take full ownership of the record, even with a zone configured for secure dynamic updates. This hence has severe security implications that require consideration when determining the requirements for scavenging and aging.  Enabling scavenging and aging on a primary DNS zone, stored as a flat *.dns file, alters the format of the file. Although this does not affect secondary copies of this DNS zone, or initiate replication to secondary servers, it may no longer be possible for third party DNS servers to load the modified file. The subsequent consequences require consideration within a mixed DNS server environment.  For DNS zones configured to store data within Active Directory, and to perform scavenging and aging, it is possible to specify scavenging servers for the DNS zone. Without the specification of scavenging servers for an Active Directoryintegrated DNS zone, and DNS server (on a domain controller) that loads the DNS zone from the Active Directory may initiate scavenging processes. This may have undesired consequences where there is no synchronisation between aging and scavenging. It is only possible to use the “DnsCmd” command line tool, and the following command for this tool (“<ServerName> /ZoneResetScavengeServers <ZoneName> [<Server IPs>]”), to specify one or more scavenging servers for an Active Directory-integrated DNS zone.  When considering the use of scavenging and aging, the following parameters require configuration:  The no-refresh interval: This interval (default value of 7 days when scavenging and aging enabled) represents the period during which the DNS server does not

Page 246 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

accept registration refresh requests from Windows DNS clients for dynamically updated and now aged resource records. The DNS server will accept, however, updates to the resource records during the no-refresh interval, such as changes to the IP address for the record. To prevent premature refreshing of resource records, the no-refresh interval matches the default value for the refresh interval. The default value for the no-refresh interval is sufficient for most requirements, and hence only consider altering it where there is a requirement to match a new value for the refresh interval. A long no-refresh period permits stale resource records to remain within the DNS database for longer.  Consider altering the no-refresh interval for registration refresh requests where the following examples of criteria may be identified: • DNS clients (or DHCP servers that perform dynamic registrations on behalf of DHCP clients) connected to a DNS server via a low available network link (such as a demand-dial network connection) may benefit from an increased no-refresh interval that will prevent excessive network traffic. Longer intervals between the acceptances of registration refresh requests by a DNS server will increase the levels of available bandwidth within the network connection. • Domain controllers within branch offices (that do not have local access to a DNS server hosting a primary copy of the “_msdcs.< domain>” DNS zone) connected to a DNS server within a hub location over a low available bandwidth network link may also benefit from an increased no-refresh interval. This interval will be set on the root DNS zone for the domain these domain controllers represent, or a delegated “_msdcs.< domain>” DNS zone of this domain. • Global Catalog within branch offices (that do not have local access to a DNS server hosting a primary copy of the “_msdcs.<forest_root_domain>” DNS zone) connected to a DNS server within a hub location over a low available bandwidth network link may also benefit from an increased no-refresh interval. This interval will be set on the root DNS zone for the forest, or a delegated “_msdcs.<forest_root_domain>” DNS zone of the forest root domain. (See later for the significance of the requirement for Global Catalog to contact this DNS zone)  Note: For granular configuration of the registration refresh interval to apply to specific domain controllers and Global Catalog servers, consider the configuration of the REG_DWORD registry entry “DnsRefreshInterval” within the registry sub-key “HKLM\Software\Policies\Microsoft\Netlogon\Parameters” with the appropriate refresh interval (in seconds).  Note the following about the use of this registry entry: • It is preferable that this registry configuration be performed via the Windows Server 2003 Active Directory Group Policy Object policy setting “Refresh Interval for the DC Locator DNS Records”, which is only applicable to Windows Server 2003 domain controllers. • The value for this registry entry must not exceed the refresh interval configured within the scavenging and aging configuration for the “_msdcs” DNS zone, otherwise the DNS server will delete the appropriate SRV RRs prior to their refresh. • This registry entry also determines how often the Netlogon services on the domain controllers also updates the dynamic site coverage list for participating domain controllers within a forest. (See later for details about the requirement to configure the “autositecoverage” feature of Active Directory domain controllers.)

Page 247 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Subsequent to the configuration of this registry entry, and after the initial successful registration of the appropriate SRV RRs by the Netlogon service for a domain controller or GC server, the Netlogon service will attempt to reregister these SRV RRs after five minutes have elapsed. The interval between each subsequent re-registration will double until the interval matches the data value for the “DnsRefreshInterval” registry entry. Thereafter, the Netlogon service will only attempt re-registration following the expiration of the data value (number of seconds) for the “DnsRefreshInterval” registry entry.  The refresh interval: This interval (default value of 7 days when scavenging and aging enabled) represents the period during which the DNS server will accept requests to refresh dynamically registered resource records by Windows DNS clients, once the no-refresh period for a resource record expires.  Expiry of the refresh interval for a resource record, without any refresh requests by the owner of the resource record during this interval, marks the resource record as a stale record.  As the refresh interval applies to all resource records in all DNS zones on a DNS server, the value for this interval must exceed the longest default refresh interval set by the source of any dynamically registered resource records, and must not be shorter than the shortest default refresh period for a dynamically registered resource record. For example, the default refresh interval set on a RR registered by a DHCP server is fifty-percent of the duration of an IP lease. Use of the default lease duration (for a Windows DHCP server) of eight days implies a refresh interval of four days. A resource record dynamically registered by the netlogon service, the cluster service, or a DHCP client has a default refresh interval of twenty-four hours. Consider altering the refresh interval for aging of resource records only where the shortest refresh interval is longer than seven days, or the longest refresh interval is shorter than seven days.  Automatic or manual scavenging: By default, enabling automatic scavenging for a Windows Server 2003 DNS server sets a default interval of 7 days between scavenging processes. The minimum configurable interval is 1 hour. Scavenging of resource records occurs once the refresh interval has expired for a resource record without any requests to refresh the resource record by the record owner. It is possible to initiate the manual scavenging of resource records as a single nonrecurring event for all DNS zones on a DNS server. Manual scavenging does not affect the schedule for automatic scavenging (if enabled and suitably configured).  Note, enabling automatic scavenging at the same time as enabling scavenging and aging on a DNS server allows synchronisation between the aging and scavenging cycles. Thus, the scavenging cycle will match the terminus period for the refresh cycle, and hence the process will remove stale records as soon as the refresh interval expires for a resource record.  Consider the modification of the default interval for scavenging only where there is the requirement to match a new refresh interval for resource record aging.  The configuration of root hints for a DNS server (see the “considerations for the determination of the design requirements for a name resolutions strategy” for detailed considerations for the use of root hints). The configuration requirements for this option require discrete consideration for each DNS server, as it may be applicable to some, but not all DNS servers. The use of root hints may include the use of the default root hints (from the cache.dns file) pointing to the Internet root DNS servers, or custom root hints to one or more internal root DNS servers.  The configuration of event logging for a DNS server involves the selection of the required logging level for events, as they occur on the DNS server, in the Application

Page 248 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Event Log of the server. Identify this option as a baseline configuration option for all DNS servers, for use in either its default configuration (to log all events), or in a custom configuration.  The four event logging configuration options that may be selected are:  No logging at all: The selection of this option ensures the logging of no DNS events at all within Application Event Log on the server. Do not consider the use of this option for a production DNS server. This option is only viable for selection on, for example, test, and laboratory DNS server installations.  Errors only: The selection of this option filters out all informational and warning events and logs only the error level events in the Application Event Log. Again, do not consider the use of this option for a production DNS server. Warning event messages are very useful for the ongoing preventative maintenance of a DNS server installation.  Errors and Warnings: This option is the minimum recommended event logging option for production DNS servers. Only consider the use of this option where the production DNS server has stabilised following deployment, and has entered a change control infrastructure.  All Events: This option logs all event messages on a DNS server, and is the default logging option on Windows Server 2003 DNS servers. This may be useful for troubleshooting but not for routine maintenance of the DNS server, as too many event messages may mean that significant messages are missed, and there is an overhead on the DNS server to write all the events to the Application Event Log.  The forward and reverse lookup DNS zone configuration options include:  Determination of the types of forward or reverse lookup DNS zones required. It is possible to create primary, secondary, or stub forward and reverse lookup DNS zones on a Windows Server 2003 DNS server. Consult the considerations for the determination of the design requirements for DNS zones for details of DNS zone selection requirements.  Determination of the DNS zone storage requirements (within a flat (*.dns) file, within a default (domain or forest) ADP, within the legacy domain partition to support Windows 2000 DNS servers on Windows 2000 domain controllers, or within custom ADPs in an Active Directory infrastructure). Based upon the identified requirements, propose that the selected storage option for DNS zone data is applied to all applicable DNS zones and hence, the use of this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones.  Determination of the DNS zone creation requirements (dynamic updates or manual creation of resource records) for each required primary DNS zone. Consult the considerations for the determination of the design requirements for primary DNS zones for details of the required zone creation options for primary DNS zones. Based upon the identified requirements, propose that the selected zone creation option for primary DNS zones is applied to all applicable DNS zones and hence, the use of this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones.  Determination for the primary DNS zone population requirements (dynamic updates or manual resource record creation) for each required DNS zone. Consult the considerations for the determination of the design requirements for DNS zones for details of the required DNS zone population options. Based upon the identified requirements, propose that the selected zone population option for primary DNS zones is applied to all applicable DNS zones and hence, the use of

Page 249 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones.  Determination of the primary DNS zone maintenance requirements (zone scavenging and aging configuration, use of DHCP to remove dynamically registered RRs when IP leases expire, and so on) for each required DNS zone. See above for the details in the use of scavenging and aging on a Windows Server 2003 DNS server, and consult the considerations for the determination of the design requirements for the integration of DNS with DHCP and / or WINS for the DHCP integration configuration requirements. Based upon the identified requirements, propose that the selected zone maintenance option for primary DNS zones is applied to all applicable DNS zones and hence, the use of this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones.  Determination of the DNS zone replication requirements, that includes the configuration of zone transfers and notify lists, replication topology requirements, use of Active Directory replication to replicate Active Directory-integrated DNS zone data, and so on Consult the considerations for the determination of the requirements for DNS zone replication for details of the required configuration options. The configuration requirements for this option require discrete consideration for each DNS server, as they may be applicable to some, but not all DNS servers.  Determination of the requirements for the integration of DNS with DHCP and / or WINS infrastructures, detailing the configuration requirements for WINS lookup and reverse lookup, and configuration requirements for DHCP server integration with DNS to dynamically register “A” and “PTR” resource records on behalf of DHCP clients. Consult the considerations for the determination of the design requirements for the integration of DNS with DHCP and / or WINS for details of the required configuration options. The configuration requirements for these options require discrete consideration for each DNS server, as they may be applicable to some, but not all DNS servers.  Determination of the configuration requirements for the Start of Authority (SOA) resource record within each primary DNS zone, detailing the configuration requirements for the following fields within this record: • The “Primary Server” field (that denotes the DNS server that “owns” this DNS zone): This is typically the first DNS server that hosts the DNS zone when created. Where there is a requirement to migrate the DNS zone to another DNS server that will become the primary server for this zone, consider amending this field to reflect the new owner. • The “Responsible Person” record represents the administrator of the DNS zone. Consider the configuration of this record only where, for example, there is the requirement to replicate the DNS zone to multiple secondary DNS servers, and autonomous components within a distributed IT administrative infrastructure will be responsible for local DNS server maintenance. Knowledge of the administrator for the DNS zone may be useful in this scenario for the processing of zone administration requests and troubleshooting. Note that the when populating this record, replace the “@” symbol within an e-mail address with a “.” to follow FQDN naming conventions. It is possible to create a “Responsible Person” resource record within the DNS zone and use it to populate this field. • The “Refresh Interval” field within the SOA resource record: Consult the results of the analysis to determine the requirements for DNS zone replication for the configuration requirements of the refresh interval. Based upon the identified requirements, propose that the selected refresh interval within the

Page 250 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

SOA RR is applied to all applicable DNS zones and hence, the use of this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones. Only consider the modification of the refresh interval for a DNS zone to meet specific requirements identified within an organisation. • The “Retry Interval” field within the SOA resource record: Consult the results of the analysis to determine the requirements for DNS zone replication for the configuration requirements of the retry interval. Based upon the identified requirements, propose that the selected retry interval within the SOA RR is applied to all applicable DNS zones and hence, the use of this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones. Only consider the modification of the retry interval for a DNS zone to meet specific requirements identified within an organisation. • The “Expires after” interval within the SOA resource record: Consult the results of the analysis to determine the requirements for DNS zone replication for the configuration requirements of the expiry interval. Based upon the identified requirements, propose that the selected expiry interval within the SOA RR is applied to all applicable DNS zones and hence, the use of this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones. Only consider the modification of the expiry interval for a DNS zone to meet specific requirements identified within an organisation. • The “Minimum (default) TTL:” field within the SOA resource record: Consult the results of the analysis to determine the requirements for DNS zone replication for the configuration requirements of the minimum (default) TTL interval. Based upon the identified requirements, propose that the selected minimum (default) TTL value within the SOA RR is applied to all applicable DNS zones and hence, the use of this requirement as a baseline configuration option for all DNS servers that will host the applicable DNS zones. Only consider the modification of the minimum TTL value of a DNS zone to meet specific requirements identified within an organisation.  Determination of the configuration requirements for the Name Server (NS) resource records for a DNS zone. The NS resource records provide two vital functions for a DNS zone. Firstly, they define the authoritative servers for a DNS zone, thus allowing the reception of name resolution requests for the DNS zone by these servers, and secondly, they identify the authoritative servers for delegated sub-domains hosted on other DNS servers. When determining the requirements for the Name Server resource records for a DNS zone, consider the following information: • When delegating a sub-domain for a DNS zone, there may be the requirement to create a glue record for a NS that contains an out-of-zone name. A glue record is an “A” record created within the delegated domain on a DNS server that permits referrals up the namespace hierarchy to locate an authoritative name server (a process also known as “glue chasing”). A NS resource record used for the purpose of delegation (as opposed to an “A” resource record) is a “delegation record”. • A DNS zone may have multiple name servers, and the list of name servers for a zone may be used to determine the scope of replication of a DNS zone, and the scope of zone change notifications within the notify list for a DNS zone. • Note that, by default, DNS servers automatically register Name Server (NS) resource records for themselves within a DNS zone that is loaded from an Active Directory ADP (or legacy Active Directory DNS zone storage location, within a domain partition). Where an organisation has the requirement to use

Page 251 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

a “hidden DNS server” then the automatic registration of NS server resource records may be an issue. A hidden DNS server is one that is not visible within a DNS zone and thus not represented via a NS record for a DNS zone, and can only be found and used by the DNS clients designated with the IP address for this DNS server. • Consider the use of “hidden DNS servers” (or “Stealth Servers”) where it is possible to identify the following requirement. There is a requirement to replicate a DNS zone to multiple DNS servers, each separated by low available bandwidth network links, and the local DNS clients of the DNS zone must not contact any other DNS servers (via the NS records for the DNS zone) other than their designated DNS servers. A DNS zone that has many NS resource records may increase the volume of network traffic generated by DNS clients querying for NS records for the DNS zone. • Thus, where this scenario may be identified within an organisation, and there is a requirement to use hidden DNS servers, then there may be the requirement to: ♦ Disable the automatic creation of a NS resource record by one or more DNS servers for a DNS zone ♦ Identify a list of specific DNS servers (via a list of static IP addresses for the DNS servers) permitted to automatically create their NS resource records within a DNS zone • In order to disable the automatic creation of NS resource records by a DNS server, the REG_DWORD registry entry “DisableNSRecordsAutoCreation” requires creation within the registry sub-key “HKLM\System\CurrentControlSet\Services\DNS\Parameters” with a value of “0x1”. • In order to specify a list of DNS servers that are explicitly permitted to create their NS resource records within a DNS zone loaded from an Active Directory ADP, the REG_SZ registry entry “AllowNSRecordsAutoCreation” requires creation within the registry sub-key: ♦ “HKLM\System\CurrentControlSet\Services\DNS\Parameters\Zones\<Zon e_Name>”, or ♦ The registry sub-key “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\<Zone_Name>” • Note, that the above registry entry to permit DNS servers to automatically create their NS resource records, as it is stored within the zone configuration, will be automatically replicated via Active Directory replication to other servers, where the DNS zone data is stored within the Active Directory. Using the above information, execute an analysis to determine the configuration requirements, for the following baseline configuration options applicable to the following DNS servers:  The requirements for the following configuration options require application to all DNS server roles (standard, caching-only, internal forwarder and internal root) either within their default configurations, or within custom configurations:  Protection against cache pollution (enabled by default)  The name checking method (uses the Multibyte (UTF-8) method as default configuration)

Page 252 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The DNS server initialisation method (DNS servers boot from the Active Directory and the registry as default configuration)  Event logging mode (logs “All Events” in default configuration)  The requirements for the following configuration options require application to all DNS server roles that may host DNS zones (and thus excludes any strict cachingonly DNS servers):  DNS zone storage, creation, population, and maintenance, requirements  DNS zone replication and Start of Authority configuration requirements for the refresh, retry, expiry, and minimum (default) TTL intervals  Configuration of Name Server (NS) resource records, and their automatic creation by DNS servers • Factor A73: Determination of the requirements for the logical and physical placement of standard DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the use of standard DNS servers, and  Wishes to determine the design requirements for the logical and physical placement of these server within the DNS and network infrastructures of the organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the requirements for the logical and physical placement of DNS servers, configured to operate within the context of the standard DNS server role, consider the following information:  The logical and physical placement of a standard DNS server within the DNS and network infrastructures of an organisation will influence:  The DNS zones that the server will host. A DNS server only requires the local hosting of those zones that are relevant to the majority and most frequent internal name queries that the DNS clients of the DNS server will generate, and requirements for dynamic updates. For example, it is not necessary for a DNS server to host DNS zones (as primary or secondary) that will receive very infrequent name queries. These name queries may hence better serviced via redirection of the name queries to other authoritative DNS servers for these DNS zones by the local DNS server.  Configuration requirements for forwarder / conditional forwarder entries, defined within the name resolution strategy for the DNS infrastructure. Ideally, where the requirements for the use of two or more internal forwarder DNS servers is identified, then the standard DNS servers should be configured to use the internal forwarder DNS server in closest network proximity (influenced by the logical and physical placement of the standard DNS server).  Configuration requirements for root hint entries, defined within the name resolution strategy for the DNS infrastructure. As for internal forwarder DNS servers, where the requirements for the use of two or more internal root DNS servers is identified, then the standard DNS servers should be configured to use the internal root hint server that:

Page 253 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Is authoritative for the root DNS zone of the DNS namespace that the standard DNS server primarily supports (to permit faster internal intranamespace name resolution) • Is in closest network proximity to the standard DNS server (influenced by the logical and physical placement of the standard DNS server)  The selection of standard DNS servers configured to receive replicas of nonActive Directory-integrated DNS zone data. To prevent excessive network traffic generated by zone replication between DNS servers, the replication topology for a DNS zone may be restricted to supporting standard DNS servers in close network proximity to each other.  Integration of the DNS zones on a standard DNS server with DHCP and / or WINS infrastructures. For example, the DHCP server(s) that will require configuration to dynamically update a DNS zone, on behalf of a DHCP client, and the WINS server(s) to provide host name lookups, should ideally be close network proximity to a standard DNS server to prevent such updates and lookup queries crossing WAN links.  The numbers and distribution of DNS clients within an organisation that has multiple geographical locations will influence the logical and physical placement of standard DNS servers within the network infrastructure of an organisation. For example, locations with fewer than ten DNS clients may not require a local standard DNS server.  The configuration of the network infrastructure will influence the logical and physical placement of the standard DNS servers. For example, an organisation with a single large location may have a partitioned network infrastructure that creates many subnets, separated and connected by routers. To meet requirements to minimise inter-subnet network traffic, it may be necessary to place standard DNS servers within each partition of the network infrastructure that requires standard DNS server support.  The requirements to use Active Directory-integrated DNS zone data (stored within a default or custom ADP or within the legacy location (domain partition)) will influence the logical and physical placement for standard DNS servers. In order to access DNS zone data stored within the Active Directory, it is necessary to install the DNS server on a Windows Server 2003 domain controller. Hence, the logical and physical distribution of the Windows Server 2003 domain controllers will determine the distribution and placement of the Windows Server 2003 DNS servers. Using the above information, execute the following:  Determine and document the network and physical locations within an organisation that will definitely require one or more local standard DNS servers, and hence the total minimum number of standard DNS servers required.  Determine and document the network and physical locations within an organisation that may require one or more local standard DNS servers following completion of all DNS server analysis.  Determine and document the support scope within each location where one or more local standard DNS servers are required, identifying the numbers, types, distribution, and name resolution requirements of the DNS clients within this support scope. • Factor A74: Determination of the number of standard DNS servers required, and minimum hardware specifications

Page 254 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the locations where a standard DNS server may be required, and  Wishes to determine the actual number of standard DNS servers that will be required, and the design requirements for the minimum hardware specifications for this DNS server role ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Consider the following factors when determining the actual number of standard DNS servers required within each logical and physical location within an organisation, identified as potentially suitable for hosting one or standard DNS servers:  The redundancy requirements for name resolution services provided by a standard DNS server  The performance requirements for name resolution services provided by a standard DNS server  The financial and administrative overheads associated with the number of standard DNS servers required  Requirements for service autonomy, service isolation, and data isolation  The use of the standard DNS server role as an actual or virtual DNS server role Consider the use of two or more standard DNS servers within a logical or physical location where it is possible to identify compliance with the following examples of requirements for redundancy of the name resolution service:  Where there is currently a requirement to place a minimum of one standard DNS server per subnet in a router-partitioned network infrastructure, one or more additional DNS servers in this subnet will provide redundancy should the single DNS server on a subnet fail (due to hardware or software failure). This approach will permit the redirection of the DNS clients (via the alternate DNS server configuration entry) to another local standard DNS server, thus retaining name resolution services and minimising inter-subnet network traffic.  Each DNS zone that supports an Active Directory domain (or contiguous tree of domains), or any other business-critical application or process within an organisation, requires replication to a minimum of two standard DNS servers, regardless of the storage mode for the zone data. If the zone data was stored within an Active Directory ADP, for example, a DNS server is still required to create the zone to provide access to the zone data. Without any pre-configured additional DNS servers for a DNS zone, the time required to re-create a DNS server, re-create the DNS zone, re-configure all DNS clients of the failed DNS server and so on, may prove detrimental to the continuity of the business.  Additional DNS servers may be required in hub sites to handle temporary increases in name resolution queries from DNS clients redirected due to the failure of a local DNS server. Consider the use of two or more standard DNS servers within a logical or physical location where it is possible to identify compliance with the following examples of requirements for performance of the name resolution service:  One or more of the DNS zones that a single standard DNS server may be required to host contain many thousands of resource records. The DNS server may hence

Page 255 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

receive hundreds to thousands of name queries on a daily basis. Distributing the DNS zones to more than one local standard DNS server will assist in increasing the performance of each DNS server.  The host server for the standard DNS server role has a primary function that utilises the majority of the server hardware resources. The performance of the name resolution service provided by the DNS server, that relies upon the over utilised hardware resources, may hence be detrimentally affected. Distributing the name resolution workload for this DNS server to one or more additional local standard DNS servers may hence increase performance. It is important to consider the financial and administrative overheads associated with the creation and management of a number of standard DNS servers. The greater the number of standard DNS servers required, the higher the financial overhead associated with the actual server hardware and hardware resources. For example:  The financial overheads for the server hardware components, such as CPUs, memory, disk space and so on  The overheads associated with the physical storage and security of the server at a physical location within the organisation  The overheads associated with the utilisation of available network bandwidth, and so on.  The financial and administrative overheads associated with the management of each additional server also require consideration When determining the number of standard DNS servers required to support the defined scope of the Active Directory infrastructure and all appropriate DNS client, consider the following requirements for service autonomy, service isolation, and data isolation:  Where an organisation is composed of one or more autonomous sub-divisions, and each division has their own Active Directory infrastructure, then there may be the requirement to restrict the support boundaries for standard DNS zones to reflect the Active Directory forest, tree, or domain boundaries. The enforcement of this model may thus permit the degree of service autonomy required by a division within the organisation, for the ownership and management of standard DNS servers. There may also be, for example, financial and administrative incentives to maintain service autonomy, with respect to the DNS server infrastructure. For each autonomous division within an organisation, there may thus be the requirement to design and deploy multiple standard DNS servers, each with a restricted scope of support, to meet requirements for service autonomy.  An autonomous sub-component / division of an organisation may have the requirement to isolate their internal DNS infrastructure from other DNS infrastructures within the organisation. For example, the IT administrative team for an autonomous division may be under pressure to present and maintain compliance with service level agreements for the DNS name resolution service, which is essential to the operation of an Active Directory infrastructure. Isolation of their DNS infrastructure from other DNS infrastructures within the organisation may permit greater control over external influences and inputs into the infrastructure, and thus permit control over business continuity.  An autonomous sub-component / division of an organisation may have the requirement to isolate their DNS zone data and access to the data, via the use of discrete standard DNS servers. In these scenarios, the division may decide not to use the default DNS “ForestDNSZones” or “DomainDNSZones” application directory partitions, unless the autonomous division owned the forest. If the autonomous

Page 256 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

division was represented within an Active Directory domain, shared by one or more other divisions or departments within the organisation, then there may be the requirement to store DNS data on the data isolated standard DNS servers within the flat (*.dns) files on the servers. Hence, there may be the subsequent requirement to enforce a minimum of two DNS servers per DNS zone, for fault tolerance of the DNS zone data. This option has security implications that require careful consideration. Note that it is possible to create the required number of standard DNS servers, but without the use of the additional server hardware to create actual (dedicated) standard DNS servers. The use of virtual standard DNS servers (where the DNS server service operates on a Windows Server 2003 member server with a different primary function, a Windows Server 2003 domain controller, or another DNS server role) permits the use of multiple DNS servers without the associated financial overheads of dedicated server hardware. However, it is necessary to consider the hardware resource requirements for the primary function of the server and the standard DNS server role, and ensure that performance of the standard DNS server role, or the primary function of the server, does not decline due to biased over-utilisation of the hardware resources. It may be necessary to test the required role combinations in a laboratory environment prior to deployment within a production environment. When determining the minimum hardware specifications for the standard DNS server roles, consider the following:  A Windows Server 2003 DNS server service only uses approximately four Mb of RAM to start, without any configured DNS zones  Each additional DNS zone and resource records within a DNS zone a DNS server hosts will require additional RAM. It is roughly estimated that each additional resource record within a DNS zone require 100 bytes of server RAM. Hence, a DNS server with two DNS zones, each holding a thousand resource records, will approximately require [4 Mb + ((100 bytes x 1000) x 2)] = 4.2 Mb. This is hence not a significant overhead on the memory resources of a server.  Disk write requirements will be greater on DNS servers configured with dynamically updatable primary DNS zones, and with secondary DNS zones that will receive frequent zone transfers. The disk write requirements will be greater where the primary DNS zone data is stored with an Active Directory ADP, as each update is treated as an update to the Active Directory database, and hence contributes to the transaction-logging mechanism for Active Directory writes.  The CPU requirements for DNS operations are not significant as the service only uses CPU cycles when performing a narrow spectrum of activities, such as responding to name resolution queries, sending and receiving zone transfers, starting and stopping the DNS server service, updating DNS zones with received updates from the network or manually inputted updates, registration refreshes and renewals, and so on  The network interface card requirements for a DNS server may be significant where the server is required to support large numbers of DNS clients and hence queries and possibly dynamic updates and registrations. There may hence be contention for network resources where a virtual standard DNS server role must compete with another network intensive function on the same server, such as an application server, a file and print server, a media streaming server, and so on Using the above information, execute the following:

Page 257 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the number of actual standard DNS servers required within each appropriate logical and physical location to meet requirements for redundancy, performance, service autonomy, service isolation, data isolation, and financial and administrative overheads.  Determine and document the number of virtual standard DNS servers required, and identification of the:  Primary function(s) of the server the virtual standard DNS server will be operating upon  The presence of any other virtual DNS server roles (such as internal forwarder or internal root DNS server roles) on the same server  The logical and physical locations for these virtual standard DNS servers  Determine and document the minimum hardware requirements for the acceptable performance and operation of a standard DNS server role, as an actual or virtual server  Determine and document the requirements to upgrade hardware specifications where, for example, virtual standard DNS servers are required to operate upon servers with high utilisation requirements for hardware resources to serve another primary function • Factor A75: Determination of the configuration requirements for the standard DNS server role ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and deployment of two or more standard DNS servers, and  Wishes to determine the technical configuration requirements for this server role ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The standard configuration options for the standard DNS server role should reflect the following requirements for the organisation:  The requirements for the name resolution strategy for the resolution of intra- and inter-namespace name queries  The requirements for the types of DNS zones required to support the defined scope of the Active Directory infrastructure  The requirements for the creation, population, maintenance, storage and replication of DNS zones on the standard DNS servers  The requirements for the integration of DNS with DHCP and / or WINS infrastructures All DNS servers, configured to operate within the parameters of the “standard DNS server” role, will be required to execute and support the following:  Provide authoritative name resolution services for DNS clients, via locally hosted DNS zones, the creation, population and maintenance of the appropriate DNS zones will require consideration.

Page 258 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Facilitate the resolution of intra- and inter-namespace name queries by DNS clients, the appropriate configuration of root hints and forwarder / conditional forwarder entries will require consideration. The configuration of root hints and forwarder / conditional forwarder entries must align with the identified requirements for the name resolution strategy of the DNS infrastructure.  Replicate (non-Active Directory-integrated) DNS zone data to one or more secondary DNS servers, the appropriate DNS zone replication configurations will require consideration.  Support load-balancing of multiple alias host names for two or more hosts, via the use of DNS Round Robin, the appropriate configuration requirements for Round Robin and subnet prioritisation (on the DNS server and the DNS clients) will require consideration.  Permit dynamic updates by DNS clients and / or DHCP servers, the appropriate DNS zone configuration to permit dynamic updates will require consideration.  Use a WINS infrastructure forward and reverse lookup host name resolution, the appropriate configuration requirements for the DNS zones, and the TCP/IP properties of the DNS server network interface(s) will require consideration. Using the above information, execute the following:  Determine and document the actual support functions and operations required from the standard DNS server roles  Determine and document the appropriate configuration requirements for each configuration option, for each identified standard DNS server, to enable the required functions and operations for this server role. • Factor A76: Determination of the design requirements for the logical and physical placement of caching-only DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and use of caching-only DNS servers (from the results of the analysis to determine the design requirements for a name resolution strategy), and  Wishes to determine the design requirements for the logical and physical placement of these DNS servers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objectives for the use of caching-only DNS servers are to reduce the network overheads associated with the provision of a DNS name resolution service. Hence, it is only possible to realise this objective upon compliance with the following criteria:  The caching-only server is able to resolve, after a period, the majority (for example, between seventy-five to ninety percent) of received name resolution queries from its local DNS cache, and thus generate no network traffic.  The caching-only DNS server is required to resolve, after a period, a minority (for example, between ten to twenty-five percent) of received name queries via forwarder or root DNS servers, and thus generate network traffic.

Page 259 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The logical and physical placement of the caching-only DNS server role will influence the ability of this role to meet the stated criteria. Hence, when determining the placement requirements for caching-only DNS servers, consider the following location-specific factors that will influence the ability of the caching-only to meet the criteria stated above:  The number of DNS clients that a location, and hence potentially a caching-only DNS server, is required to support may influence the placement decision for this DNS server role. The ability to meet the criteria above declines linearly with an increase in the number of DNS clients a caching-only DNS server will be required to support, based upon the variety of name queries generated by the DNS clients. The larger the number of DNS clients within a location, the greater the variety of name queries, and hence the lower the probability that a local cache is able to resolve the majority of name queries. Note that this parameter requires consideration in conjunction with the following parameters that determine the source, content, nature, variety, or consistency of name queries as well.  The types of DNS clients (Windows DNS clients, applications, processes and so on), that will generate DNS name queries, at each potential location for a cachingonly DNS server. Where, for example, a location supports one or more applications that will make varied name queries for RRs represented within multiple DNS namespaces of a DNS infrastructure, the local DNS cache on the caching-only DNS server may be unable to resolve the majority of these queries.  The distribution of the DNS clients amongst, for example, multiple DNS namespaces represented within an Active Directory infrastructure. With the distribution of DNS clients amongst multiple DNS namespaces, and the subsequent variety of name queries, the local cache of a caching-only DNS server may be unable to resolve the majority of name queries.  The network connectivity within a potential location for a caching-only DNS server may influence the selection of the closest (with respect to network proximity) forwarder and / or root DNS servers. Where the closest forwarder and / or root DNS servers are many network hops away, then the potential impact on current network traffic may be substantial for all name queries that the caching-only DNS server is unable to resolve via the local DNS cache. The use of an authoritative DNS server in these locations may allow a reduction in the requirements to contact forwarder or internal root DNS servers, depending upon the nature of the name queries.  A caching-only DNS server may be suited to the support of, for example, a few DNS clients located within a partition of a network infrastructure designed to minimise inter-subnet network traffic. A caching-only DNS server may assist in meeting these requirements via the localisation of the network traffic for the majority of name queries and provision of a single point for departure and reception for the minority of network queries from that network partition. Using the above information, execute the following:  Determine and document the locations where a caching-only DNS server may be suitable for deployment based upon the consideration of the:  Number and types of DNS clients to be supported by a caching-only DNS server in each location  The nature, consistency / variety, and content of the majority of name queries issued by these DNS clients  The quality and levels of available bandwidth within network links connecting the potential locations for caching-only DNS servers

Page 260 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The network proximity to forwarder and root DNS servers  Determine and document the locations within an organisation where a caching-only DNS server may not be suitable based upon consideration of the above factors that influence the placement of this DNS server role. • Factor A77: Determination of the number of caching-only DNS servers required, and minimum hardware specifications ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has determined the requirement for the design and deployment of one or more caching-only DNS servers, and  Wishes to determine the actual number of caching-only DNS servers that will be required, and the design requirements for the minimum hardware specifications for this DNS server role ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Consider the following factors when determining the actual number of caching-only DNS servers required within each logical and physical location within an organisation, identified as potentially suitable for hosting one or more local caching-only DNS servers:  The redundancy requirements for name resolution services provided by a cachingonly DNS server  The performance requirements for name resolution services provided by a cachingonly DNS server  The financial and administrative overheads associated with the number of cachingonly DNS servers required  Requirements for service autonomy, service isolation, and data isolation  The use of the caching-only DNS server role as an actual or virtual DNS server role When determining the redundancy requirements for name resolution services provided by a caching-only DNS server, consider the following information:  The failure of name resolution services provided by a caching-only DNS server may be caused by:  Failure of the caching-only DNS server (hardware or software) and thus no provision of name resolution services  Failure of a component of the network infrastructure between the DNS clients and the caching-only DNS server thus preventing reception of name resolution queries by a caching-only DNS server  Failure of a component of the network infrastructure between the caching-only DNS server and a forwarder and / or root DNS server, thus preventing the use of a forwarder or root DNS server for assistance in resolving name queries  The placement of two or more caching-only DNS servers at a location can protect against the first example of a failure criteria, where the caching-only DNS server becomes unavailable. However, as the criteria for the placement of a caching-only DNS server (see above) restricts the use of a caching-only server to locations that,

Page 261 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

for example, support only a few DNS clients that generate infrequent and primarily consistent name queries, in these instances, two or more caching-only DNS servers may be superfluous to their requirement. Hence, in these scenarios, assure protection against server failure via the configuration of an alternate DNS server IP address within the supported DNS clients of a caching-only DNS server. When determining the performance requirements for name resolution services provided by a caching-only DNS server, consider the following information:  As discussed above, the placement criteria for a caching-only DNS server defines a restricted number of DNS clients, and hence name queries, that a caching-only DNS server will be required to support. Based upon these criteria, the performance of the name resolution services for a caching-only DNS server will not be subject to degradation unless the scope of DNS clients and volume of name resolution queries the server must support changes substantially, post-deployment of the server.  Hence, it may not be justifiable to design and implement multiple caching-only DNS servers within a location to ensure no degradation in performance of the name resolution services provided by the server. Monitoring of the performance statistics of the caching-only DNS server may be required to ensure no degradation of the performance of name resolution services. When determining the financial and administrative overheads associated with the number of caching-only DNS servers required for each location, consider the following information:  As described below, caching-only DNS servers are ideally suited to a virtual DNS server role, operating as the non-primary role on a physical server. This hence limits the financial overheads associated with the use of caching-only DNS servers, as multiple dedicated physical servers may not be required.  The administrative overheads associated with caching-only DNS servers are minimal. Once appropriately configured, the server does not require much maintenance as it does not host any DNS zones. Hence, a large number of cachingonly DNS servers will not represent a substantial administrative overhead within an organisation. When determining the number of caching-only DNS servers required to support the defined scope of the Active Directory infrastructure and all appropriate DNS client, consider the following requirements for service autonomy, service isolation, and data isolation:  Where an organisation is composed of one or more autonomous sub-divisions, and each division has their own Active Directory infrastructure, then there may be the requirement to restrict the support boundaries for caching-only DNS servers to reflect the Active Directory forest, tree, or domain boundaries. The enforcement of this model may thus permit the degree of service autonomy required by a division within the organisation, for the ownership and management of caching-only DNS servers. For each autonomous division within an organisation, there may thus be the requirement to design and deploy multiple caching-only DNS servers, each with a restricted scope of support, to meet requirements for service autonomy.  An autonomous sub-component / division of an organisation may have the requirement to isolate their internal DNS infrastructure from other DNS infrastructures within the organisation. For example, the IT administrative team for an autonomous division may be under pressure to present and maintain compliance with service level agreements for the DNS name resolution service, which is essential to the operation of an Active Directory infrastructure. Isolation of their DNS infrastructure from other DNS infrastructures within the organisation may permit greater control over external influences and inputs into the infrastructure, and thus permit control over business continuity.

Page 262 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A caching-only DNS server does not host any DNS zones, and the only DNS data held by this server resides temporarily within the local cache. Although the data within the cache has a TTL value (defined by the resource record and authoritative DNS server), it is possible to maliciously access and retrieve this data from the caching-only DNS server. Hence, where this is a requirement for data isolation, then the use of discrete caching-only DNS servers that are carefully controlled and managed, with respect to use and access, may meet these requirements. A caching-only DNS server is ideally suited to deployment as a virtual DNS server role, as it requires minimal server hardware and software resources for operation. It is hence possible to install a caching-only DNS server on a Windows Server 2003 member server that has an alternative primary function, or on a Windows Server 2003 domain controller. When determining the minimum hardware specifications for a caching-only DNS server, consider the following information:  A caching-only DNS server does not perform disk writes for DNS zone data (for zone transfers, manual entries, or dynamic entries)  A caching-only DNS server will not use a significant amount of RAM for name resolution activities via the local cache or via forwarder or root DNS servers. Using the above information, execute the following information:  Determine and document the number of actual caching-only DNS servers required within each appropriate logical and physical location to meet requirements for redundancy, performance, service autonomy, service isolation, data isolation, and financial and administrative overheads.  Determine and document the number of virtual caching-only DNS servers required, and the identification of the:  Primary function(s) of the server the virtual caching-only DNS server will be operating upon  The presence of any other virtual DNS server roles (such as internal forwarder or internal root DNS server roles) on the same server  The logical and physical locations for these virtual caching-only DNS servers  Determine and document the minimum hardware requirements for the acceptable performance and operation of a caching-only DNS server role, as an actual or virtual server.  Determine and document the requirements to upgrade hardware specifications where, for example, virtual caching-only DNS servers are required to operate upon servers with high utilisation requirements for hardware resources to serve another primary function. • Factor A78: Determination of the standard configuration requirements for the caching-only DNS server role ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and deployment of one or more caching-only DNS servers, and  Wishes to determine the configuration requirements for this server role

Page 263 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The name resolution strategy to use an internal root DNS server and / or forwarders will determine the configuration requirements for caching-only DNS servers. Below are some examples of name resolution strategies that influence the configuration requirements for caching-only DNS servers:  Where there is a requirement to inclusively send all name queries, that cannot be locally resolved on an internal DNS server, to one or more internal root DNS servers (for appropriate resolution / redirection for resolution), then a caching-only DNS server must be configured only with custom root hints. The internal root DNS servers for the required root hints should be those in close network proximity to the caching-only DNS server. The local default cache.dns file on the caching-only DNS server requires deletion for this scenario.  Where there is a requirement to inclusively send all name queries, that cannot be locally resolved on an internal DNS server, to one or more forwarders, then a caching-only DNS server must be configured only with forwarders or conditional forwarders (to point to specific forwarder DNS servers for specific namespaces). The forwarders that will receive the recursive queries from the caching-only DNS server should be those in closes network proximity to the caching-only DNS server. Again, the local default cache.dns file on the caching-only DNS server requires deletion for this scenario.  Where there is a requirement to inclusively send all name queries, that cannot be locally resolved on an internal DNS server, to one or more Internet root DNS servers, then a caching-only DNS server must be configured only with the default root hints (from the default cache.dns file) pointing to the Internet root DNS servers. Note that this configuration option assumes that the caching-only DNS server will have network access to the Internet. For any name resolution strategies that do not exactly fit one of the above example scenarios, determine the appropriate configuration requirements for a caching-only DNS server, noting the requirement to select the DNS server that will receive an iterative, or recursive, name query from this server, as the server in closest network proximity. Use the results of the Site Plan process “analysis of the current and proposed network infrastructure”, to determine the most appropriate forwarder or internal or external root DNS servers. Note that the use of recursive name queries shifts the onus on name resolution to the target forwarder DNS server. This may be desirable for a caching-only DNS server that operates from a remote location, on a heavily (server hardware resources) utilised multi-function server, or with a low available bandwidth inter-location network link. The use of recursive queries results in fewer name queries transmitted on the network link, with only two messages transmitted per name query. To minimise the use of any network links to generate recursive or iterative name queries for repeated / repeatable name queries, consider the modification of the configuration of the default time to live (TTL) values for all cached entries. It is possible to modify the maximum cache size, maximum cache TTL, and maximum negative cache TTL. The negative cache holds entries for name resolution requests that failed to be resolved. It is possible to configure these values using the DnsCmd.exe command line utility, and the following switches:  “dnscmd <DNS_Server_Name> /Config /MaxCacheSize”

Page 264 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 “dnscmd <DNS_Server_Name> /Config /MaxCacheTTL”  “dnscmd <DNS_Server_Name> /Config /MaxNegativeCacheTTL” Using the above information, determine and document the standard configuration requirements for caching-only servers, and those parameters that require discrete consideration and configuration for each caching-only DNS server. • Factor A79: Determination of the design requirements for the logical and physical placement of internal forwarder DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and use of internal forwarder DNS servers (from the results of the analysis to determine the design requirements for a name resolution strategy), and  Wishes to determine the design requirements for the logical and physical placement of these DNS servers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objectives for the use of internal forwarder DNS servers are to perform one of the following functions:  Internal inter-namespace name resolution (via conditional forwarder entries), or  External inter-namespace name resolution (via non-conditional or conditional forwarder entries), or  A combination of both internal and external inter-namespace name resolution When determining the logical and physical placement requirements for the internal forwarder DNS server role to meet the one of the objectives listed above, consider the following information:  The geographic distribution of the DNS clients of the forwarder DNS server roles within organisation, and their logical distribution within the supporting network infrastructures of an organisation  The requirements for redundancy of the internal and / or external inter-namespace name resolution services  The presence, number and distribution of firewall-partitioned network segments (also known as demilitarised zones)  The presence, number, and distribution of network connection points to one or more external networks (extranets and the Internet) If an internal forwarder DNS server is required to support only internal inter-namespace name resolution, then it does not require placement in close proximity to network connection points to external networks. Instead, placement of one or more internal forwarder DNS servers must be in locations that are in the closest proximity to the largest concentrations of DNS clients configured with forwarder entries pointing to these servers. If an internal forwarder DNS server is required to support only external, or a combination of internal and external inter-namespace name resolution, then it will

Page 265 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

require placement in close proximity to network connection points to external networks, such as the Internet. When determining the logical and physical placement of internal forwarder DNS servers, the distribution of the DNS clients of a forwarder DNS server require consideration. Note that the DNS clients of a forwarder DNS server may be other DNS servers within a DNS infrastructure. To minimise the impact on the network from the requirement to route name queries to an internal forwarder DNS server, consider placing one or more forwarder DNS servers within the closest possible network proximity to the largest concentrations of DNS clients. Use a combination of the geographic and network distribution of these DNS clients to ascertain the most appropriate locations for internal forwarder DNS servers. The inter-namespace name resolution services provided by an internal forwarder DNS server are prone to the following causes of failure:  Failure of the server hardware or software for the internal forwarder DNS server  Failure within a component of the internal supporting network infrastructure may result in the network isolation of the forwarder DNS server from all, most, or some of the DNS clients  Failure within a component of the internal supporting network infrastructure that permits outbound connections to external networks may result in the inability of a forwarder DNS server to contact external DNS servers to resolve name queries Where there is a requirement to mitigate failures caused by all three of these possible causes, consider the following:  The use of multiple internal forwarder DNS servers mitigates the failure of the server hardware or software within a single internal forwarder DNS server  Where an internal routed network infrastructure supports the use of multiple network routes for redundancy against failures in routers and other network components, consider the distributed placement of multiple internal forwarder DNS servers. Place forwarder DNS servers within network segments that are alternate network routes for DNS clients of the forwarder DNS servers.  It is only possible to mitigate the failure of a component of an internal network infrastructure, which prevents network connections to or through an external network connection point, where an organisation has multiple external network connection points. Where this is true, consider the distributed placement of internal forwarder DNS servers within close network proximity to two or more external network connection points. This design methodology recommends the placement of an internal forwarder DNS server within a firewall-partitioned network segment if it is required to support external inter-namespace name resolution services. If an external network connection point does not have the protection of a firewall or a firewall-partitioned network segment, then do not consider the placement of an internal forwarder DNS server here. Where an organisation has only a single network connection point to one or more external networks, including the Internet, then place one or more internal forwarder DNS servers (required to support external inter-namespace name resolution) in close proximity to this connection point. However, where an organisation has more than one network connection point to external networks, consider combinations of the following factors in determining appropriate placement for these DNS servers:

Page 266 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The distribution of the largest concentrations of DNS clients, of the internal forwarder DNS server, with respect to their geographic and network proximity to each external network connection point, will influence placement. For example, it is unfeasible to place an internal forwarder DNS server near an external network connection point that has only ten DNS clients in closest network proximity, whilst there are a few hundred DNS clients closer to an alternative external network connection point.  The presence and distribution of firewall-partitioned network segments in close network proximity to external network connection points (see considerations above for firewall-partitioned network segments)  The requirements for redundancy of an external inter-namespace name resolution service (see considerations above for redundancy) Using the above information, execute the following:  Determine and document the locations where an internal forwarder DNS server may be suitable for deployment based upon the consideration of:  The distribution of the DNS clients of the forwarder DNS server roles within the geographic and network infrastructures of an organisation  The requirements for redundancy of the internal and / or external internamespace name resolution services  The presence, number and distribution of firewall-partitioned network segments (also known as demilitarised zones)  The presence, number, and distribution of network connection points to one or more external networks (extranets and the Internet)  Determine and document the locations where an internal forwarder DNS server may not be suitable for deployment based upon the above considerations. • Factor A80: Determination of the number of internal forwarder DNS servers required, and minimum hardware specifications ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the use of one or more internal forwarder DNS servers, and  Wishes to determine the actual number of servers required, and the design requirements for the minimum hardware specifications for this DNS server role ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Consider the following factors when determining the actual number of internal forwarder DNS servers required within each logical and physical location within an organisation identified as potentially suitable for hosting one or more local internal forwarder DNS servers:  The redundancy requirements for inter-namespace name resolution services provided by a internal forwarder DNS server  The performance requirements for inter-namespace name resolution services provided by a internal forwarder DNS server

Page 267 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The financial and administrative overheads associated with the number of internal forwarder DNS servers required  Requirements for service autonomy, service isolation, and data isolation  The use of the internal forwarder DNS server role as an actual or virtual DNS server role It is possible to achieve fault tolerance for external (and specifically Internet) name resolution services provided by forwarder DNS servers via the use of multiple forwarder DNS servers, placed in different geographical locations, and each with discrete network access to the external / Internet network. This configuration also permits the isolation and segregation of name resolution traffic that could potentially traverse low bandwidth inter-location network links. The use of multiple forwarder DNS servers is possible (see later for details) via the entry of IP addresses for multiple forwarder DNS servers for each conditional forwarder entry on a DNS server. When determining the number of internal forwarder DNS servers required, to maintain performance of the inter-namespace name resolution services, consider the following information:  Name queries sent to a forwarder DNS server from a DNS server are recursive queries. This shift in onus for handling the name resolution request places hardware (CPU cycles, RAM, network) resource demands upon the forwarder DNS server.  Where a dedicated forwarder may receive a large number of recursive name queries, then the performance of this server will decline, thus lengthening the time required for the resolution of a name query. Distributing the workload of a forwarder amongst more than one DNS server will thus increase the performance of the name resolution service.  Consider the use of a network load-balancing cluster to distribute name resolution requests between multiple forwarder DNS servers. Capacity testing may be required to establish the minimum number of actual or virtual forwarder DNS servers that are required for an organisation, based upon operation of the servers within pre-defined threshold values for CPU, network, disk and memory usage, against simulations of predicted volumes and frequencies of recursive name queries from DNS servers. When considering the financial and administrative overheads associated with the number of internal forwarder DNS servers required for each location, consider the following information:  In most medium to large organisations with multiple external network connection points, and distributed concentrations of DNS clients, there may be the requirement for the use of two or more internal forwarder DNS servers. The additional nature of the requirement to placement these servers within firewall-partitioned network segments restricts their use as virtual DNS servers, as does the high server hardware resource requirements for this DNS server role. Hence, it is important to consider the financial overheads associated with the provision of external internamespace name resolution services within an organisation via the use of multiple internal forwarder DNS servers.  The placement requirements for forwarder DNS servers providing external internamespace name resolution services requires an additional administrative overhead in assuring the integrity of these servers within firewall-partitioned network segments. Once an internal forwarder server is deployed and appropriately configured, it does require regular monitoring as it may utilise significant hardware resources.

Page 268 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When determining the number of internal forwarder DNS servers required, to support requirements for service autonomy, service isolation, and data isolation, consider the following information:  Where an organisation is composed of one or more autonomous sub-divisions, then there may be the requirement to separate inter-namespace name resolution services provided by an internal forwarder DNS server. For example, autonomous divisions within different geographic locations may wish to use local external network connection points and local external DNS servers for their internal forwarder DNS servers.  The use of Internet name resolution services may be critical to the continuity of the business processes within, for example, an autonomous sub-division of an organisation. In these scenarios, there may be the requirement for the design and deployment of discrete internal forwarder DNS servers to permit independent control and management of this critical service, and thus maintain compliance with SLAs, and so on  An internal forwarder DNS server dedicated to the provision of external internamespace name resolution services may not host any local DNS zones, and thus, no DNS zone data. Hence, the design and deployment of multiple internal forwarder DNS servers to meet requirements for data isolation may not be justified. However, although the data within the local cache has a TTL value (defined by the resource record and authoritative DNS server), it is possible to maliciously access and retrieve this data from the internal forwarder DNS server. Hence, where this is a requirement for data isolation, then the use of discrete internal forwarder DNS servers that are carefully controlled and managed, with respect to use and access, may meet these requirements. Consider the use of multiple forwarder DNS servers to meet the requirement to prevent (where possible) recursion via the Internet, by ensuring a separation between intranet and Internet name resolution requests. For example, an organisation has a multiple DNS namespace infrastructure, with each namespace registered for use on the Internet, and used internally to support an Active Directory infrastructure. With a dedicated “internal forwarder DNS server”, it is possible to route all name requests for these namespaces internally, without the requirement to resolve them via an external root DNS server on the Internet. The internal DNS forwarder could route, for example, all name requests to a corresponding internal root DNS server authoritative for the target namespace. It is possible to configure this solution using conditional forwarders on internal DNS servers to forward name resolution requests for any namespace / domain component of a namespace used internally within the organisation, to a dedicated internal forwarder DNS server. Forward all other name requests for namespaces external to the organisation to a dedicated “Internet forwarder DNS server” that, for example, resides within a DMZ for an organisation. When determining the requirement for the deployment of internal forwarder DNS servers as actual (dedicated) servers or as virtual servers, consider the following:  As stated earlier, an internal forwarder DNS server may have high (hardware) resource utilisation requirements due to the nature of the service it provides. Consider the use of a dedicated forwarder DNS server where performance statistics show a detrimental performance profile for this role (when operating as a virtual server role) within the production (or a simulated) environment.  The placement requirements for internal forwarder DNS servers required to perform external inter-namespace name resolution may require the use of an actual

Page 269 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

forwarder DNS server. A virtual forwarder DNS server may be considered where a high specification server is available within the required location (a firewallpartitioned network segment), and it demonstrates a low resource utilisation profile. When determining the design requirements for the minimum hardware specifications for an internal forwarder DNS server, consider the following information:  If there is the requirement to configure an internal forwarder DNS server to receive, pre-dominantly recursive queries from other DNS servers, then the onus on name resolution shifts to this server. Hence, this server will be required to utilise more server hardware resources, such as CPU cycles and RAM than a DNS server receiving predominantly iterative queries.  If an internal forwarder DNS server is not to host any local DNS zones, and is dedicated to the resolution of outgoing external inter-namespace name queries, then the disk requirements for this server role will be minimal. Using the above information, execute the following:  Determine and document the number of actual internal forwarder DNS servers required within each appropriate logical and physical location to meet requirements for redundancy, performance, service autonomy, service isolation, data isolation, and financial and administrative overheads.  Determine and document the number of virtual internal forwarder DNS servers required, and the identification of the:  Primary function(s) of the server the virtual internal forwarder DNS server will be operating upon  The presence of any other virtual DNS server roles (such as caching-only DNS server roles) on the same server  The logical and physical locations for these virtual internal forwarder DNS servers  Determine and document the support scope for each internal forwarder DNS server to be designed and deployed (namespaces it will forward received name queries to, and namespaces it will receive name queries from).  Determine and document the minimum hardware requirements for the acceptable performance and operation of an internal forwarder DNS server role, as an actual or virtual server.  Determine and document the requirements to upgrade hardware specifications where, for example, virtual internal forwarder DNS servers are required to operate upon servers with high utilisation requirements for hardware resources to serve another primary function. • Factor A81: Determination of the standard configuration requirements for the internal forwarder DNS server role ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and deployment of one or more internal forwarder DNS servers, and  Wishes to determine the configuration requirements for this server role

Page 270 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the configuration requirements for internal forwarder DNS servers, it is important to consider the expected functions for this role within the DNS infrastructure of an organisation. As discussed above, it is possible for an internal forwarder DNS server to perform internal and / or external inter-namespace name resolution. It is also possible to use an internal forwarder DNS server, due to its recommended placement configuration, to either only send out inter-namespace name queries to external DNS servers, or to also receive inter-namespace name queries from external DNS servers. When determining the configuration requirements for an internal forwarder DNS server configured only to resolve internal inter-namespace name queries, consider the following:  The internal forwarder DNS server, within this function, will be required to resolve queries for resource records only held within other internal DNS namespaces. Hence, to perform this function, this server may be configured with either root hints to one or more internal root DNS servers, conditional forwarder entries to DNS servers authoritative for the root DNS zones of the appropriate internal DNS namespaces, or stub zones for the root DNS zones of the appropriate internal DNS namespaces.  When determining the appropriate configuration options for this function, note the order in which the DNS server uses these configuration options. First, the local cache, then local DNS zones, then forwarder / conditional forwarder entries, and finally root hints.  Note that the use of conditional forwarders offers a slightly better performance profile than the use of stub zones. When determining the configuration requirements for an internal forwarder DNS server configured only to send out external inter-namespace name queries, consider the following:  The internal forwarder DNS server will require root hints configured to point to one or more external root DNS servers. These may be the Internet root DNS servers, or they may be the DNS servers owned and managed by an ISP for the organisation.  There will be no requirement to configure conditional forwarder entries or root hints on this server to point to internal DNS servers, as the forwarder DNS server is not to receive external queries for internal host or service names. When determining the configuration requirements for an internal forwarder DNS server configured to send and receive external and internal inter-namespace name queries, consider the following:  The internal forwarder DNS server may require, in addition to the root hints pointing to external root DNS servers, either conditional forwarder entries for internal DNS namespaces pointing DNS server authoritative for these namespaces, or stub zones for internal DNS namespaces.  It is important to ensure that the internal forwarder DNS server, within the context of this function, does not have root hints pointing to any internal root DNS servers. If it is not possible for the internal forwarder DNS server to contact any external root DNS servers, this may result in an endless name query loop between internal forwarder and internal root DNS servers.  Consider securing the internal forwarder DNS server, by (for example):

Page 271 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Setting the access control list (ACL) on: • The “%systemroot%\system32\DNS” folder, subfolders, and files to remove the “Authenticated Users” permissions • The registry key “HKLM\System\CurrentControlSet\Services\DNS” to Administrator and System as “Full Control”, and remove the “Read” permissions for “Authenticated Users”  Disabling all unnecessary services on the server Where there is a requirement to design and implement multiple “forwarder” DNS servers (as the role for a DNS server), then ensure that there is no chaining of (internal or external) forwarder DNS servers. For example, avoid the following scenario where a DNS forwarder server (DNS1) has a configuration of a normal forwarder or a conditional forwarder to send a received (recursive) name resolution query to another internal forwarder DNS server (DSN2). It is important to avoid this inefficient name resolution strategy and pathway. Conditional forwarder entries on an internal forwarder DNS server should only point to authoritative DNS servers. Using the above information, execute an analysis to determine and document the standard configuration requirements for internal forwarder DNS servers. The configuration requirements must reflect the expected functions these servers will be required to perform, and those parameters that require discrete consideration and configuration for each required internal forwarder DNS server. • Factor A82: Determination of the design requirements for the logical and physical placement of internal root DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the use of internal root DNS servers (from the results of the analysis to determine the design requirements for a name resolution strategy), and  Wishes to determine the design requirements for the logical and physical placement of these DNS servers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objectives for the use of internal root DNS servers are to facilitate internal intraand inter-namespace name resolution. When determining the logical and physical placement requirements for the internal root DNS server role to meet the stated objectives for this role, consider the following information:  The DNS clients of an internal root DNS server may be Windows DNS clients or internal DNS servers. Hence, there is a requirement to consider the geographic distribution of these DNS clients within the organisation, and their logical distribution within the supporting network infrastructures of the organisation.  The requirements for redundancy of the internal intra- and inter-namespace name resolution services provided by the internal root DNS servers will influence the placement requirements for this role.

Page 272 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Placement of one or more internal root DNS servers must be within geographic and logical network locations in closest proximity to the highest concentrations of DNS clients and servers configured with root hints to the internal root DNS servers. Consideration of this factor when determining the placement of the internal root DNS servers may assist in reducing network traffic, and increase the performance of the name resolution process. To guard against failures in components of an internal network infrastructure, causing an internal root DNS server to become network isolated from all or some of the DNS clients of this server, consider the distributed placement of this server role within alternate network segments. This will hence provide redundancy of the name resolution service provided by this role by assuring network connectivity to at least one root DNS server. Using the above information, execute the following:  Determine and document the logical and physical locations where an internal root DNS server may be suitable for deployment based upon consideration of:  The distribution of the DNS clients configured with root hints to the internal root DNS servers  The requirements for the redundancy of the internal intra- and inter-namespace name resolution services provided by the internal root DNS server  Determine and document the logical and physical locations where an internal root DNS server may not be suitable for deployment based upon the above considerations. • Factor A83: Determination of the number of internal root DNS servers required, and minimum hardware specifications ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the use of one or more internal root DNS servers, and  Wishes to determine the actual number of servers required, and the design requirements for the minimum hardware specifications for this DNS server role ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: For most organisations, a single internal root DNS server is capable of meeting all internal inter-namespace name resolution requirements. However, other factors that can influence the number of internal root DNS servers required exist and thus require consideration. The following factors may influence the determination of the number of internal root DNS servers required:  Requirements for service autonomy  Requirements for service isolation  Requirements for data isolation  Requirements for redundancy of the internal intra- and inter-namespace name resolutions services provided by the internal root DNS server role

Page 273 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Consideration for the potential / predicted workload on an internal root DNS server and hence the performance of the name resolution services provided by this role  Considerations for the administrative and financial overheads associated with multiple internal root DNS servers  The use of the internal root DNS server role as an actual or virtual DNS server role Where an organisation is composed of one or more autonomous sub-divisions, and each division has their own Active Directory infrastructure, then there may be the requirement to restrict the boundaries of a supporting DNS server infrastructure (and hence internal root DNS servers) to the boundaries of each Active Directory infrastructure. Enforcing this model may thus permit the degree of service autonomy required by a division within the organisation, for the ownership and management of one or more internal root DNS servers. Where there are several such divisions, then the organisation may have multiple internal root DNS servers, with restricted or controlled support boundaries. It is possible to integrate these multiple internal root DNS servers, for internal internamespace name resolution, using conditional forwarders within each internal root DNS server for namespaces that each root has direct or indirect authority over. An autonomous sub-component / division of an organisation may have the requirement to isolate their DNS infrastructure from the parent organisation’s infrastructure or that of other sub-components / divisions within the organisation, to meet requirements for service isolation. Examples for the requirement for service isolation include the need to maintain service levels for name resolution, and requirements to restrict the support scope for a dedicated internal root DNS server. For example, an autonomous division of an organisation provides a business service to its clients, and integrates the DNS infrastructures of the clients with that of the divisions, to permit inter-organisation name resolution, using internal root DNS servers for the division and the client DNS infrastructures as the name resolution bridges between the discrete namespaces. If the division’s dedicated internal root DNS server were to also support the inter-namespace name resolution requirements of other DNS clients and DNS servers within the organisation, this may, for example, degrade the performance of this dedicated internal root DNS server, and thus compromise the service level agreements between the division and its clients. An autonomous sub-component / division of an organisation may have the requirement to isolate their DNS infrastructure from the parent organisation’s infrastructure or that of other sub-components / divisions within the organisation, to meet requirements for data isolation. Examples for the requirement for data isolation include the requirement to restrict access to DNS zone and cached data on an internal root DNS server from other DNS infrastructure within the organisation. For example, a division of a financial service organisation supports an extranet site to permit client organisations access to services hosted by the division. The internal root DNS server for the division will receive name resolution queries from client organisations, and send out name resolution queries to client organisation from within the division. The cache within the internal root DNS server will hold details of the clients for this division (client identity may be illustrated by the namespaces within the cache), and the name server RRs for DNS zones within the clients. This information, accessed via malicious means and distributed to 3rd-part organisations, may compromise, for

Page 274 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

example, the business relationship between the client and the division, where client anonymity was a requirement for the business relationship. When determining the numbers of internal root DNS servers that are required to support the internal intra- and inter-namespace name resolution requirements, consider the redundancy requirements for this valuable name resolution service. As for the other DNS server roles, the failure of this server role may disrupt business continuity, especially where line-of-business applications and processes depend upon these name resolution services. The use of multiple internal root DNS servers may provide redundancy for these services. Within a large organisation, that has many DNS clients, multiple DNS namespaces, and a large volume of inter-namespace name resolution queries, a single internal root DNS server for the entire organisation may not be sufficient to respond to all queries in a timely manner. To distribute the workload on the internal root DNS server and improve performance of name resolution, it may hence be necessary to design and deploy more than one DNS server. Assuming name queries are sent exclusively to an internal root DNS server using root hints from other internal DNS servers, then an internal root DNS server (that is not a forwarder) will receive recursive name queries and hence will predominantly be using CPU, network, disk and memory resources. Capacity testing may be required to establish the minimum number of dedicated (or multi-function) internal root DNS servers that are required for an organisation, based upon operation of the servers within pre-defined threshold values for CPU, network, disk and memory usage, against simulations of predicted volumes and frequencies of name queries from DNS clients. Where an organisation may require the design and deployment of multiple dedicated (or multi-function) internal root DNS servers, then consider the following management, and financial overheads:  For each dedicated internal root DNS server required, there is a financial and administrative overhead associated with the server hardware and maintenance costs, respectively.  Where the support scope for two or more internal root DNS servers is the same (thus created for load-balancing of name resolution queries), there will be an administrative overhead associated with the synchronisation of the configuration information for these two DNS server to maintain their operational functionality as root DNS servers. For example, if a root DNS server is to hold a stub zone for a namespace, then it will be necessary to re-create that same stub zone on every other internal root DNS server that shares the same support scope.  Where there are multiple internal root DNS servers that share the same support scope, the caches will not be the same on each server, and hence not as authoritative as the cache for a single internal root DNS server that would receive all internal name queries sent via root hints.  Where there is a requirement to design and deploy multiple internal root DNS servers that have differing support scopes, it will be necessary to design multiple name resolution strategies, and where required, the integration of each name resolution strategy via the multiple internal root DNS servers. This hence has a financial impact on the total cost of ownership of each DNS infrastructure with discrete internal root DNS servers. When determining the requirement for the deployment of internal root DNS servers as actual (dedicated) servers or virtual servers, consider the following:

Page 275 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 As stated earlier, depending upon the source and types of the majority of name queries an internal root DNS server receives, the resource utilisation requirements may be quite high. Consider the use of a dedicated internal root DNS server where performance statistics show a detrimental performance profile (when operating as a virtual server role) within the production (or a simulated) environment.  The placement requirements for this server role do not influence the use of actual or virtual internal root DNS servers. Using the above information, execute the following:  Determine and document the number of actual internal root DNS servers required, and the justifications for their creation (for service isolation and autonomy, data isolation, load-balancing or workload and so on)  Determine and document the number of virtual internal root DNS servers required, and the identification of the:  Primary function(s) of the server the virtual internal root DNS server will be operating upon  The presence of any other virtual DNS server roles (such as standard DNS server roles) on the same server  The logical and physical locations for these virtual internal root DNS servers  Determine and document the support scope for each internal root DNS server to be designed and deployed (namespaces it will forward received name queries to, and namespaces it will receive name queries from)  Determine and document the minimum hardware requirements for the acceptable performance and operation of a internal root DNS server role, as an actual or virtual server  Determine and document the requirements to upgrade hardware specifications where, for example, virtual internal root DNS servers are required to operate upon servers with high utilisation requirements for hardware resources to serve another primary function • Factor A84: Determination of the standard configuration requirements for the internal root DNS server role ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and deployment of one or more internal root DNS servers, and  Wishes to consider the technical configuration requirements for this server role ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the configuration requirements for the internal root DNS servers, consider the following information:  It is important to determine whether an internal root DNS server is to be a dedicated root server, or serve multiple functions. Discussed earlier, within the considerations for the determination of the number of internal root DNS servers required for a DNS infrastructure, are the considerations for the use of a dedicated or multi-function internal root DNS server.

Page 276 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 If the server is to be a dedicated internal root DNS server, then it should only need the minimum configuration requirements to enable this role. This will hence exclude the use of DNS server features that may be superfluous to the operation of this role, such as the use of primary or secondary root DNS zones for namespaces within the scope of an internal root DNS server. Consider the use of alternatives to primary and secondary root DNS zones, such as the local DNS server cache, stub zones, and conditional forwarders.  If the server is to have a hybrid role, determine whether it is to be authoritative for resolution of inter-namespace name queries via the use of primary or secondary DNS zones, or via the use of cached entries. If the server is to host primary or secondary root DNS zones, or other DNS zones from any of the other namespaces within the scope of this server, then consider the factors listed below for this scenario. When determining the configuration of internal root DNS servers, it is possible to enable this role using one or a combination of a series of DNS server technologies, based upon the requirement for a dedicated or multi-functional internal root DNS server. Presented below are the considerations for the use of each of the following technologies, to enable an internal root DNS server:  Primary DNS zones for the root DNS zones (e.g. “Natsum.com.”) in namespaces within the scope of an internal root DNS server, and delegations to third level child domains (e.g. “ChildA.Natusm.com.”)  Secondary DNS zones for the root DNS zones (e.g. “Natsum.com.”) in namespaces within the scope of an internal root DNS server, and delegations to third level child domains (e.g. “ChildA.Natusm.com.”)  Stub zones for the root DNS zones in namespaces within the scope of an internal root DNS server  Conditional forwarder entries to DNS servers authoritative for the root DNS zones in namespaces within the scope of an internal root DNS server If an organisation is considering the use of an internal root DNS server to host all or some of the root DNS zones for each namespace, as primary zones, then consider the following information:  If an organisation has many domain namespaces that fall within the support scope for an internal root DNS server, then there may be a substantial impact upon the hardware resources of the DNS server. It is important to consider the size of each root DNS zone database, the frequency of change and read requests that the zone will receive, and the corresponding server hardware resources that will be required by the internal root DNS server to support all of the root DNS zones, as primary zones. In addition, consider the impact of any increases in network traffic to and from the internal root DNS server on the performance of the supporting network infrastructure.  Where an organisation has a geographically distributed infrastructure that reflects the distribution of the DNS clients of root DNS zones, it will be necessary to direct all updates, from these clients, to the primary DNS zones on the internal root DNS server. This network traffic may hence use WAN links and thus affect the levels of available bandwidth within these network links during peak business hours.  Where it is possible to identify examples of the constraints on the use of an internal root DNS server to host the primary root DNS zones for all in-scope namespaces, then do not recommend this option. Only consider the use of this option where the impact on, for example, the performance of the internal root DNS server and the

Page 277 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

supporting network infrastructure does not degrade to levels below any specified / pre-determined threshold values. If an organisation is considering the use of an internal root DNS server to host all or some of the root DNS zones for each namespace, as secondary zones, then consider the following information:  The use of a secondary zone of a primary root DNS zone would permit an internal root DNS server to be authoritative for the resource records (RRs) within the root DNS zone and the delegation records for child domains of the namespace, without the overhead of zone maintenance (RR creation, updates, and deletions).  However, there will be a network overhead associated with replication traffic for zone transfers. Where the IXFR protocol is used, this will reduce the volume of traffic for zone transfers, and where scheduled zone transfers are configured (instead of change notification) on the internal root DNS server, then the will reduce / control the frequency of zone transfers. This may be essential where the DNS servers hosting the primary root DNS zones are in locations remote to an internal root DNS server.  The use of secondary zones on an internal root DNS server may enable an internal root DNS server to respond authoritatively to internal inter-namespace name queries, or assist in their resolution. If an organisation is considering the use of an internal root DNS server to host all or some of the root DNS zones for each namespace, as stub zones, then consider the following information:  The use of a stub zone (for a primary root DNS zone) on an internal root DNS server presents a minimal overhead for the server (see later for a discussion on the use of stub zones within the “considerations for the determination of the design requirements for the DNS zones of a DNS infrastructure.”)  Because stub zones only hold the name server RRs for a DNS zone, there are minimal storage and zone replication overheads associated with the use of stub zones.  Because the use of stub zones do not make an internal root DNS server authoritative for inter-namespace name queries, but instead permit the server to forward a name query to an authoritative DNS server, their use permits the design and deployment of dedicated internal root DNS servers. The use of conditional forwarder entries on an internal root DNS server permit the server to act as a bridge for inter-namespace name queries within an organisation, between organisations, and between an organisation and the Internet. Note that it is important not to configure standard (non-conditional) forwarder entries on an internal root DNS server. If this is attempted, the internal root DNS server will forward all name queries that cannot resolve (via cached entries, primary, secondary, or stub zones and so on) to a forwarder DNS server. Depending upon the intended direction of the name query sent to the forwarder, this server might not be able to resolve name queries received from the internal root DNS server. For example, if the forwarded name query was for a RR within a non-Internet registered namespace that lies outside of the scope of the internal root DNS server (for example within another DNS infrastructure within the organisation, or in another organisation), then the forwarder will fail to resolve the query. Note, again, that the use of conditional forwarders results in a slightly better performance profile when compared to the use of stub zones.

Page 278 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When determining the configuration requirements for each required internal root DNS server, it is important to determine the source and direction of name queries that the server will be required to provide support in their resolution, within the context of the server’s role in the name resolution strategy. See the factors within the process to determine the design requirements for a name resolution strategy for details of these considerations. An internal root DNS server may be responsible for the support of name resolution requests from within an organisation and possibly from outside of an organisation. Hence, the technical configuration requirements for an internal root DNS server include the ability to be able to resolve:  An iterative name query submitted by an internal DNS server  An iterative name query submitted by a root DNS server from another organisation / DNS server infrastructure  A recursive name query submitted by an external root DNS server or an internal forwarder DNS server An iterative name query from an internal DNS server may be for a RR within the scope of another internal DNS namespace, or it may be for a RR within the scope of an external DNS namespace (on the Internet or within another organisation). The configuration requirements for an internal root DNS server to handle these name queries are:  For a dedicated internal root DNS server, to assist in the resolution of the name query for a RR within another internal DNS namespace, it must be configured with either:  A stub zone that lists the name servers authoritative for the target domain namespace within the name query, or  A conditional forwarder entry pointing to a DNS server authoritative for the target domain namespace within the name query  For a multifunctional internal root DNS server, to assist in the resolution of the name query for a RR within another internal DNS namespace, it must be configured with stub zones or conditional forwarders, as for a dedicated internal root DNS server, or:  A primary root DNS zone for the root domain of the target namespace within the name query, suitably configured with subdomains or delegations for child domains where necessary, or  A secondary zone for a primary root DNS zone for the root domain of the target namespace within the name query  For a dedicated or multifunctional internal root DNS server, to assist in the resolution of the name query for a RR within a namespace external to the organisation, (and hence beyond its scope), it must be configured with:  A conditional forwarder for “All other DNS domains” pointing to a forwarder DNS server that can resolve the name query via the Internet, or  A conditional forwarder for the specific target namespace (if, for example, it resides within another organisation or it is not registered for use on the Internet) via a conditional forwarder entry pointing to, for example, an internal root DNS server within the target organisation

Page 279 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

An iterative name query submitted by a root DNS server from another organisation / DNS server infrastructure will only be for a RR within a DNS namespace within this organisation. Hence, the configuration requirements for an internal root DNS server to handle these name queries are the same as if an internal DNS server submitted the query, since the direction of the name query is the same. A recursive name query submitted by an external root DNS server or an internal forwarder DNS server to an internal root DNS server will only be for a RR within a DNS namespace within this organisation. Again, the configuration requirements for an internal root DNS server to handle these name queries are the same as if an internal DNS server submitted the query, since the direction of the name query is the same. For all internal root Windows Server 2003 DNS servers, there will be the requirement to delete the default cache.dns file (located by default within the “%systemroot%\system32\dns” folder) (or simply delimit the root server entries within the file using a semi-colon), and not to configure root hints on any internal root DNS servers. Using the above information, execute an analysis to determine and document the standard configuration requirements for internal root DNS servers. The configuration requirements must reflect the functions the servers will be required to perform, and those parameters that require discrete consideration and configuration for each required internal root DNS server. • Factor B34: Reviewing an example of a modular approach towards the development of standard DNS server role configurations ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to review an example of a modular approach towards the development of standard DNS server role configurations, for a standard, caching-only, internal forwarder, and internal root DNS servers. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The following illustration is an example of the modular approach an organisation may adopt for the development of standard DNS server role configurations. Within this example, the organisation has determined the following configuration requirements:  The organisation has determined the requirements for standard, caching-only, internal forwarder, and internal root DNS server roles.  No internal forwarder DNS servers will host DNS zones. Only standard and internal root DNS servers will host DNS zones.  There will be no non-conditional forwarder entries configured for the internal forwarder DNS server. This role may have, however, conditional forwarder entries for internal namespaces. Hence, recursion will be required for this role.  The internal root DNS server role will only participate in the resolution of internal intra- and inter-namespace name queries. This role will not participate within routine DNS zone replication and update operations, as these operations are exclusively within the scope of the standard DNS server role. Hence, the internal root DNS server will not require configuration for integration with any DHCP or WINS infrastructures. The internal root DNS server will require the configuration of root hints, and hence the “configuration of root hints” component will involve the removal of the default cache.dns file on the DNS server.

Page 280 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The caching-only DNS server role will not host any DNS zones, and hence does not require any DNS zone-related configurations. START

(Custom) TCP/IP Configuration for each NIC

Protection against Cache Pollution

Name Checking Method

DNS Server initialisation and boot method

DNS Event Logging Mode

Baseline configuration options for all DNS Servers Custom configuration options for internal forwarder DNS Servers

+

+ +

Disabling of Recursion Internal Forwarder DNS Server

Configuration of Root Hints

Configuration of Conditional Forwarder Entries

Custom configuration options for caching-only DNS Servers
Disabling of Recursion Configuration of Root Hints Configuration of Forwarder Entries Configuration of Conditional Forwarder Entries Caching-Only DNS Server

Baseline configuration options for all DNS Servers to host DNS zones
DNS Zone Storage Requirements DNS Zone Creation Requirements DNS Zone Population Requirements DNS Zone Maintenance Requirements DNS Zone Replication & SOA Requirements

Custom configuration options for standard DNS Servers

+

Disabling of Recursion Configuration of Scavenging and Aging at the Server Level Integration of DNS with WINS

Fast Zone Transfers for BIND Secondaries

Fail Zone Load on Bad Data

Use of DNS Round Robin

Use of DNS Server Subnet Prioritisation

Configuration of Root Hints

Configuration of Forwarder Entries

Configuration of Conditional Forwarder Entries Configuration of SOA “Primary Server” Field

Integration of DNS with DHCP Standard DNS Server

Determination of Required DNS Zone Types

Configuration of SOA “Responsible Person” Field

Configuration of Name Server Resource Records

Custom configuration options for internal root DNS Servers
Disabling of Recursion Fail Zone Load on Bad Data Configuration of Scavenging and Aging at the Server Level Configuration of the SOA “Responsible Person” Field Configuration of Root Hints Configuration of Forwarder Entries

+
Internal Root DNS Server
R

Configuration of Conditional Forwarder Entries

Determination of Required DNS Zone Types

Configuration of the SOA “Primary Server” Field

Configuration of the Name Server Resource Records

© 2004 MUSTANSHI

BHARMAL

Figure 6.26: Example of a Modular Approach towards the Development of Standard DNS Server Role Configurations Note that this illustrated example of a modular approach to the design of configuration requirements for DNS server roles is just an example. The actual configuration requirements for an organisation must be independently determined from the business and technical requirements for the DNS infrastructure to support the defined scope of the Active Directory infrastructure.

Page 281 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

5.9.6.1.7.

Determination of the Design Requirements to Build, Deploy, and Configure the DNS Servers

This step requires execution where an organisation can identify compliance with either of the following requirements: 1. An organisation is following “Track 1” or “Track 2” of this process (has no current DNS server infrastructure), and wishes to determine the design requirements for the process to build, deploy, and configure the identified Windows Server 2003 DNS servers, or An organisation is following “Track 3” of this process (has one or more existing DNS servers) and has identified the requirement for the design, build, deployment and configuration or one or more new DNS servers additional to the current DNS servers estate

2.

Where it is possible to identify compliance with either of the above requirements, consider the information when determining the design requirements for the process to build, deploy, and configure the required DNS servers: • Factor B35: Understanding the approach to determine the design requirements for the process to build, deploy, and configure the required DNS servers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, to determine the design requirements for the process to build, deploy, and configure the required DNS servers. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The deployment of DNS servers within a DNS infrastructure has the following three distinct sub-phases:  Build phase: This phase involves the execution of tasks necessary to ensure the successful installation of the DNS server software on the appropriate servers within an organisation. This phase has pre-build, build, and post-build tasks.  Deployment phase: This phase involves the execution of tasks necessary to ensure the successful installation of the server to host the DNS server service onto the production network infrastructure for an organisation. This phase has predeployment, deployment, and post-deployment tasks.  Configuration phase: This phase involves the execution of tasks necessary to ensure the appropriate configuration of all required DNS servers to perform all of their intended functions within the DNS infrastructure, to support the Windows Server 2003 Active Directory infrastructure. The sequence for execution of these phases may differ, depending upon specific business and technical requirements. However, the following logical rules apply:  The configuration phase must be preceded by either the build or deployment phase  The execution sequence for the build and deployment phases are interchangeable, depending upon business and technical requirements This design methodology proposes execution of the following approach to determine the design requirements for the process to build, deploy, and configure the identified DNS servers:  Determine the design requirements for the build tasks

Page 282 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine the design requirements for the deployment tasks  Determine the design requirements for the configuration tasks • Factor A85: Determination of the design requirements for the build tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the build tasks for the required DNS servers. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the tasks required for the execution of the pre-build phase, consider the following:  It is necessary to determine whether a required DNS server will install onto a server as the:  Sole function of that server, and hence the server will serve no other function, such as file and print server, domain controller, and so on  Primary function of that server, and hence the server will serve other functions, such as file and print server, that can be operated as secondary services. Secondary functions are those that use fewer server hardware resources than primary functions on a server. Note that the domain controller function would be a primary function due to the excessive hardware requirements for this service.  Shared function of that server, where the DNS server service is to operate in conjunction with other services that share a similar hardware utilisation profile, such as WINS, or DHCP services (collectively termed “infrastructure services”).  Secondary function of that server, where the DNS server service is to operate in conjunction with another primary service that has a higher hardware utilisation profile, such as the domain controller service.  Where a DNS server will install onto a server as the sole function of that server, then the deployment process for that DNS server is independent of the deployment processes for other server functions.  However, where a DNS server will install onto a server as the primary, shared, or a secondary function on that server, and where that server does not currently exist, consideration will be required for the dependencies or influences generated by the deployment processes for the other functions of that server. For example, where the primary function of a server is the Windows Server 2003 domain controller service, and the Windows Server 2003 DNS server service will install as a secondary service, then consider the following:  The deployment process for the domain controller will influence the deployment process and schedule for the Windows Server 2003 DNS server.  The installation of the domain controller service may influence the build tasks for a Windows Server 2003 DNS server. For example, the scripted or manual installation of the domain controller service on a Windows Server 2003 server can concurrently install, and configure, the Windows Server 2003 DNS server software on that server.  Determine the existence of any other dependencies that require consideration as they may influence the deployment of the DNS server software on the target server. For example, the DNS server software will require installation onto a new server

Page 283 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

hardware platform. There will hence be the dependency on the completion of the procurement, assembly, and configuration processes for the new server.  Determine the required mode for installation of the DNS server software onto the target server. For example, determine whether the DNS server software will require manual installation by an administrator, or unattended installation via a script or the DCPROMO wizard.  Determine the source and version of the DNS server software files (within the i386 folder). For example, if the organisation has standardised upon a specific service pack version of the DNS server software, then ensure the use of source files of this required version only, and ensure the appropriate location for these files, depending upon the required mode for installation. When determining the influence of the selected mode of installation of the DNS server on the sequence of steps within the deployment phase, consider the following:  Where there is the requirement to install the DNS server software onto a remote server manually via, for example, a remote administrator session, then the server will require deployment onto the production environment prior to the execution of the build tasks. Hence, the sequence of steps within the deployment phase may be “deployment build configuration”.  Where there is the requirement to install the DNS server software via an unattended installation script for the operating system, using, for example, a scripted bootable CD-ROM, then it is possible to execute all build tasks prior to the deployment of the server onto the production environment. Hence, the sequence of steps within the deployment phase may be “build deployment configuration”. In this scenario, there are no dependencies upon obtaining the source files via a network connection to another server on the production network infrastructure.  Where there is a requirement to install the DNS server software via an unattended installation script for the operating system, using, for example, a network installation from source files on a file server on the production network, then it is only possible to execute the build tasks following completion of the deployment tasks. Hence, the sequence of steps within the deployment phase may be “deployment build  configuration”. When determining the tasks required for the execution of the post-build phase, consider the requirement to identify post-build tests, and criteria for success or failure of the tests, to verify the successful installation of the DNS server software on the target server. Examples of tests include:  The determination of the operation of the DNS server service  The determination of the ability to stop, pause, and restart the DNS server service  The determination of the ability to connect to the DNS server via a DNS snap-in for a Microsoft Management Console (MMC) and view the properties of the DNS server Using the information above, execute the following:  Determine and document, for each identified DNS server, whether the service is the sole, primary, secondary, or shared function on the target server  Determine and document the position of the build process within the sequence of steps within the deployment phase, based upon the required mode of installation of the DNS server software  Determine and document the required pre-build, build, and post-build process tasks for each identified DNS server within the DNS infrastructure.

Page 284 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the required sequence of the phases based upon the build tasks • Factor A86: Determination of the design requirements for the deployment tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the deployment tasks for the required DNS servers. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: In order to deploy a DNS server onto the production network infrastructure, it is necessary to determine, collate, and document a number of specific deploymentspecific information. Although the onus is with the organisation to determine the specific deployment information required, as this is unique to each organisation, this design methodology provides the following examples of information required for each DNS server, which require execution as pre-deployment tasks:  Determine the required TCP/IP configuration information (allocated IP addresses, subnet mask, default gateway information, and so on) for each network interface card (NIC) on the DNS server, within the production network infrastructure of an organisation.  Determine the network connection details for each NIC on the DNS server, identifying, for example, the switches / hubs to which each NIC will connect, the patch cables to be used (including colour of cables used, where appropriate) and so on.  Determine the physical location details for the server, identifying, for example, the server room, the server rack, the position within the server rack, and so on.  Where a DNS server is to reside within a firewall-partitioned network (DMZ), then there will be the requirement to define (inbound / outbound) firewall policies that open the appropriate TCP and UDP ports (53). When determining the tasks necessary to deploy the required DNS servers within the production network infrastructure, consider the following:  Determine any requirements to centralise or decentralise the execution of the deployment phase tasks for the DNS servers, via consideration of the following:  Factors such as the presence of autonomous divisions within an organisation, the geographical distribution of the required DNS servers within the organisation, and so on will influence the requirement to decentralise the deployment tasks for the DNS servers.  Factors such as the presence of only a single geographical location for an organisation, or the presence of a centralised IT administration team, will influence the requirement to centralise the deployment of the DNS servers.  Whether there is a requirement to decentralise or centralise the deployment tasks, it may still be necessary to produce, for the local administrators responsible for executing the deployment tasks, written instructions. The instructions may detail, for example, the tasks necessary to install the server into the appropriate location, and connect the server to the production network infrastructure. When determining the tasks necessary, to execute the post-deployment phase, consider the following:

Page 285 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 In order to verify the correct deployment of the DNS servers, it may be necessary to produce:  A checklist for verification of executed deployment tasks  A series of tests and test criteria to verify the successful deployment of the DNS server  The tests to verify the successful deployment of the DNS server on to the production network infrastructure may include the following example tests:  “Ping” tests to verify network connectivity  “tracert” tests to verify network connectivity (where, for example, a DNS server resides within a firewall-partitioned network (DMZ)) and correct router configuration  Where the DNS server is to reside within a firewall-partitioned network (DMZ), consider the use of telnet sessions to attempt connections to TCP port 53 (note that UDP port 53 should also be opened on the firewall, but the Windows Server 2003 “HyperTerminal” telnet utility will only test TCP port connections). Using the above information, execute the following:  Determine and document all pre-deployment, deployment, and post-deployment tasks for each new required DNS server, based upon its logical and physical placement requirements within the organisation.  Determine and document the required sequence for execution of the phases, based upon the requirements for the deployment tasks. • Factor A87: Determination of the design requirements for the configuration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the configuration tasks for the required DNS servers. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the tasks necessary to execute the pre-configuration phase, consider the following:  It is necessary to ensure that all administrators, tasked with the configuration of the new required DNS servers, comply with the following:  They all understand the standard and custom configuration requirements for each DNS server to be configured  They all have access to, or appropriately supplied with, all configuration instructions appropriate to the DNS servers they are responsible for configuring.  Hence, there may be the requirement to brief all administrators on the steps that require execution within each process, and ensure access or distribution of all appropriate instructions. The determination of the configuration tasks for the identified DNS servers depends upon the following:  The requirements for the centralised or decentralised deployment of the DNS servers

Page 286 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The selected mode for implementation of the required configuration options on the DNS servers When determining the influence of the requirement for the centralised configuration of the required DNS servers, consider the following factors:  The presence of autonomous divisions of an organisation within a DNS infrastructure can influence the requirement for centralised configuration of DNS servers. Autonomous divisions within an organisation typically wish to retain administrative control over their server infrastructure. This hence implies a decentralised administration model that may extend to the DNS servers within the DNS infrastructure. Where this scenario is true, then there may be a requirement to permit decentralised configuration of the DNS servers, and provide written instructions and a checklist for local administrators to execute this phase of the deployment of their DNS servers.  Consider any differences in the languages for the administrators of an autonomous division that may be in a different country, when producing the written instructions.  The physical distribution requirements for the DNS servers for a DNS infrastructure within an organisation can influence the requirement for centralised configuration of DNS servers.  Where DNS servers within a DNS infrastructure will require distribution over multiple remote geographical locations for an organisation, then it may not be possible to perform the majority of configuration tasks on these servers from a central location, as they typically require manual execution. It is not feasible or possible in most cases to build and configure DNS servers centrally and then ship them to remote locations. Hence, the configuration tasks for these DNS servers will require execution locally at each location.  Where there is a requirement to permit local execution of the configuration tasks, provide written instructions and checklists for all identified tasks specific to the remote DNS servers.  The presence or absence of skilled or trustworthy administration resources in remote locations can influence the requirement for centralised configuration of DNS servers. Where a remote location does not have skilled or trustworthy resources, then there may be the requirement to either perform any possible configuration tasks centrally, or automate as many of the configuration tasks as possible. The automation of configuration tasks can assist in reducing user intervention and hence errors in execution of tasks. When determining the influence of the selected mode for implementation on the position of the configuration phase in the sequence of phases, consider the following factors:  Where there is a requirement to configure registry settings on a Windows Server 2003 DNS server using a GPO, then as long as the DNS server is contactable once on the production network, the DNS server does not require configuration prior to deployment on to the production network infrastructure. Hence, the sequence of steps within the deployment phase may be “build deployment configuration”.  Where there is a requirement to complete all configuration tasks manually for DNS servers, then the configuration tasks may require completion prior to deployment of the DNS server on to the production network infrastructure. Hence, the sequence of steps within the deployment phase may be “build configuration deployment”.  Where there is a requirement to complete some specific configuration tasks manually for DNS servers prior to deployment on the production network infrastructure, and the remaining configuration tasks after deployment, then the

Page 287 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

sequence of steps within the deployment phase may be “build pre-deployment configuration deployment post-deployment configuration”. Note that it is only possible to automate the following Windows Server 2003 DNS server installation tasks (both tasks rely upon the use of unattended installation scripts for the Windows Server 2003 operating system):  To automatically install the Windows Server 2003 DNS server software on a Windows Server 2003 Server, via an unattended installation script, create the entry “DNS = 1” within the [NetOptionalComponents] section of a unattend.txt answer file.  Where there is a requirement to install the DNS server software on a domain controller, and allow a scripted DCPROMO wizard to install and configure the DNS server software, then within the [DCInstall] section of a unattend.txt answer file, create the entry “DnsOnNetwork = No”). Note that this option installs the DNS service, creates a valid DNS configuration, and creates a zone for the new domain with that service. When determining the tasks necessary to execute the post-configuration phase, consider the following:  In order to verify the correct configuration of the DNS servers (based upon their intended role within the DNS infrastructure), it may be necessary to produce:  A checklist for verification of executed configuration tasks  A series of tests and test criteria to verify the successful configuration of the DNS server  The tests to verify the successful configuration of the DNS server based upon its intended role within the DNS infrastructure, may include the following example tests:  “ping” and “nslookup” tests to verify name resolution  “ipconfig / registerdns” tests to verify dynamic update configuration of DNS zones (where required) Using the above information, execute the following:  Determine and document all pre-configuration, configuration, and post-configuration tasks for each new required DNS server, based upon its role within the DNS infrastructure  Determine and document the requirements to centrally execute all or selected DNS server configuration tasks  Where this requirement is identified, then determine the specific DNS servers for which configuration tasks are to be centrally executed  Where this requirement is not identified, then determine the: • Specific DNS server for which configuration tasks are to be locally executed, and • The requirements for written instructions and checklists for local administrators to execute the configuration tasks  Determine and document the required sequence for the phases based upon the requirements for the configuration tasks.

Page 288 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

5.9.6.2.

Determination of the Active Directory Design Requirements for a DNS Server Infrastructure Note that some of the following configuration requirements involve the configuration of Windows Server 2003 domain controllers and not the direct configuration of any components of a DNS infrastructure. However, this section on the design of the DNS server infrastructure discusses these configuration requirements as they relate specifically to Microsoft DNS SRV resource records for Active Directory. Note also that as the configurations detailed below have very specific scopes for application, they do not require consideration as components of the standard configurations for any of the DNS server roles defined and discussed earlier. Hence, consider these advanced configurations for design and implementation as “fine-tuning” of the integration of Active Directory with the DNS infrastructure. Consider the following information when determining the specific Windows Server 2003 Active Directory requirements that will influence the design of the supporting DNS server infrastructure: • Factor B36: Understanding the influence of Active Directory on the determination of the number of DNS server infrastructures required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of Active Directory on the number of DNS server infrastructures required within a DNS infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: An organisation can have one or multiple actual or virtual DNS server infrastructures. The aspects of a Windows Server 2003 Active Directory infrastructure that will influence the number of DNS server infrastructures required by an organisation are:  The representation of autonomous divisions within the Active Directory infrastructure for the organisation ay lead to, for example, discrete owners for each Windows Server 2003 Active Directory forests that requires design and deployment within an organisation.  The presence of autonomous divisions within an organisation that discretely own one or more of the DNS namespaces to be represented within the Windows Server 2003 Active Directory infrastructure, and hence requires support from a DNS infrastructure. Due to the critical dependency of a Windows Server 2003 Active Directory forest on a supporting DNS server infrastructure, owners of Windows Server 2003 Active Directory forests, created to permit service autonomy and / or isolation, may wish to exert their autonomous or service isolated status and requirements upon a supporting DNS server infrastructure for their forest. A forest owner may be the parent organisation or a division of an organisation, and may not be restricted to a single forest. Hence, there may be a requirement to design and deploy a discrete DNS server infrastructure to support all of the forests owned by a forest owner. An organisation may wish to create multiple DNS server infrastructures partitioned against the ownership of each DNS namespace that will require representation within a Windows Server 2003 Active Directory infrastructure for an organisation. Take for example an organisation with multiple autonomous divisions, and multiple DNS namespaces. The ratio of DNS namespaces to Windows Server 2003 Active Directory forests is many to few, and the ratio of DNS namespace owners to DNS namespaces is

Page 289 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

few to many. Hence, for example, one autonomous division or the parent organisation may own many DNS namespaces, represented within one or more Windows Server 2003 Active Directory forests. Hence, a single discrete DNS server infrastructure may support all the DNS namespaces owned by a single division / organisation. It is possible to design multiple DNS server infrastructures partitioned using just forest owners or just DNS namespace owners, and thus a produce a strict design model for a DNS server infrastructure. Alternatively, it is possible to use a combination of these design models to create a hybrid design model that will produce one or more DNS server infrastructures aligned to forest owners and one or more DNS server infrastructures aligned to DNS namespace owners, where possible. This design methodology strongly recommends the design and deployment of as few DNS server infrastructures as possible, to reduce the administrative and financial overheads associated with each infrastructure. • Factor A88: Determination of the requirement to partition and replicate the Active Directory Service Location Domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of one or more Active Directory forests, with multiple domains within each forest,  Has identified the requirements for the design and use of two or more DNS servers within a DNS infrastructure  Has identified the requirements for the implementation of multiple DNS servers in different physical locations to the DNS server(s) authoritative for the DNS zone that supports the forest root domain, and  Wishes to determine the requirements to partition and replicate the Active Directory service location domains (“_msdcs”, “_tcp”, and “_sites”) into separate DNS zones, or alternatives to partitioning and replication ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The “_msdcs”, “_tcp”, and “_sites” are specific to Microsoft Windows 2000 and Windows Server 2003 Active Directory infrastructures, and contain the service (SRV) location resource records to permit the location of domain controllers, Global Catalog servers, Kerberos services and so on. Every DNS zone for a domain within an Active Directory forest has the “_msdcs” subdomain, but only the “_msdcs” subdomain within the DNS zone for the forest root domain contains the listing of the Global Catalog servers for a forest. Hence, when a user logs on, the user's computer must contact a DNS server to locate a global catalog server for the forest. If the “_msdcs” zone for the root domain of the forest is not contained on the designated DNS server for the client computer, then the designated DNS server must contact DNS servers that contain that zone. A “deployment best practice” states that the “_msdcs” subdomain within the DNS zone for the forest root domain requires “replication to the DNS servers running on all domain controllers within the forest, to permit the location of replication partners for domain controllers, and Global Catalog servers”. However, within the production infrastructures of some organisations, this recommendation may not be realistic.

Page 290 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

For example, not all DNS servers may be operating on domain controllers (and hence able to access Active Directory integrated DNS zones), and not all DNS servers may be using the Windows 2000 or Windows Server 2003 DNS server software, but instead using compatible third party DNS server software, such as BIND DNS. Thus, in these scenarios, it may be necessary to use normal zone transfers to distribute the “_msdcs.<forest_root_domain>” subdomain DNS zone to all appropriate DNS servers. Hence, the associated network traffic generated by the replication of this zone to all DNS servers within the forest may be substantial. There may also be the requirements to design custom replication topologies for this DNS zone, to permit the distributed replication of the zone, in a hierarchical manner. Hence, this design methodology proposes the following alternatives to the replication of the “_msdcs.<forest_root_domain>” subdomain to all appropriate DNS servers within a forest:  The use of a root hint to a DNS server authoritative for the “_msdcs.<forest_root_domain>” subdomain of the DNS zone for the forest root domain (for example, an internal root DNS server)  The use of a conditional forwarder entry for the “_msdcs.<forest_root_domain>” subdomain, with (for example) several IP addresses (listed top down in order of closest network proximity) for DNS servers authoritative for the “_msdcs.<forest_root_domain>” subdomain of the DNS zone for the forest root domain Which ever method is chosen to permit access to the SRV resource records within the "_msdcs.<forest_root_domain>" subdomain of the DNS zone for the forest root domain of a forest, it is important to also ensure the availability of this critical DNS zone. This is possible via the replication of this zone to at least two or more other DNS servers, and / or storage of the DNS zone data for this zone within either a default or custom Active Directory ADP. Using the above information, execute an analysis to determine the required approach to meet the requirements for the access of the SRV resource records within the "_msdcs.<forest_root_domain>" subdomain of the DNS zone for the forest root domain of a forest. The possible approaches are:  The exclusive use of the approach to ensure replication of the "_msdcs.<forest_root_domain>" subdomain to all DNS servers on all domain controllers within the forest (the “deployment best practice” approach)  The exclusive use of root hints and / or conditional forwarders for the "_msdcs.<forest_root_domain>" subdomain pointing the one or more DNS servers authoritative for this DNS zone, or  A hybrid approach combining both of the above approaches to ensure access to these SRV resource records, but without compromising any business or technical objectives and requirements for this component of the DNS infrastructure. This design methodology strongly recommends this approach. • Factor A89: Determination of the configuration requirements for the registration of DC Locator DNS SRV RRs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements to modify the default configuration and operations associated with DNS SRV RRs, registered by the

Page 291 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Netlogon service on domain controllers, to meet specific business and technical objectives. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: By default, all domain controllers (via the Netlogon service, the use of dynamically updatable DNS zones, and the presence of dynamic-update-enabled network connections) dynamically register their DC Locator SRV RRs within the appropriate DNS zone for a domain. However, it is possible to perform the following configurations for the registration of DC Locator DNS SRV RRs:  Disable the dynamic update of the DC Locator SRV RRs by the Netlogon service on a domain controller  Disable the dynamic update of specific SRV RRs by the Netlogon service on a domain controller  Configure the time-to-live (TTL) value for the DC Locator SRV RRs dynamically registered by the Netlogon service on a specific domain controller When determining the requirements to disable the dynamic registration of all DC Locator SRV RRs by the Netlogon service on a domain controller, consider the following:  DC Locator SRV RRs are essential to the operation of an Active Directory infrastructure. Without these RRs, clients of the Active Directory would be unable to locate any key Active Directory services such as the Kerberos authentication service, the Global Catalog service, and so on.  The Netlogon service on all domain controllers dynamically registers within the “_msdcs”, “_sites”, “_tcp”, and “_udp” subdomains (within a DNS zone that represents an Active Directory domain) the appropriate SRV RRs that reflect the services offered by a domain controller. Although enabled by default, this feature does rely upon the configuration of the DNS zone to accept dynamic updates, and the configuration of an appropriate network connection on the domain controller to permit dynamic updates.  As this enabled feature is advantageous to the continued and normal operation of an Active Directory infrastructure, only consider disabling the dynamic registration of the DC Locator DNS SRV RRs where it is possible to identify compliance with either or both of the following example criteria within an organisation:  There is a security requirement to prevent all dynamic updates to all DNS zones. This may include dynamic updates performed by: • All domain controllers, via the Netlogon service • All appropriate Windows DNS clients of a DNS zone • All appropriate DHCP servers configured to perform dynamic updates on behalf of DHCP clients • All appropriate cluster nodes, via the cluster service  There is a requirement to prevent one or more specific domain controllers from temporarily registering their SRV RRs within the appropriate DNS zones (configured to permit dynamic updates). For example, a domain controller requires isolation from the provision of domain controller-related services to

Page 292 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Active Directory clients whilst it undergoes testing or maintenance. Disabling (dynamic) and preventing (manual) registrations of the SRV RRs prevents the use of this domain controller by Active Directory clients (as they will not be able to locate it via DNS), but does not disable the Active Directory service on this domain controller.  Note that it is possible to disable the dynamic registration of all DC Locator SRV RRs by the Netlogon service on a domain controller via the following methods:  Automatically via a script to create the REG_DWORD registry entry “UseDynamicDns” within the registry sub-key “HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”, and assign this entry a value of “0”  Automatically via setting the Windows Server 2003 Active Directory Group Policy Object (GPO) policy “Dynamic Registration of the DC Locator DNS Records” to “disable”. Note that this GPO policy is only applicable to Windows Server 2003 domain controllers. When determining the requirements to disable the dynamic update of specific DC Locator SRV RRs by a domain controller, consider the following:  A domain controller, depending upon its configuration, may register multiple SRV RRs. For example, the following fifteen SRV resource records may be registered by the Netlogon service on a domain controller configured as a Global Catalog server and the FSMO role, Primary Domain Controller Emulator:  The domain controller SRV RRs: • Domain controller (_ldap._tcp.dc._msdcs.<DnsDomainName>) • Domain controller for a specific Site (_ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>) • Domain controller location via GUID (_ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName>)  The LDAP SRV RRs: • LDAP (_ldap._tcp.<DnsDomainName>) • LDAP SRV for a specific Site (_ldap._tcp.<SiteName>._sites.<DnsDomainName>)  The Kerberos SRV RRs: • The Key Distribution Centre (KDC) (_kerberos._tcp.dc._msdcs.<DnsDomainName>) • The Key Distribution Centre (KDC) for a specific Site (_kerberos._tcp.dc._msdcs.<SiteName>._sites.<DnsDomainName>) • The RFC 1510 KDC SRV RR (using TCP protocol) (_kerberos._tcp.<DnsDomainName>) • The RFC 1510 KDC SRV RR (using UDP protocol) (_kerberos._udp.<DnsDomainName>) • The RFC 1510 for a particular Site SRV RR (_kerberos._tcp.<SiteName>._sites.<DnsDomainName>)

Page 293 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• The RFC 1510 Kerberos Password Change server SRV RR (using TCP protocol) (_kpasswd._tcp.<DnsDomainName>) • The RFC 1510 Kerberos Password Change server SRV RR (using UDP protocol) (_kpasswd._udp.<DnsDomainName>)  The Global Catalog SRV RRs: • Global Catalog server (_ldap._tcp.gc._msdcs.<DnsForestName>) • Global Catalog server for a specific Site (_ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName>) • Generic Global Catalog server (not using LDAP) (_gc._tcp.<DnsForestName>) • Generic Global Catalog server for a specific Site (not using LDAP) (_gc._tcp.<SiteName>._sites.<DnsForestName>)  The PDC SRV RR (_ldap._tcp.pdc._msdcs.<DNSDomainName>)  The default registration of the SRV RRs for a domain controller ensures the normal operation of an Active Directory infrastructure. Hence, this design methodology proposes an organisation only consider the selective disabling of SRV RRs registered by the Netlogon service on a domain controller where it is possible to identify compliance with one or more of the following example criteria:  There is a requirement to compliment the granular enabling of Site coverage by specific domain controllers (see below) (without disabling the “autositecoverage” feature on all domain controllers) with the disabling of the advertising of domain controller services within specific Sites in the forest. For example: • A Site has three domain controllers that, via “autositecoverage”, advertise their SRV RRs within another “covered” Site. There is the requirement to restrict the scope of two of these three domain controllers to providing domain controller services only for the Site in which they are located, and not other Sites. There may hence be the configuration requirement to prevent these domain controllers from registering the LDAP, domain controller, and Kerberos SRV RRs at the Site level. • Note that this restriction applies to all Sites within the Active Directory forest, and is not granular for specific Sites. Hence, for example, disabling the registration of the LDAP SRV RRs at the Site level will remove all LDAPP SRV RRs registered by this domain controller from every Site subdomain within DNS, including the Site in which the domain controller resides. Hence, this design methodology advises extreme care and caution during the use of this configuration.  There is a requirement to prevent the generic registration (non-Site specific) of Global Catalog SRV RRs within all Sites except, for example, a hub Site. This requirement will ensure that should the local GC server for a remote Site fail, the Active Directory clients will connect to a GC server in the hub Site only, and not to another GC server within another Site, via a GC server SRV RR within DNS.  There is a requirement to restrict the provision of certain services by a domain controller within an entire forest. For example, it is possible to prevent the registration of Global Catalog SRV RRs (by a domain controller configured as a Global Catalog server) via a Group Policy Setting applied to the GC server. This may hence prevent autonomous divisions from advertising the services of a GC server created without authorisation.

Page 294 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 There may be the requirement to consolidate certain services so that, for example, only one or two powerful domain controllers within each Site provide them. This approach may hence allow the offloading of the provision of these services from lower specification domain controllers. For example, a Site with a few thousand servers also supports directory-enabled applications that make frequent LDAP calls to the Active Directory. By concentrating the advertisement of the LDAP service to one or a few high-specification domain controllers, the other domain controllers within the Site can concentrate their resources on servicing the Active Directory client requirements for authentication and so on.  There may be a security requirement to prevent the advertisement of a domain controller service within a domain. For example, an organisation may wish to restrict access to the LDAP protocol for directory service access via advertisements for this protocol within a DNS infrastructure.  It is possible to control the registration of the types of DNS SRV RRs by the Netlogon service on a domain controller via the following methods:  Automatically via a script to create and configure the REG_MULTI_SZ registry entry “DnsAvoidRegisterRecords” within the registry sub-key “HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”. Configure this data value for this registry entry with one or more of the required spacedelimited mnemonics from the following table below.  Automatically via configuration of the Windows Server 2003 Active Directory GPO policy, “DC Locator DNS Records Not Registered by the DCs", with one or more of the required space-delimited mnemonics listed in the table below. Note that this GPO policy is only applicable to Windows Server 2003 domain controllers.
Mnemonic LdapIpAddress Ldap LdapAtSite Pdc Gc GcAtSite DcByGuid GcIpAddress DsaCname Kdc KdcAtSite Dc DcAtSite Rfc1510Kdc Rfc1510KdcAtSit e GenericGc GenericGcAtSite Rfc1510UdpKdc Type A SRV SRV SRV SRV SRV SRV A CNAME SRV SRV SRV SRV SRV SRV SRV SRV SRV DNS Record <DnsDomainName> _ldap._tcp.<DnsDomainName> _ldap._tcp.<SiteName>._sites.<DnsDomainName> _ldap._tcp.pdc._msdcs.<DnsDomainName> _ldap._tcp.gc._msdcs.<DnsForestName> _ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName> _ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName> _gc._msdcs.<DnsForestName> <DsaGuid>._msdcs.<DnsForestName> _kerberos._tcp.dc._msdcs.<DnsDomainName> _kerberos._tcp.dc._msdcs.<SiteName>._sites.<DnsDomainName> _ldap._tcp.dc._msdcs.<DnsDomainName> _ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName> _kerberos._tcp.<DnsDomainName> _kerberos._tcp.<SiteName>._sites.<DnsDomainName> _gc._tcp.<DnsForestName> _gc._tcp.<SiteName>._sites.<DnsForestName> _kerberos._udp.<DnsDomainName>

Page 295 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Mnemonic Rfc1510Kpwd Rfc1510UdpKpwd

Type SRV SRV

DNS Record _kpasswd._tcp.<DnsDomainName> _kpasswd._udp.<DnsDomainName>

Table 6.6: List of Mnemonics for Active Directory SRV RRs Used Within a Registry Key When determining the requirements to modify the time-to-live (TTL) for all SRV RRs dynamically registered by the Netlogon service, on behalf of a domain controller, consider the following:  By default, the value for the time-to-live (TTL) parameter for all DNS SRV RRs is ten minutes (600 seconds). This period represents the maximum lifetime for the storage of these DNS SRV RRs within the resolver cache on a DNS client.  Clients within an Active Directory infrastructure use DNS SRV RRs more often by than any other RR within the DNS zones for a forest and domains. It is necessary for all clients to contact a domain controller for authentication when they wish to logon on, require access to Active Directory-controlled resources within an organisation, and so on  The caching of the SRV RRs for the Kerberos (KDC) service provided by a domain controller hence ensures:  The use of a cached RR speeds up the authentication process for the Active Directory client, as the client does not have to contact a DNS server to retrieve an SRV RR for a domain controller each time the client requires access to domain controller services.  This hence reduces the workload on a DNS server authoritative for the DNS SRV RRs to process frequent and high volumes of such requests.  The use of cached RRs decreases the volume of network traffic generated by clients wishing to access Active Directory-control resources within the organisation  Increasing the TTL value for DNS SRV RRs registered by the netlogon service on a domain controller may have the following results:  It may ensure that the SRV RRs within the resolver cache on the Active Directory clients are viable for a longer period, thus reducing the frequency and increasing intervals between requirements to contact authoritative DNS servers for these RRs. This in turn will reduce the workload on a DNS server (and hence increase its performance), increase the speed of the authentication process for the Active Directory clients, and decrease the levels of associated network traffic.  It may lead to delays in the resolution of authentication failures should the domain controller advertised within a cached DNS SRV RR become unavailable. For example, after a failed attempt by the client to contact the domain controller, it will query its designated DNS server. If a large number of other clients cached the SRV RR for a particular domain controller for a longer period than default, then as soon as the advertised domain controller is unavailable, the large volume of queries suddenly received by the DNS server may slow down the response times for the clients.  Decreasing the TTL value for DNS SRV RRs registered by the netlogon service on a domain controller may have the following results:

Page 296 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 It may result in an increase in the frequency and volume of queries, by Active Directory clients, to DNS servers authoritative for the appropriate DNS SRV RRs as the cached entries expire sooner.  There may be an associated increase in the levels of network traffic generated by the client name queries to their designated DNS servers.  There may be an increase in the workload of the DNS servers as the frequency of queries for the DNS SRV RRs increases, and hence a decrease in their performance. This may hence result in slower response times for the authentication process.  This design methodology proposes an organisation only consider modification of the default value for the TTL parameter for DNS SRV RRs, for one or more specific domain controllers, where it is possible to identify compliance with the following examples of criteria:  There is a requirement to decrease the levels of network traffic, workload on DNS servers, and response times for the authentication process. It is possible to meet this requirement by increasing the value of the TTL parameter of DNS SRV RRs for domain controllers.  There is a requirement to compliment a load-balancing mechanism for DNS SRV RRs (using the Weight and Priority parameters for a SRV RR (see later for details)) by decreasing the value of the TTL parameter. This will hence ensure a higher frequency of requests to a DNS server by an Active Directory client for the SRV RRs, and hence more control over the distribution of these SRV RRs to the clients by the DNS server, within the context of the load-balancing mechanism.  Note that it is possible to modify the value for the TTL parameter for all DNS SRV RRs dynamically registered by the Netlogon service on a domain controller, for one or more domain controllers, via the following methods:  Automatically via a script to create the REG_DWORD registry entry “DnsTtl” within the registry sub-key “HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”, and assign this entry a value, in seconds, for the required TTL (for example, the default is 600 seconds (10 minutes), and “900” seconds is 15 minutes)  Automatically via setting the Windows Server 2003 Active Directory Group Policy Object (GPO) policy “TTL Set in the DC Locator DNS Records” to the required number of seconds. Note that this GPO policy is only applicable to Windows Server 2003 domain controllers. Using the above information, execute the following:  Determine and document the requirement to disable the dynamic update of the DC Locator DNS SRV RRs by the Netlogon service on a domain controller, for one or more domain controllers  Where the requirement disable the dynamic update of the DC Locator DNS SRV RRs by the Netlogon service is identified, determine and document the following:  The domain controllers that require configuration with this setting  The required method(s) for application of the required configuration  Determine and document the requirement to disable the dynamic update of specific SRV RRs by the Netlogon service on a domain controller, for one or more domain controllers

Page 297 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Where the requirement to disable the dynamic update of specific SRV RRs by the Netlogon service is identified, determine and document the following:  The domain controllers that require configuration with this setting  The specific SRV RRs that the Netlogon service is to be prevented from registering on each identified domain controller  The required method(s) for application of the required configuration  Determine and document the requirement to modify the default value for the TTL parameter within DNS SRV RRs registered by the Netlogon service on a domain controller, for one or more domain controllers  Where the requirement to modify the default value for the TTL parameter within DNS SRV RRs registered by the Netlogon service is identified, determine and document the following:  The domain controllers that require configuration with this setting  The required value(s) to be assigned to all, or each identified domain controller  The required method(s) for application of the required configuration • Factor A90: Determination of the configuration requirements for the load-balancing of DC Locator DNS SRV RRs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements to modify the default priority and weight values for DNS SRV RRs registered by the Netlogon service on domain controllers, to meet specific load-balancing requirements. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to configure two parameters within all DNS SRV RRs to meet requirements for load balancing. These are the “Weight” and “Priority” parameters. The default values for these parameters are 100 and 0 (zero), respectively. When determining the requirements to modify the default values for the “Weight” and “Priority” parameters for all SRV RRs dynamically registered by the Netlogon service, on behalf of a domain controller, for one or more domain controllers, consider the following:  The DNS server service uses the weight value for a SRV RR to consider preference towards particular hosts, in conjunction with the priority value. This occurs when the DNS service is required to select a target host from multiple hosts that have all registered SRV RRs for the same type of service (specified within the “Service” field of an SRV RR, such as “_ldap” or “_Kerberos”), and each SRV RR has the same priority value. The DNS server will preferentially return to a DNS client, within SRV query results, those DNS SRV RRs with higher assigned weight values.  When domain controllers have the same priority value, the Netlogon service selects from among them by using a statistical calculation based on the weight assigned to the domain controller. Domain controllers with the highest weight have a higher probability of contact and use by a client. This method allocates contact traffic most efficiently.  The following formula calculates the probability value based upon the value of the weight parameter: weight parameter value / sum (weight parameter values for all domain controllers with equal priority). For example:

Page 298 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Three domain controllers (DC1, DC2, and DC3) are all assigned equal priority values for their SRV RRs  Each domain controller receives the following assigned weight values: • DC1 is assigned a value of three • DC2 is assigned a value of two, and • DC3 is assigned a value of one  Hence, the probability of selection of DC1 is 3/6 = ½ = 50%; DC2 is 2/6 = 1/3 = 33%; and DC3 is 1/6 = 16.67%.  The priority value for a SRV RR indicates to a DNS server the level of priority a host has over its peers that offer the same service advertised via the SRV RRs. A lower numeric value within the priority parameter of a SRV RR indicates a higher priority. Multiple SRV RRs for a service registered by multiple hosts, and assigned the same numeric value for the priority parameter, share equal priority. Selection of the host is then dependent upon any differences within the weight parameters for these SRV RRs. Where the weight values also match, then the DNS clients can try hosts of equal preference in random order.  Note that these configurations apply at the domain controller level, and not to specific DNS SRV RRs registered by a domain controller. Hence, it is important to define and understand the scope of application prior to configuration. This design methodology proposes an organisation consider the configuration of the weight and priority values for DN SRV RRs, only where it is possible to identify compliance with either or both of the following example criteria:  There is a requirement to prioritise the use of specific domain controllers over others within a Site by Active Directory clients. For example, a Site configured with three domain controllers has two dedicated domain controllers, and one domain controller operating on a server with a different primary function, such as a Microsoft Exchange 2003 Server. Although the two dedicated domain controllers have lower hardware specifications compared to the Microsoft Exchange 2003 server, they have higher levels of hardware resource availability. Hence, these dedicated domain controllers are more capable of handling Active Directory-related requests than the non-dedicated domain controller. The use of the weight and priority values can hence ensure that the dedicated domain controllers receive the majority of SRV queries between them.  There is the requirement to control the direction and flow of network traffic to domain controllers within a Site from Active Directory clients, using this load-balancing feature.  There is the requirement to distribute the workload for the provision of specific services between different domain controllers via the load balancing of SRV RRs in conjunction with the selective disabling of the registration of SRV RRs by domain controllers. For example, there is the requirement to load-balance the provision of the LDAP service across four out of ten domain controllers within a domain and in the same Site. The six other domain controllers are configured not to advertise their LDAP services. It is hence possible to use the weight and priority values to load balance the LDAP service across the four domain controllers permitted to advertise this service. Note that the configuration of weight and priority values to DNS SRV RRs increases the processing time for SRV queries and makes them less readable. Hence, this design methodology recommends organisations do not configure these values where load balancing is not required.

Page 299 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Note that it is possible to configure the weight parameter, for all DNS SRV RRs registered by the Netlogon service on a domain controller, via the following methods:  Automatically via a script to create the REG_DWORD registry entry “LdapSrvWeight” within the registry sub-key “HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”, and assign this entry a value within the range of 0 (zero) to 65535 (default value is 100).  Automatically via setting the Windows Server 2003 Active Directory Group Policy Object (GPO) policy “Weight Set in the DC Locator DNS Records” to the required value for this parameter. Note that this GPO policy is only applicable to Windows Server 2003 domain controllers. Note that it is possible to configure the priority parameter, for all DNS SRV RRs registered by the Netlogon service on a domain controller, via the following methods:  Automatically via a script to create the REG_DWORD registry entry “LdapSrvPriority” within the registry sub-key “HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”, and assign this entry a value within the range of 0 (zero) to 65535 (default value is 0 (zero)).  Automatically via setting the Windows Server 2003 Active Directory Group Policy Object (GPO) policy “Priority Set in the DC Locator DNS Records” to the required value for this parameter. Note that this GPO policy is only applicable to Windows Server 2003 domain controllers. Using the above information, execute the following:  Determine and document the requirement for the use of load balancing across DNS SRV RRs  Where the requirement to use load balancing is identified, determine and document the following:  The domain controllers that require configuration for load balancing  The weight and priority values that require assignment to these identified domain controllers  The required method(s) for application of the required configurations • Factor A91: Determination of the configuration requirements to support Application Directory Partition (ADP) Site Locator DNS SRV RRs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom Active Directory Application Directory Partitions (ADPs) (see results of the Forest Plan process to create a “design for Application Directory Partitions within a Forest”),  Has identified the requirements for the replication of one or more of the custom ADPs to several domain controllers in different Sites where the majority of the clients of the ADP reside,  Has identified that a few clients of the ADP reside in Sites not covered by the domain controllers that host replicas of an ADP, and  Wishes to determine the design requirements for DNS SRV RR configuration to ensure coverage of these Sites

Page 300 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to create and configure a custom application directory partition (ADP) for replication only to specific Windows Server 2003 domain controllers within the forest. The enrolment of a Windows Server 2003 domain controller into the replica list of a custom ADP forces the Netlogon service on this domain controller to register (dynamically) Site-specific ADP-specific DC Locator DNS SRV RRs. These resource records are additional to the standard domain controller SRV RRs. It is possible to configure the registration of these ADP-specific DC Locator DNS SRV RRs by the enrolled domain controllers within specific additional Sites. Consider the requirement to extend the list of sites, where a domain controller advertises the ADP-specific DC Locator DNS SRV RRs, where it is possible to identify one or more of the following example criteria within an organisation:  There is the requirement to advertise the ADP-specific DC Locator DNS SRV RRs within Sites where the domain controllers hosting the replicas of an ADP do not reside. For example, an application that use an ADP to store configuration and functional data has clients distributed across multiple Sites. A few clients are located within Sites that do not host domain controllers within the replica list of the ADP, and hence, these clients are unable to access the ADP, as they cannot locate a domain controller that hosts the required ADP. By extending the list of Sites a domain controller must advertise ADP-specific DC Locator DNS SRV RRs within, a client will be able to locate the appropriate domain controller.  There is a requirement to control the network path and access to ADP data by clients and applications using the selective registration of the ADP-specific DC Locator DNS SRV RRs within Sites. It is possible to configure the list of Sites, where a domain controller that hosts a replica of an ADP registers the ADP-specific DC Locator DNS SRV RRs, via the following methods:  Automatically via a script to create the REG_SZ registry entry “NdncSiteCoverage” (NDNC = Non-Domain Naming Context = ADP) within the registry sub-key “HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters”. Configure this data value for this registry entry with one or more of the required space-delimited list of Sites the domain controller is required to cover.  Automatically via setting the Windows Server 2003 Active Directory Group Policy Object (GPO) policy “Sites Covered by the Application Directory Partition Locator DNS SRV Records” with one or more of the required space-delimited list of Sites the domain controller is required to cover. Note that this GPO policy is only applicable to Windows Server 2003 domain controllers. Using the above information, execute the following:  Determine and document the requirement to extend the list of Sites where a domain controller hosting a replica of an ADP will register the ADP-specific DC Locator DNS SRV RRs  Where this requirement is identified, determine and document the following:  The custom Application Directory Partitions that require consideration for this configuration  The domain controllers within the replica list for an ADP that require configuration

Page 301 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The list of the Active Directory Sites that each identified domain controller will be required to register the ADP-specific DC Locator DNS SRV RRs  The required method(s) for application of the required configurations • Factor A92: Determination of the configuration requirements for automatic site coverage registration in DNS ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of multiple locations within the organisation that host Active Directory clients, represented as Sites within the Site infrastructure for a forest, but which have no local domain controllers, or  Has identified the presence of multiple locations within the organisation that host Active Directory clients, represented as Sites within the Site infrastructure for a forest, but which have only a single local domain controller, and  Wishes to determine the design requirements for the modification of the default “autositecoverage” registration feature of Windows Server 2003 domain controllers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A default feature of Windows Server 2003 domain controllers for a domain is to use the “autositecoverage” algorithm. This algorithm ensures that Active Directory clients within each Active Directory Site for a forest may contact at least one other domain controller within another Site in close proximity to this Site, should there be no local domain controller. The algorithm uses the replication topology for an Active Directory forest to determine this information, and then register the appropriate SRV resource records within the corresponding “_msdcs.<domain>” DNS zone. The potential issues that may arise from the implementation of this feature are where a local Active Directory client, via a DNS SRV resource record, attempts to contact a domain controller within another remote location and not, for example, preferred domain controllers within a hub site. When determining the requirement to disable the “autositecoverage” feature, consider the following information:  If there is a requirement to disable this feature, then it must be performed on all domain controllers within a forest, and not just within domain controllers in remote locations  It is possible to granularly enable the function provided by this feature (to compliment or replace the “autositecoverage” feature) to designate specific Active Directory Sites covered by:  Domain controllers for the registration of Locator DNS SRV records within the “_msdcs.<domain>” DNS zone  Global Catalog servers for the registration of Locator DNS SRV records within the “_msdcs.<forest_root_domain>” DNS zone  The Netlogon service uses information for the following criteria (in the order listed) from the Active Directory to determine appropriate Site coverage:

Page 302 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The costs associated with the Site Link(s) between a domain controller and the Site to be covered  The Site with the greatest number of domain controllers  (Tie breaker should the above two criteria match for more than one Site) The alphabetical order for the names of the potential Sites to offer domain controller cover for another Site.  The disabling of the “autositecoverage” feature of Windows Server 2003 Active Directory domain controllers is a major undertaking, as it requires configuration on all domain controllers within a forest. Hence, this design methodology strongly advises against the execution of this action unless it is possible to identify clear justifiable and supporting business or technical requirements.  This design methodology hence proposes that organisations consider disabling the “autositecoverage” feature of Windows Server 2003 Active Directory domain controllers only where it is possible to identify compliance with the following requirements and criteria:  The organisation has identified the requirement to ensure the use / failover of Active Directory clients from within a remote location, to domain controllers within a specific Site not selected for automatic coverage by the “autositecoverage” algorithm, and  It is possible to identify compliance with one or more of the following example criteria: • The “autositecoverage” algorithm has selected a Site that is the closest (based upon cost) and most appropriate (based upon numbers of domain controllers in the Site) (but this Site is undesirable). Subsequent revision of the cost model for the Site Link objects is not a feasible option to ensure selection of the desired Site. • The “autositecoverage” algorithm has selected a Site that is the closest (based upon cost) and most appropriate (based upon numbers of domain controllers in the Site) (but this Site is undesirable). The network link that connects this Site with the Site to be covered has high available bandwidth levels, but intermittent service levels. This may hence be unsuitable for the Active Directory clients within the Site to be covered. • The “autositecoverage” algorithm has selected a Site that is the closest (based upon cost) and most appropriate (based upon numbers of domain controllers in the Site), but this Site is undesirable as it does not contain domain controllers for the domain in which the Active Directory clients (in the Site to be covered) are members of. • The Active Directory forest for an organisation contains many hundreds of domain controllers, distributed into many tens of Active Directory Sites. There is requirement to control the network traffic associated with the automatic registration and re-registration of the LDAP and Kerberos services by all or most of these domain controllers within the “<SiteName>._sites.<DnsDomainName>” DNS zones for the Sites “covered” by the domain controllers via the “autositecoverage” algorithm. There may also be an impact on the storage requirements and performance of the DNS server service where it is required to maintain and process many hundreds of SRV entries that may not be required.

Page 303 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 When determining the requirement to granularly ensure coverage of an Active Directory Site by one or more specific domain controllers or Global Catalog servers, consider the following factors that may influence this requirement:  A supporting network infrastructure may logically connect multiple Active Directory Sites within a forest, but the network connections do not reflect relationships between logically disconnected Sites, such as divisional ownership, domain representation, physical proximity of the locations represented by the Sites, and so on  The results of the “autositecoverage” feature do not reflect the business or technical requirements for the coverage of Sites by domain controllers and Global Catalog servers within other Sites.  The granular and explicit coverage of Sites by domain controllers and Global Catalog servers within other Sites is possible via the use of the registry entries “SiteCoverage” and “GcSiteCoverage” respectively. These REG_MULTI_SZ registry entries require creation on Windows Server 2003 domain controllers within the registry sub-key “HKLM\System\CurrentControlSet\Services\Netlogon\Parameters” with data values identifying the Active Directory Sites that these domain controllers and Global Catalog servers are to cover.  Note that is preferable to configure these registry entries via the use of the Windows Server 2003 Active Directory Group Policy Object policy settings “Sites Covered by the DC Locator DNS SRV Records” and “Sites Covered by the GDC Locator DNS SRV Records” respectively. Note also that these Windows Server 2003 Active Directory GPO policy settings are only applicable to Windows Server 2003 domain controllers. Using the above information, execute the following:  Determine and document the requirements to disable the “autositecoverage” feature on all domain controllers within a forest  Determine and document the requirements to create and configure the “SiteCoverage” registry entry for domain controllers within a domain  Where there is a requirement to create and configure the “SiteCoverage” registry entry, determine and document the following:  The domain controllers that require configuration  The list of Sites that each of these domain controllers are required to cover  Determine and document the requirements to create and configure the “GcSiteCoverage” registry entry for Global Catalog servers within a forest  Where there is a requirement to create and configure the “GcSiteCoverage” registry entry, determine and document the following:  The Global Catalog servers that require configuration  The list of Sites that each of these Global Catalog servers are required to cover • Factor B37: Understanding the influence of the Active Directory Site and Site Link topology on DNS server design ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 304 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Has identified the requirements for the design and deployment of a distributed Windows Server 2003 Active Directory infrastructure that comprises of multiple Sites and Site Links, and  Wishes to understand the DNS server design elements influenced by this Active Directory infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A distributed Active Directory infrastructure, with multiple Sites and Site Links between the Sites, may influence the design for multiple components and elements of a supporting DNS server infrastructure. The following are examples of the design elements of a DNS server infrastructure influenced by an Active Directory Site infrastructure. Where a physical location has a user population represented within multiple Active Directory domains and DNS namespaces, then this will influence the design for the partitioning of DNS namespaces into zones, and hence the number of DNS zones each DNS server in each physical location is required to host. This will hence in turn influence the design for the following DNS infrastructure elements:  The capacity and performance planning elements of a DNS server infrastructure  The design for zone replication within and between physical locations  The design for name resolution within and between DNS namespaces to support local and inter-location name resolution requests The requirement to reduce inter-Site DNS zone replication traffic will influence the design of the types of DNS zones used within a Site and the replication model for the DNS zones. For example, to prevent name resolution traffic from crossing an inter-Site network link, it is necessary to design a local DNS server that is authoritative for the requested DNS namespace query. However, in order to make a DNS zone authoritative, it must be a primary or secondary DNS zone. A secondary DNS zone relies upon zone transfers from a master DNS server. Where the master DNS server is in a different physical location to the DNS server hosting the secondary zone, there will be a requirement for the network traffic created by zone transfers to the secondary zone to cross the interSite network links. To prevent this, it is necessary for a local DNS server to host a primary zone. Where there is a requirement to allow multiple DNS servers to be authoritative for a DNS zone, but restrict zone transfer traffic, it is possible to create the zone as a primary DNS zone stored within a Windows Server 2003 Active Directory application directory partition. This approach will permit a local DNS server to be authoritative for a DNS zone and not generate a discrete replication topology for the DNS zone but instead use the Active Directory replication model to replicate the DNS zone to multiple domain controllers. This approach hence influences the following design elements for a DNS server infrastructure:  The selection of DNS server software required to support the Windows Server 2003 Active Directory infrastructure. It is only possible to use Windows Server 2003 DNS server software if Windows Server 2003 Active Directory application directory partitions are to be used to store DNS zone data

Page 305 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Design for the placement and installation of the DNS server software within each physical location for an organisation. In order to access DNS zone data stored within a Windows Server 2003 Active Directory application directory partition, it is necessary to install Windows Server 2003 DNS server software on a Windows Server 2003 domain controller. • Factor B38: Understanding the opportunity to use group policy object settings to configure DNS clients ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the opportunity for the use of group policy object settings to configure Windows 2000, Windows XP Professional, and Windows Server 2003 DNS clients ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible, within Windows Server 2003 Active Directory, to configure selected Windows DNS clients using policy settings within a group policy object (GPO). It is possible to configure and apply thirteen GPO settings to DNS clients. The “determination of the design requirements for DNS clients of a DNS infrastructure” discusses these policy settings in detail. Note that the requirement to use all or some of the thirteen GPO settings to configure DNS clients will influence the following design elements of a DNS server infrastructure:  The design for the mode of configuration of the Windows DNS clients of all or some of the DNS server infrastructures for an organisation  The design for the configuration of DNS zones to be hosted by each DNS server to permit dynamic updates  The design for the integration of DNS with DHCP servers for dynamic updates 5.9.7. DNS Server Gap Analysis Only organisations following “Track 3” of this process (have one or more internal DNS servers) are required to execute the DNS server gap analysis. • Factor B39: Understanding the approach for execution of the DNS server gap analysis ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach, proposed by this design methodology, for execution of the DNS server gap analysis. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is necessary to execute the DNS server gap analysis following completion of the analysis of the current DNS server infrastructure, and the determination of the DNS server and client requirements to support the defined scope of the Active Directory infrastructure. The analysis conducted so far has revealed the following details about the current DNS server infrastructure and DNS server and client configuration requirements:  The following information about the current DNS server infrastructure:  The number of DNS servers currently in operation (within the scope of this process) within the organisation, identifying the number of DNS servers

Page 306 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

dedicated to specific functions, and the number of DNS servers operating virtual roles  The version of DNS server software currently in use  The number, type, configuration, and storage mode of DNS zones that each DNS server supports, and the function of each DNS zone within the DNS infrastructure  The relationships between the DNS zones (inter-zone replication)  The integration of DNS servers with WINS and / or DHCP servers  The current name resolution strategy for the DNS server infrastructure  The configuration of the DNS clients of the DNS server infrastructure, and so on  The following requirements for a DNS server and Windows DNS client infrastructure:  The design requirements for a name resolution strategy  The design requirements for specific DNS zone types, zone data storage options, zone data replication between DNS zones  The design requirements for integration of DNS with a WINS and / or a DHCP infrastructure  The design requirements for the configuration of Windows DNS clients of a DNS infrastructure  The design requirements for the configuration of Windows Server 2003 DNS servers  The determined number of actual and virtual standard, caching-only, internal forwarder, and internal root DNS servers required to support the Windows Server 2003 Active Directory infrastructure This design methodology proposes the following objectives for the DNS server gap analysis:  The DNS server gap analysis requires execution only against those existing DNS servers within an organisation, identified as being suitable or required to support the proposed Windows Server 2003 Active Directory infrastructure for the organisation.  The gap analysis will not identify any design tasks if the current (in-scope) DNS server infrastructure is capable of supporting all identified requirements for the DNS server and client infrastructures without any requirement to design or modify the current infrastructure.  Where the current (in-scope) DNS server infrastructure is incapable of meeting all of the identified requirements for a DNS server infrastructure to support the defined scope of the Active Directory infrastructure, then the gap analysis will identify the appropriate design tasks to permit compliance with identified design requirements. The following are examples of scenarios where a current DNS server infrastructure cannot support, in its current configuration, the identified design requirements for a DNS server infrastructure to support the defined scope of the Active Directory infrastructure:

Page 307 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The current DNS server software or version of software is incapable of supporting the identified design requirements, such as the requirement for stub DNS zones, and so on without an upgrade to a newer version of software that does support the requirements. This hence generates the requirement to design the necessary tasks to upgrade the current DNS server software to a version that supports the identified requirements.  The current DNS server software or version of software is capable of supporting the identified requirements, but only after a modification of the configuration of the software. This hence generates the requirement to design the necessary tasks to modify the current DNS server software to support the identified requirements.  The current DNS server software or version of software is incapable of supporting the identified requirements even with upgrades to newer versions, or modifications to the current version. This hence generates the requirement to design the migration from the current to the new required DNS server software platform. Hence, this design methodology proposes the following approach for the execution of the DNS server gap analysis:  Execute a DNS server gap analysis to identify the suitability of an existing DNS server infrastructure to support all identified design requirements.  Where an existing DNS server infrastructure is capable of supporting all required design requirements, without any modifications, then it is not necessary to execute any design tasks for the DNS server infrastructure component of a DNS infrastructure.  However, where the DNS server is unable to support all identified design requirements for the proposed DNS server infrastructure, then execute the following:  Execute a gap analysis to determine the requirements to upgrade elements of the existing DNS server infrastructure  Execute a gap analysis to determine the requirements to modify elements of the existing DNS server infrastructure  Execute a gap analysis to determine the requirements to replace elements of the existing DNS server infrastructure Hence, presented within the following four sections are the considerations for the execution of the DNS server gap analysis:  Considerations for the conduction of a DNS server gap analysis  Considerations for the upgrade of the current DNS server software to a newer version that supports all identified design requirements  Considerations for the modification of the current DNS server configuration to support all identified design requirements  Considerations for the replacement of the current DNS server software with different DNS server software to support all identified design requirements 5.9.7.1. Execution of a DNS Server Gap Analysis Consider the following information when executing a DNS server gap analysis, to determine the differences between an existing DNS server infrastructure and the identified requirements for a DNS server infrastructure, to support the defined scope of the Active Directory infrastructure:

Page 308 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

• Factor B40: Understanding the support of DNS features by different implementations of DNS Server software ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the differences between the current DNS server software capabilities and the identified requirements for the DNS infrastructure to support the defined scope of the Active Directory infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: There are many sources of DNS server software available, with two of the most common sources been BIND and Microsoft Windows DNS. When executing the DNS server gap analysis, consider the following table that illustrates the differences in feature support of some typical features, within the different versions of Microsoft Windows DNS and BIND DNS server software:
Feature Windows Server 2003 Windows 2000 Windows NT 4.0 BIND 9 BIND 8.2 BIND 8.1.2

Supports the Internet Engineering Task Force (IETF) Internet-Draft, "A DNS RR for specifying the location of services (DNS SRV)." (SRV records) Dynamic zone updates Conditional forwarder entries WINS and WINS-R records Fast zone transfer Incremental zone transfer Stub zones UTF-8 character encoding Aging and scavenging of obsolete records Active Directory integrated zones Storage of zones in the application partition of Active Directory

         

         

         

         

         

         

Table 6.7: Comparison of Features between versions of Windows and BIND DNS • Factor A93: Determination of the support for the identified design requirements of a name resolution strategy ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the design requirements for a name resolution strategy, and  Wishes to execute a gap analysis to determine whether the current DNS server infrastructure can support these requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 309 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Depending upon the identified design requirements for a name resolution strategy, an existing DNS server infrastructure may have to support the following:  The requirements for forwarder and / or conditional forwarder configuration entries on a DNS server  The requirements for root hint configuration entries on a DNS servers and clients  The requirements for intra- and inter-namespace name resolution  The requirements for the use of internal root DNS servers  The requirements for the use of internal forwarder DNS servers  The requirements for the use of caching-only DNS servers  The requirements for the use of stub zones Upon identification of the requirements for any or all of the above components of a name resolution strategy, determine the capability of the current DNS server infrastructure to support these requirements. Where it is determined that the current DNS server infrastructure cannot support, in its current configuration and version of software, all of the identified requirements, then determine:  The component(s) of the name resolution strategy that the current DNS server software cannot support  Whether a newer version of the DNS server software is capable of supporting the identified requirements or not  Whether the current DNS server software can be reconfigured or modified to permit support of the component(s) of the name resolution strategy Where the current DNS server software requires an upgrade to a newer version, to permit support of the component(s) of the name resolution strategy, determine the latest version of the DNS server software that permits support. Also, identify the specific DNS server(s) that require an upgrade. Where the current DNS server software requires reconfiguration or modification, to permit support of the component(s) of the name resolution strategy, determine the design requirements to implement the necessary configuration(s). Also, identify the specific DNS server(s) that require a reconfiguration or modification. Where it is determined that the current DNS server infrastructure can support, in its current configuration and version of software, all of the identified requirements, then there will be no design tasks associated with the with implementation of the required name resolution strategy. Using the above information, execute the following:  Execute a gap analysis between required components of a name resolution strategy and the current capabilities of DNS server software supporting a current DNS infrastructure  Determine and document the requirements to execute upgrades, modification, or replacements of DNS server software • Factor A94: Determination of the support for the identified DNS zone design requirements

Page 310 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to execute a gap analysis between the current DNS server software capabilities and the identified requirements for the DNS zones to support the defined scope of the Active Directory infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Depending upon the identified design requirements for DNS zones, an existing DNS server infrastructure may be required to support the following:  The requirements for the partitioning of DNS namespaces into two or more DNS zones  The requirements for the types of forward and reverse lookup DNS zones (primary, secondary, stub)  The requirements for the storage of the DNS zone data within each DNS zone  The requirements for the creation of a DNS zone, and the population of a primary DNS zone with the SRV resource records necessary to support the defined scope of the Active Directory infrastructure  The requirements for the dynamic update of DNS zones Partitioning of a DNS namespace into multiple DNS zones will influence the number of DNS zones that require creation, population, maintenance, replication, and so on. Most modern DNS server software can support multiple DNS zones on a DNS server. Hence, the requirements for partitioning of a DNS namespace will not influence the determination of the capability of the current DNS server infrastructure in supporting a Windows Server 2003 Active Directory infrastructure. Where there is an identified requirement for the use of stub zones, it is necessary to determine if the current DNS server software can support their use. If the software cannot, determine if a newer version is capable of supporting stub zones. Where there is a requirement to store DNS zone data within an Active Directory infrastructure, determine if there is a requirement to use either the custom or default application directory partitions (ADPs), or the legacy DNS zone data storage location (within the domain partition). If there is a requirement to store any DNS zone data within an ADP, then only a Windows Server 2003 DNS server may be used to access and manage these DNS zones. Storage of DNS zone data within the legacy Active Directory (domain partition) location, permits the use of either Windows 2000 or Windows Server 2003 DNS server software only. Determine whether the current DNS server infrastructure can support the use of SRV resource records. If the DNS server software cannot, determine if there is a newer version of the software that permits the support of SRV RRs. Also, identify the specific DNS server(s) that require an upgrade. Where there is the requirement to use DCPROMO to create the initial primary DNS zones, and there is a requirement to use dynamically updatable DNS zones, determine if the current DNS server software supports dynamic updates. If the DNS server software cannot, determine if there is a newer version of the software that permits the support of dynamic updates. Where it is determined that the current DNS server infrastructure can support, in its current configuration and version of software, all of the identified DNS zone requirements, then there will be no design tasks associated with implementation of these requirements.

Page 311 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Using the above information, execute the following:  Execute a gap analysis between the identified design requirements for DNS zones and the current capabilities of DNS server software supporting a current DNS infrastructure  Determine and document the requirements to execute upgrades, modification, or replacements of DNS server software • Factor A95: Determination of the support for DNS zone replication design requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the replication of DNS zones between two or more DNS servers, and  Wishes to execute a gap analysis to determine whether the current DNS server infrastructure can support these design requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Depending upon the identified requirements for the replication of DNS zones, an existing DNS server infrastructure may have to support the following:  The replication topology requirements  The replication of DNS zone data via Active Directory replication between domain controllers  The selective replication of DNS zone data to specific domain controllers within the replica list of a default or custom ADP hosting DNS zone data Where the current DNS server software requires an upgrade to a newer version, to permit support of the DNS zone replication requirements, determine the latest version of the DNS server software that permits support. Also, identify the specific DNS server(s) that require an upgrade. Where the current DNS server software requires reconfiguration or modification, to permit support of the DNS zone replication requirements, determine the design requirements to implement the necessary configuration(s). Also, identify the specific DNS server(s) that require reconfiguration or modification. Where it is determined that the current DNS server infrastructure can support, in its current configuration and version of software, all of the identified requirements, then there will be no design tasks associated with the implementation of the DNS zone replication requirements. Using the above information, execute the following:  Execute a gap analysis between the identified design requirements for DNS zone replication and the current capabilities of DNS server software supporting a current DNS infrastructure  Determine and document the requirements to execute upgrades, modification, or replacements of DNS server software • Factor A96: Determination of the support for design requirements to integrate DNS with DHCP and / or WINS

Page 312 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has identified the requirements for the integration of DNS with DHCP and / or WINS, and wishes to conduct a gap analysis to determine whether the current DNS server infrastructure can support these requirements. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Depending upon the identified requirements for the integration of DNS with a DHCP and / or WINS infrastructure, an existing DNS server infrastructure may have to support the following:  Compliance with support for option 81 (of the Internet Draft, Interaction between DHCP and DNS by M. Stapp and Y. Rekhter (dhc-dhcp-dns-12.txt)), within the context of permitting a DHCP server to update a DNS server with DHCP client DNS A and PTR resource record details. The DNS server must hence support dynamically updateable DNS zones.  Compliance with the minimum requirements for the integration of DNS within WINS (must be a Windows DNS server, and preferably a minimum version of Windows 2000 DNS server) Where the current DNS server software requires an upgrade to a newer version, to permit support of the integration with a DHCP and / or WINS infrastructure, determine the latest version of the DNS server software that permits support. Also, identify the specific DNS server(s) that require an upgrade. Where the current DNS server software requires reconfiguration or modification, to permit support of the integration with a DHCP and / or WINS infrastructure, determine the design requirements to implement the necessary configuration(s). Also, identify the specific DNS server(s) that require reconfiguration or modification. Where it is determined that the current DNS server infrastructure can support, in its current configuration and version of software, all of the identified requirements, then there will be no design tasks associated with the implementation of the required integration of DNS with DHCP and / or WINS. Using the above information, execute the following:  Execute a gap analysis between the identified design requirements to integrate DNS with DHCP and / or WINS and the current capabilities of DNS server software supporting a current DNS infrastructure, and DHCP server software  Determine and document the requirements to execute upgrades, modification, or replacements of DNS server software • Factor A97: Determination of the support for DNS server design requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the configuration of the DNS servers to support an Active Directory infrastructure, and  Wishes to execute a gap analysis to determine whether the current DNS server infrastructure can support these design requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 313 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Depending upon the identified design requirements for the DNS servers to support an Active Directory infrastructure, an existing DNS server infrastructure may have to support the following:  The baseline configuration requirements for all DNS servers  Where the requirement for the use of the standard DNS server role is identified, then also the following requirements:  The logical and physical placement requirements for the standard DNS servers  The numbers of standard DNS servers required, and their minimum hardware specifications  The configuration requirements for the standard DNS server role  Where the requirements for the use of the caching-only DNS server role is identified, then also the following requirements:  The logical and physical placement requirements for the caching-only DNS servers  The numbers of caching-only DNS servers required, and their minimum hardware specifications  The configuration requirements for the caching-only DNS server role  Where the requirements for the use of the internal forwarder DNS server role is identified, then also the following requirements:  The logical and physical placement requirements for the internal forwarder DNS servers  The numbers of internal forwarder DNS servers required, and their minimum hardware specifications  The configuration requirements for the internal forwarder DNS server role  Where the requirements for the use of the internal root DNS server role is identified, then also the following requirements:  The logical and physical placement requirements for the internal root DNS servers  The numbers of internal root DNS servers required, and their minimum hardware specifications  The configuration requirements for the internal root DNS server role Where the current DNS server software requires an upgrade to a newer version, to permit support of the identified design requirements for DNS servers, determine the latest version of the DNS server software that permits support. Also, identify the specific DNS server(s) that require an upgrade. Where the current DNS server software requires reconfiguration or modification, to permit support of the identified design requirements for DNS servers, determine the design requirements to implement the necessary configuration(s). Also, identify the specific DNS server(s) that require reconfiguration or modification. Where it is determined that the current DNS server infrastructure can support, in its current configuration and version of software, all of the identified requirements, then

Page 314 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

there will be no design tasks associated with the implementation of the identified design requirements for DNS servers. Using the above information, execute the following:  Execute a gap analysis between the identified design requirements for the DNS servers to support an Active Directory infrastructure and the current capabilities of DNS server software supporting a current DNS infrastructure  Determine and document the requirements to execute upgrades, modification, or replacements of DNS server software • Factor A98: Determination of the support for Active Directory specific DNS server design requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the Active Directory specific design requirements for the configuration of the DNS servers, and  Wishes to execute a gap analysis to determine whether the current DNS server infrastructure can support these design requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Depending upon the identified Active Directory specific design requirements for the DNS servers, an existing DNS server infrastructure may have to support the following:  The requirement to disable the dynamic registration of DC Locator SRV RRs by domain controllers within DNS  The requirement to configure load-balancing of DC Locator SRV RRs  The requirement to configure support for ADP Site Locator DNS SRV RRs  The requirement to configure automatic site coverage registration in DNS Note that the configuration of all of these options applies only to Windows Server 2003 domain controllers, either via manual manipulation of the registry, or via the Group Policy Objects (GPOs). Hence, as none of these configuration options depends directly upon a version of DNS server, they do not influence the design for the DNS server infrastructure. 5.9.7.2. Upgrading the Current DNS Server Software Execute this gap analysis component where it is possible to identify compliance with all of the following criteria: 1. 2. 3. The DNS server gap analysis has determined that the current DNS server software is incapable of supporting all of the identified design requirements The organisation has determined that a currently available newer version of the same DNS server software is capable of supporting all of the identified design requirements The organisation has hence determined the requirement to upgrade the current DNS server software for one or more of the current DNS servers, within the existing DNS server infrastructure, to a newer version of the same DNS server software

Page 315 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Where it is possible to identify compliance with all of the above criteria, consider the following information when conducting a gap analysis to determine the requirements to upgrade the DNS server software on existing DNS servers: • Factor A99: Determination of the requirement to standardise on a particular version of the same DNS server software ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has an existing multiple DNS server infrastructure  Has identified the requirement to upgrade one or more of the existing DNS servers to a newer version of the same DNS server software to permit support of identified design requirements, and  Wishes to determine the requirement to standardise all DNS server software versions in use within the DNS infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology strongly recommends that all DNS server software within a DNS infrastructure standardise upon a single source and version of software. For example, all DNS servers should use the Windows Server 2003 DNS server software, or all DNS servers should use BIND DNS server software, version 9.0, and so on. Where there is a requirement to upgrade one or more existing DNS servers within a DNS infrastructure to a newer version of DNS server software, then consider the issuance of a directive to ensure:  The latest version or latest bar one is used (which ever version permits support for all identified design requirements), and  The software version is applied to all DNS servers within the DNS infrastructure, to standardise all servers on the single version Standardisation of DNS server software is associated with the following examples of advantages:  Reduced administrative overheads for server maintenance are achievable because there is no requirement to maintain two or more different versions of software that require, for example, patching, configuration, removal, and installation, and so on.  It is possible to reduce training costs if there is a requirement only to learn one version of software across the entire DNS infrastructure.  Requirements for skilled resources to manage the DNS infrastructure are simpler to meet since the resources only need to be skilled in one version, and not multiple versions of DNS server software.  The technical capabilities of all DNS servers are the same, and hence it is possible to design and develop standard configurations for DNS server roles that can apply to all DNS servers within a role. Multiple versions of DNS server software may result in the requirement to develop multiple standard configurations to cater for the differences in technical capabilities of each version of software. There are hence administrative and financial overheads associated with this requirement. Standardisation of DNS server software is associated with the following examples of disadvantages:

Page 316 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 There may be DNS servers within a DNS infrastructure that can support of the identified design requirements that pertain specifically to their role and function within the DNS infrastructure, but are operating on an older version of software. An upgrade of the DNS server software on these DNS servers, to ensure standardisation on a newer version of software, may not be possible due to, for example, the lower hardware specifications of the server or the version of operating system that supports the DNS server. The additional financial and administrative overheads associated with the upgrade of server hardware and / or operating system version may be prohibitive and hence may prevent standardisation of DNS server software.  The financial overheads associated, for example, with the purchase of licenses for the DNS server software may be prohibitive where they are required for a large number of DNS servers within a DNS infrastructure.  There may be an administrative overhead associated with the deployment of the new version of DNS server software to all DNS servers. This process requires careful planning to ensure no loss of data or business continuity during the upgrade process (see later for details). Using the above information, execute the following:  Determine and document the requirement to standardise all DNS servers within a DNS infrastructure on a particular version of DNS server software  Determine and document the required version of DNS server software that meets all of the identified design requirements for the DNS server infrastructure, to support the defined scope of the Active Directory infrastructure. • Factor A100: Determination of the dependencies on the installation of the DNS server software ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the dependencies associated with the installation of version of DNS server software, which may influence the ability to upgrade the software to a newer version. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Some versions of DNS server software are dependent upon other software or operating systems, and hence may not have a simple upgrade path to a new version. For example, Windows DNS server software is a component of the Windows Server operating system and is not installable discretely to the operating system. Thus, for example, it is not possible to upgrade from a Windows NT 4.0 DNS server to a Windows Server 2003 DNS server without upgrading the operating system from Windows NT 4.0 to Windows Server 2003. This dependency may hence generate financial and administrative overheads, such as:  Upgrading or replacing the existing server hardware to permit support for the new operating system  The cost of licensing, administration, training, and so on to use the new operating system  The requirement to design the configuration, deployment, and management of the new server operating system

Page 317 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Where a DNS server, using an older version of the DNS server software, concurrently supports a discrete application or service, and the required newer version has dropped support for a feature used within the older version, then the upgrade may not be possible. In this scenario, upgrading the DNS server to a newer version may jeopardise the operation of the application or service that relies upon a specific feature no longer supported in a newer version of the software. Using the above information, execute the following:  Determine and document the presence of any dependencies upon the upgrade of a version of DNS server software to a required newer version  Upon identification of such dependencies, determine and document whether it is feasible to perform the upgrade to a newer version of DNS server software. If it is not feasible, then determine and document the most appropriate course of action required to permit the upgrade. • Factor A101: Determination of the design task requirements to execute an upgrade ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design tasks necessary to execute an upgrade of their existing DNS server software to a newer version. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The upgrade of DNS server software requires careful planning to ensure protection against loss of DNS zone data and business continuity. The following high-level generic steps are involved in the upgrade of the DNS server software, regardless of the source or version of the software: The following pre-upgrade tasks require execution:  Determination of the dependencies generated by the DNS server within the DNS infrastructure for an organisation  Analysis of the identified dependencies to determine the most suitable time for upgrade of the DNS server without disrupting business continuity  Backup of the current DNS server, including all zone and configuration data  Isolation of the DNS server (stopping all server services) to prevent connections by clients, applications, and other processes during the upgrade process  Removal of the old version of DNS server software (where required)  Preparation and submission of a change request to upgrade the DNS server software (see next sub-section on “modification of current DNS server configuration” for details of considerations for compliance with change control infrastructures) The following upgrade tasks require execution:  Upgrade of the server hardware (where required)  Upgrade of the server operating system (where required)  Configuration of the upgraded server operating system (where required)  Installation of the newer version of the DNS server software, plus any patches / hot fixes and so on, where required

Page 318 of 467

Last printed 28/5/2004 11:50 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The following post-upgrade tasks require execution:  Restoration of DNS zone data, as appropriate, and configuration of the newer version of the DNS server software to support all identified design requirements  Backup of the new DNS server, zone data, and configuration information The first step in the pre-upgrade process, to determine the dependencies generated by a DNS server within a DNS infrastructure for an organisation, is critical to the success of the upgrade process. An existing DNS server may support a multitude of applications, clients, processes, and services. Taking a DNS server temporarily out of production for an upgrade may disrupt many such support functions, and hence may affect business continuity. Based upon the identified dependencies, it may be necessary, for example, to perform the upgrade of a DNS server outside of normal business hours, and preferably during a weekend. It is important to ensure a full backup is made of the DNS server, all zone data stored locally on the server, and all configuration information (for example, stored in the registry). This is critical should the upgrade process fail, and there is the requirement to restore the original DNS server. Prior to performing the upgrade of the DNS server, it is important to isolate the server from clients, applications, processes, and services within the production environment. Also, to prevent any administrative sessions on the DNS server, disable any terminal software that permits remote administration of the DNS server. Where possible, take the DNS server off the production network for effective isolation. Where it is necessary to remove the older version of the software prior to installation of the newer version, then ensure that the removal process does not leave behind any files or registry entries that may affect t