Transcript DNS Name
Module 2: Designing an Active Directory Naming Strategy Overview Identifying Business Needs DNS and Active Directory Planning Active Directory Domain Names Designing a DNS Naming Strategy for Active Directory Resolution of unique names is the cornerstone of identifying and accessing objects in Microsoft® Windows® 2000 Active Directory™ directory service. Active Directory uses the Domain Name System (DNS) as a basis for naming domains. The hierarchical structure of Active Directory is derived from the root domain, which is the first domain created. Carefully selecting an inclusive DNS name for the root domain is crucial because an inclusive name may make it easier for users to access the network over the Internet and also enable network flexibility. At the end of this module, you will be able to: Identify business needs that impact the selection of Active Directory names. Describe how Active Directory is integrated with DNS. Plan Active Directory names within the Active Directory hierarchy. Design a DNS naming strategy for Active Directory root domains. Identifying Business Needs Main Business Needs that Impact a Naming Strategy: Intended Scope of Active Directory Internet Presence The initial root domain name will influence the structure of the Active Directory hierarchy. A properly selected name should accommodate the current and future planned business needs of an organization. The two primary business considerations that affect the naming of an Active Directory structure are how much of the organization Active Directory should include, and whether or not the organization plans to make some or all of its resources available on the Internet. Intended Scope of Active Directory When assessing business needs, you need to determine the scope of the planned Active Directory structure. Before you implement Active Directory, you must first determine how the Active Directory structure will meet the business requirements of the organization. Thus, the design of the Active Directory structure should accommodate one or more of the following possibilities, depending on the business requirements: Will the Active Directory structure include the entire organization, including subsidiaries? Will the Active Directory incorporate partners or customers in the future? Are you anticipating any mergers or acquisitions in the next two to five years? Internet Presence You must consider whether or not the organization's Active Directory will ever be available on the Internet. If so, you must choose a name for the Active Directory root that adheres to Internet standards. You must also choose a DNS strategy to support the Active Directory. DNS and Active Directory Distinguishing Between DNS and Active Directory Interoperability with BIND Active Directory follows DNS standards for naming domains, servers, and services. Active Directory also uses DNS as the domain locator service. You can use DNS for name resolution of both intranet (internal) and Internet (external) resources in your organization. There are special considerations you must take into account if your organization uses a Berkeley Internet Name Domain (BIND) DNS server and insists on maintaining it. In this lesson you will learn about the following topics: Distinguishing between DNS and Active Directory Interoperability with BIND Distinguishing Between DNS and Active Directory DNS Servers Store Resource Records Active Directory Servers Store Domain Objects Domain Name System (DNS) contoso.msft Active Directory can consist of one or more domains. You identify Active Directory domains by the DNS names you assign them. AD Concepts The Active Directory domain and the corresponding DNS domain have the same name, yet each has a distinct role. These two domains store different information and manage different objects. DNS servers store and manage resource records within a zone database file. A DNS zone database file contains all resource records for a single DNS domain, or a discreet portion of a DNS domain tree. Active Directory stores and manages domain objects. Objects in the Active Directory include users, computers, printers, servers, workstations, services and shares. All objects are stored within Active Directory and managed either by scripting, or by tools within Microsoft Management Console (MMC). Because Active Directory and DNS domain names are identical and DNS is the mechanism for performing name resolution, each Active Directory domain requires a corresponding DNS domain. However, each DNS domain does not require a corresponding Active Directory domain. Interoperability with BIND Windows 2000 DNS Server Service Offers Maximum Compatibility BIND DNS Servers Can Be Integrated with Active Directory BIND 8.2.1 or later recommended Windows 2000 DNS Server service is fully compatible with Active Directory. However, some organizations may use BIND DNS servers and insist on maintaining their use. Certain versions of BIND can be integrated with Active Directory. If a business need requires that the existing BIND servers be kept in place, you can make one of four choices: Use BIND for external access and Windows 2000 DNS for internal access. Use BIND for both Internet (external) and intranet (internal) access. Use BIND for internal and external access, but place the Active Directory domain on the Windows 2000 DNS server. Use Windows 2000 DNS for both external and internal access. If a BIND server is used for external resources and a Windows 2000 DNS server for Active Directory, you may need to delegate the Active Directory subdomains. These are the subdomains that are used by client computers to gain access to services in Active Directory. While some earlier versions of BIND will function with Active Directory, BIND 8.2.1 is the minimum recommended version. BIND 8.2.1 supports the SRV (service) resource records, dynamic updates, negative caching, and incremental zone transfers. The following table compares the features supported in Windows 2000 DNS and BIND: Note: For more information on SRV resource records and dynamic DNS, see RFC 2782 and RFC 2136. Feature Windows 2000 BIND 8.2.1 BIND 4.9.7 SRV records Yes Yes Yes Dynamic Update Yes Yes No Secure Dynamic Update Yes No No WINS & WINS-R records Yes No No Fast zone transfer Yes Yes Yes Incremental zone transfer Yes Yes No UTF-8 character encoding Yes No No Planning Active Directory Domain Names Determining the Scope of Active Directory Designing the Naming Hierarchy Choosing Active Directory Domain Names Because Active Directory is tightly integrated with DNS, you should adhere to DNS standards when planning the naming strategy for Active Directory. Your Active Directory design should include: Determining the scope of Active Directory within your organization. Designing a hierarchical DNS name. Choosing Active Directory domain names by using a naming strategy. Determining the Scope of Active Directory DNS Name Should Represent Entire Organization Headquarters Branch Locations Business Partners Active Directory Name Can Be Internet Name Register Name with ICANN When you determine the scope of Active Directory, make it as broad as possible to avoid having to restructure it later. When considering the scope for naming, you should consider not just the internal organization, but whether the organization will have an Internet presence. Your DNS Name Should Represent Your Entire Organization Because Active Directory can accommodate only one DNS root name, you should choose a name that represents the entire organization. This name will allow all users within the organization to access all information and resources within the organization. There are instances, however, when the organization may require more than one root name. For example, if the organization has acquired a company that already has a well-established identity on the Internet, you might want to retain the DNS name of the newly acquired company. The Active Directory Name Can Be Your Internet Name Active Directory can exist within the scope of the Internet DNS structure. In this case, you must register the DNS root name with the Internet Corporation for Assigned Names and Numbers (ICANN). Registration ensures the global uniqueness of all DNS names. You will have the authority to manage your own hierarchy of child domains, zones, and hosts within the root domain. Designing the Naming Hierarchy Root DNS Name: contoso.msft contoso.msft Child namerica.contoso.msft DNS Name: namerica.contoso.msft Child europe.contoso.msft DNS Name: europe.contoso.msft Domains in Active Directory are arranged in a hierarchical structure that reflects their relationships to each other. Within the network, each domain must have a unique DNS name that matches the Active Directory domain name. Client computers running Active Directory use these names to identify and locate domain controllers for logon purposes. The goal in designing your naming hierarchy is to reflect the organization logically. The First Domain Is the Root Domain The first domain created in Active Directory is the starting point, or root, of Active Directory. All other domains are derived from the root domain. Only one name can be used for the root domain. If you plan an Internet presence using this root name, the name must be unique on the Internet. Important: You cannot change the name of the root domain in your Active Directory forest without removing Active Directory and creating a new forest Domains Derived from the Root Domain Form a Hierarchical Tree If you have multiple domains in Active Directory, a naming hierarchy is formed. For example, a network with a single domain might have the single domain name, contoso.msft. If business needs require you to divide your network into three domains, North America, Europe, and Africa, your domain names could be namerica.contoso.msft, europe.contoso.msft, and africa.contoso.msft. Each domain name is separate, but maintained within the same Active Directory tree. Choosing Active Directory Domain Names Choose a Root Domain Name Unique to the Internet Conform to DNS Naming Regulations Register Your DNS Domain Name Choose Meaningful, Stable, Scalable Names Use An Existing DNS Domain Name Because Active Directory naming follows the standard DNS format, DNS must be installed on your network, and Active Directory names must conform to DNS naming guidelines. When choosing Active Directory domain names, consider the following strategies: The Active Directory root domain name must be unique in the DNS hierarchy. If your network connects to the Internet, choose a name that is unique on the Internet. If your network connects to the Internet, the DNS name of each Active Directory domain must conform to Internet domain naming rules. Note: For more information on DNS character standards, see RFC 1034, RFC 1035, and RFC 1123. You will need to register the DNS domain name you designate as the root Active Directory domain with ICANN if you plan to use the name for both external and internal access. Choose domain names that are recognizable, meaningful, and stable, such as geographical names. Choose a name that can last three to five years, and that can accommodate the addition of child domains, which might occur in the case of a reorganization or acquisition. Use an existing DNS domain name within the registered DNS hierarchy for the organization. Create a new domain name as a child domain of the existing DNS domain namespace, such as corp.contoso.msft. Note: The draft that reserves .local for local domain names has expired. For more information, see www.ietf.org/proceedings/99jul/I-D/draft-ietf-dnsindlocal-names-07.txt. Designing a DNS Naming Strategy for Active Directory Making Initial Naming Decisions Using a Delegated Subdomain Name for the Internal Network Using a Single DNS Name for Public and Private Networks Using a Different DNS Name for Public and Private Networks Designing a DNS Solution to Integrate with BIND Design Guidelines Designing a DNS Naming Strategy for Active Directory There are several ways that you can design a DNS naming strategy for the Active Directory root domain. Most of these choices will reflect whether the organization has, or plans to have, an Internet presence. If the organization chooses to have an Internet presence you must decide whether to separate your internally accessible resources from your externally accessible resources. Depending on your Internet strategy and existing DNS implementations, you can use one or more of the following guidelines. Use a subdomain of a registered DNS domain name as the Active Directory root. Use the same DNS root domain name for your Active Directory structure and Internet presence. Use a different DNS domain name for your Active Directory root to maintain separation between your Active Directory structure and your Internet presence. In this lesson you will learn about the following topics: Making initial naming decisions. Using a delegated subdomain name for the internal network. Using a single DNS name for public and private networks. Using a different DNS name for public and private networks. Designing a DNS solution to integrate with BIND. Design guidelines. Making Initial Naming Decisions Registering the DNS Root Name Designing with an Existing DNS Implementation Determining Internal and External Naming Strategies Meeting Requirements of the DNS Design Assuring Client Name Resolution There are important initial decisions you need to make when designing a DNS naming strategy. The impact of not considering these items could necessitate a reinstallation of Active Directory in the future. Registering the DNS Root Name If you choose to have an Internet presence, you must obtain a registered DNS domain name. Even if you do not anticipate an Internet presence, it is recommended that you still register your chosen root name with ICANN so that a future move to the Internet will not require renaming your root. Designing with an Existing DNS Implementation Windows 2000 DNS server service is recommended because it supports full functionality with Active Directory. If you use the BIND DNS server, you will need to make design choices based on your naming strategy. You may need to upgrade your BIND servers, or opt to convert to Windows 2000 DNS. Determining Internal and External Naming Strategies If your organization has an Internet presence, securing the internal resources is a priority. How you choose to separate your internally accessible resources from your externally accessible resources will impact the design. Meeting Requirements of the DNS Design When determining the naming approach for your organization, make sure the design meets the following requirements: Expose only the public part of the organization's namespace to the Internet. Enable all Active Directory client computers to resolve all of the organization's internal and external names. Make sure that client computers requiring access to the Internet can resolve any names from the Internet. Assuring Client Name Resolution to the Organization's External Resources The external DNS server should only have resource records for the external hosts and services that will be exposed to users of the Internet. To allow internal clients to gain access to your organization's Internet data, you can place servers with duplicate content on the internal network, using the same DNS names as the servers on the Internet. Therefore, the external DNS servers will resolve the organization's DNS names to an external IP address, and the internal DNS servers will resolve the organization's DNS name to an internal IP address. Assuring Client Name Resolution of Internet Hosts Additional configuration may be required for the internal hosts to access public Internet resources. You can configure the internal DNS server to forward all irresolvable DNS requests to an external DNS server. If a proxy server is used, create an exclusion list for the clients. The proxy server will forward all requests received to an external DNS server. Considerable planning will be required for the firewall to specify exactly what types of traffic from internal clients will be allowed through the firewall to the external network. This can be accomplished by using either a firewall or a combination of a firewall and a proxy server. Using a Delegated Subdomain Name for the Internal Network Create a New DNS Zone in New Domain Configure Authoritative DNS Server in Existing DNS Domain to Delegate to New Domain Create Active Directory Forest Root in New Domain contoso.msft Zone 1 Firewall ad.contoso.msft Zone 2 Instead of using the organization's registered DNS domain name as the root domain of Active Directory, you can use a DNS child domain. The child domain exists in a separate zone, and is designated as the Active Directory root domain. You should only expose the zone containing the DNS root domain to the Internet. For example, the company called Contoso, Ltd. decides to use the domain ad.contoso.msft for its Active Directory root domain. The Contoso, Ltd. Information Technology (IT) team must first do the following: Create a new DNS zone on a separate DNS server that encompasses the ad.contoso.msft domain. Configure the DNS server that is authoritative for contoso.msft with a delegation record to the other DNS server for the ad.contoso.msft domain. Create the root of the Active Directory forest in the ad.contoso.msft domain. The name of the Active Directory root domain will be ad.contoso.msft. The implications of using a Delegated Subdomain Name for the Internal Network are as follows: This solution allows isolation of all Active Directory data in its domain or domain tree. This solution provides a contiguous namespace, creating less confusion for the administrative staff and clients. The delegated Active Directory root domain requires its own DNS server. However, it does not require upgrading the DNS servers that currently serve the existing registered DNS domain. Active Directory name structure is longer because naming starts at a third-level domain. Using a Single DNS Domain Name for Public and Private Networks Zone for contoso.msft without internal servers Public Internet Firewall Zone for contoso.msft with internal servers Private Internal Network You may want to retain a single DNS domain name for both internal and external use. However, you want to ensure that the internal network is kept separate from the Internet. Separating DNS Zones by Using a Firewall You can create two DNS zones with the same name on either side of a firewall, and then manage the contents of those zones so that the appropriate records are present in each. In this scenario, the DNS server on the public network would maintain records only for hosts to be accessed from the Internet. The DNS server on the internal network would have the resource records that would be exposed to all internal hosts, including all resource records related to Active Directory. Using the firewall to separate DNS zones requires administration of the SRV resource records. You must ensure that only the appropriate resource records are exposed to external requests. The implications of using a single DNS domain name for Public and Private Networks are as follows: Users can use a single domain name whether accessing resources from the internal network or from the Internet. Additional administration by the DNS administrators is required to ensure the appropriate records are on the internal and external DNS servers. Configuration of a firewall can be more complex when protecting the internal network from the Internet. No additional names need to be registered with the ICANN. If external resources are mirrored on the internal network, synchronizing the data can be challenging. Using a Different DNS Name for Public and Private Networks Zone for contoso.msft without internal servers Public Internet Firewall Zone for contosoltd.msft Private Internal Network An alternative to creating separate views of a single domain for public and internal clients is to use different domain names for the public and private networks. For example, Contoso, Ltd. could use contoso.msft on the public network, and use contosoltd.msft for the internal network. This solution makes the division of public and private resources very simple. All public resources use one domain name, and all internal resources on the private network use another domain name. Assuring Client Name Resolution Remember that you can allow clients to resolve external names for both your organization and other Internet hosts by configuring the internal DNS server to forward all requests it is unable to resolve to the external DNS server. For proxy clients, create an exclusion list. Considerable planning will be required for the firewall to specify exactly what types of traffic from internal clients will be allowed through the firewall to the external network. This can be accomplished by using either a firewall or a combination of a firewall and a proxy server. The implications of using a different DNS name for public and private networks are as follows: Resources are more manageable and secure because there is a clear distinction between public and private resources. The internal naming hierarchy is not exposed on the Internet. Internal resources are inaccessible from the Internet by using the external domain name. You will no longer need to replicate external server content to internal servers. When accessing a company resource from the Internet, some users may be confused by the different name. It may not be necessary to register additional names with ICANN. You may need to upgrade DNS servers to provide support for SRV resource records. Existing DNS infrastructure and host names can remain unchanged and will match the Active Directory domain name. Existing DNS zones and DNS topology can remain unchanged. Designing a DNS Solution to Integrate with BIND To Integrate BIND and Microsoft DNS You Can Use Existing DNS Strategy as the Root of Active Directory Create a Subdomain of the Existing DNS Strategy as the Root of Active Directory Keep the Existing BIND DNS Strategy, and Register Another Domain Name for the Root of Active Directory If your organization mandates that existing BIND servers version 8.2.1 or higher be maintained, you must decide how to integrate them with Microsoft DNS servers. Strategy To Integrate: Use existing DNS strategy as the root of Active Directory On the BIND DNS server, create the following subdomains: _msdcs.domainname _sites.domainname _tcp. domainname _udp. domainname Create a subdomain of the existing DNS strategy as the root of Active Directory On the BIND DNS server, delegate the subdomain to the Microsoft DNS server. On the Microsoft DNS server, create the subdomain. On the Microsoft DNS server, enable dynamic updates. Configure the necessary Microsoft DNS Secondary servers, or integrate the zones with Active Directory. Keep the existing BIND DNS strategy, and register another domain name for the root of Active Directory Create the new zone on the Microsoft DNS server as an Active Directory integrated zone. Create a secondary zone for the new domain on the BIND server. Create a secondary zone for the existing DNS name on the Microsoft DNS server. Have DNS clients point to either the existing BIND DNS server or the MS DNS server for the DNS name resolution. The table summarizes DNS naming strategy design choices and their implications. Design Choice Implications Delegated subdomain for the internal network Isolates all Active Directory data from the public resources in its domain or domain tree. Contiguous namespace. The delegated Active Directory root domain requires its own DNS server. Does not require upgrading any existing DNS servers. Fully qualified domain names of hosts will be longer. Users can use a single domain name. Additional administration is required. Configuration of a firewall can be more complex. No additional names need to be registered. Must synchronize with mirrored external resources. Management and security are easier due to a clear distinction between public and private resources. The internal naming hierarchy is not exposed on the Internet. Single DNS name for public and private networks Different DNS name for public and private networks Design Guidelines Naming Strategies Include: Delegated Subdomain for the Internal Network Single DNS Name for Public and Private Networks Different DNS Name for Public and Private Networks The following flow chart represents a decision tree that is useful for determining the appropriate naming strategy for an organization. Lab A: Planning an Active Directory Naming Strategy Review Identifying Business Needs DNS and Active Directory Planning Active Directory Domain Names Designing a DNS Naming Strategy for Active Directory