Article Summary: This article provides information on issues that may arise in an environment in which the Active Directory domain and registered internet domain name are identical.
Best practices for Active Directory (AD) domain design advise against using a registered domain name as the name of an AD domain. Viable alternatives include using a non-public DNS suffix (.local or .lan, for example) in the AD domain name, or making the AD domain a subdomain of the registered domain (corp.domain.com, for example).
You won't always have a choice in the matter, though; you may find yourself supporting an AD domain that has the same name as the company's registered domain, and management may not wish to change either name. This is known as a split DNS (or split-brain DNS) scenario, in which there are two distinct DNS namespaces - the internal namespace used by AD, and the external namespace used by the public domain registrar - with the same name. This scenario can present some unique challenges. This article discusses some common issues arising from a split DNS environment and what can be done to mitigate them.
In all of the examples below, the AD domain and registered domain are both named domain.com, and there is a company website named www.domain.com.
Issue 1: Externally-hosted company website inaccessible from inside the office
This is the most common issue in a split DNS environment: the company's website, or another company-owned, internet-connected resource, can't be reached from inside the office by machines joined to the AD domain, but machines outside the office have no problems reaching the website. The reason this happens can be shown by examining what happens when an internal user attempts to browse the company's website:
The problem arises because a DNS server that has a particular lookup zone in its database - the domain.com zone in this example - will not send queries for records in that zone anywhere else; it will simply return a "not found" response if there is no record matching a given query. In this example, there is another DNS server with the correct record: the DNS server that hosts the public domain.com zone belonging to the domain registrar, as is evident by the fact that machines outside the office can reach the website. Queries from internal machines will never reach that server, though.
The solution to this problem is simple: create a host record named www in the domain.com zone on the DC and give that record the website's IP address. Machines that query that DNS server will then receive the correct response and be able to browse the website.
Issue 2: Internally-hosted public website inaccessible from inside the office
This could be considered a variation of issue 1 above. The difference in this case is that the website is hosted internally, either behind a firewall on the company's internal network or in a DMZ. It is supposed to be accessible to both internal and external users, but internal users are unable to reach it, while external users report no problems.
The reason for the issue is similar to that in issue 1, but internal users in this case are able to correctly resolve the website's name to its public IP address. However, they're still unable to reach the website because of the way the firewall is configured. It expects users on the internal network to access the website using its private address rather than its public address.
Again, there is a simple fix: create a host record named www in the domain.com zone on the DC, but this time give the record the website's private IP address. Internal machines will resolve the website's name to that private address, while external machines will continue to resolve the name to the website's public address.
Issue 3: Website loads incompletely or still won't load after the above changes are made
This can happen if the website code redirects browsers from www.domain.com to domain.com or if internal links refer to the site as domain.com rather than www.domain.com. The same symptoms will be seen on internal machines whether the site is hosted internally or externally:
The problem in this case is a bit more complex. In order for machines to resolve domain.com to an IP address, there must be a blank host record in the domain.com zone in DNS. The name of this record will show up as (same as parent folder) in the Windows DNS console. However, there's a problem in this case: AD uses blank host records in the domain.com zone to represent DCs for the domain.com domain. Domain members use those records when locating a DC for authentication, and if there are extra blank host records in the domain.com zone, delays or authentication problems may result.
For the reason above, this issue cannot be resolved in DNS alone. Creating a blank host record with the website's IP address will only intermittently resolve the website-access issue for internal users, because there will already be other blank host records with the IP addresses of the DCs in the domain, and doing so will cause domain authentication issues.
The simplest way to resolve this issue is to modify the website's code to either remove the redirection or fix the internal links so that everything refers to the site as www.domain.com rather than domain.com. If modifying the code is not possible, the only other option for resolving the issue is to rename the AD domain. This can be a complex task, depending on the size and complexity of the environment.
最終更新日: 09/08/2014 11:33 AM