You have four basic design options when planning a DNS domain name strategy. In all cases, however, the most important consideration is that the root domain for any Active Directory domain tree must be registered with a naming authority. Otherwise, you run the risk of conflicts when connecting your organization to the Internet. The options are as follows :
Each option has its pros and cons, which are discussed in the following sections. Use the Same DNS Domain Name Internally As ExternallyUsing this option, there is no difference between the internal and the external DNS name. The network is effectively split at the firewall, with external resources resolved by one or more external DNS servers and internal resources resolved by the internal servers. Any external resources, such as Web, mail, and FTP servers, must have host records added manually to the internal DNS. Likewise, any internal resources that can be accessed from the Internet, such as virtual private network (VPN) servers, must be defined in the external as well as the internal DNS servers. This approach is simple and effective, but care must be taken if the external DNS servers are capable of dynamic update. For security reasons, you should not publish the SRV records from the internal hosts to the external DNS. Therefore, dynamic update must be turned off outside the firewall. Although it might seem like a given that Internet visitors can neither view the internal network nor update DNS, it is very easy to accidentally turn on dynamic update capabilities. Use Existing DNS Servers and Delegate Active Directory ZonesA company with an older DNS infrastructure and no need or desire to upgrade should give this option serious consideration. The four Active Directory subdomains, _msdcs, _sites, _tcp, and _udp, are delegated to either Windows 2000 DNS servers or any other DNS that supports SRV records and, ideally , dynamic update. Delegation means that responsibility for maintaining the subdomain is transferred to another DNS server or set of servers. In this case, when a domain controller attempts to dynamically update the locator SRV records, it is initially directed to one of the default non-Microsoft DNS servers, which in turn passes the request to the delegated server. Even if the primary DNS servers do not support either SRV records or dynamic updates, as long as the delegated servers do, the updates will occur correctly and Active Directory will function properly. As with the domain name solution mentioned previously, this approach is simple and maintains a single domain. Figure 4.3 shows the Active Directory subdomains that should be delegated when using this approach. Figure 4.3. Active Directory- related subdomains all start with the underscore character.
Create a Subdomain of the External Internet Domain for Use InternallyWhen you're integrating Windows 2000 in an environment in which an existing DNS infrastructure already exists to support non-Windows hosts (and changes should be minimal, if any), you should create a special subdomain for Windows 2000 hosts. This subdomain permits Windows 2000 servers and workstations to be managed separately from other non-Windows computers. It also clearly differentiates between the internal Windows 2000 network and the external network. The internal network is easily recognized because it is a subdomain off the registered first-level domain name. If the XYZ Corporation were to use this approach, the current namespace ”used both for external (Internet) and internal name resolution ”would remain unchanged. A new Windows 2000 subdomain would be created called ad.xyz.corp or something similar. Windows 2000 DNS servers would handle Microsoft client name resolution only, and resolution requests for the xyz.corp domain, as well as any external resources, would be forwarded to the existing DNS servers. In all likelihood , the ad subdomain would not be delegated from the xyz.corp root for security reasons. Create an Internal Network Name That Is Different from the External One (Split DNS)By creating a completely different internal DNS namespace, public and private resources are clearly distinguished from one another. This Split DNS approach is somewhat more complicated than the preceding three because two independent domain names must be registered. Some confusion could occur among system users who might not understand why their logon IDs, which map to the internal network, are different from the external, public, corporate DNS namespace. Email addresses also might be different from Windows 2000 logon IDs, depending on where the corporate email servers are located. DNS server configuration will be simpler, however. Delegating or forwarding requests to other servers will be unnecessary because each domain has a distinct namespace. Also, unlike single-domain solutions, you won't need to create duplicate host records for shared resources inside and outside the firewall. Common Goals of DNS Namespace Design OptionsUltimately, the goals of DNS namespace planning are simple:
|