Knowledge Base

DNS Considerations in a Windows Environment with Identical Internal and External Domain Names

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 user's computer queries the domain's DNS server, typically a domain controller (DC), for the IP address of www.domain.com.

The DC hosts a forward lookup zone named domain.com, so it looks in that zone for a host record named www.

The DC finds no host record named www, and since it is authoritative for the domain.com zone, it does not query any other DNS servers.

The DC responds to the user's computer, saying that it could not find an address for www.domain.com.

The browser on the user's computer shows "Page cannot be displayed."

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 site may not load at all, in which case a user's browser will typically show domain.com in the address bar even if the user types www.domain.com into the browser.

The site may load incompletely; parts of the site may not display and/or links within the site may not function.

In both cases, external users are able to access the website with no problems.

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.

Quick Tips content is self-published by the Dell Support Professionals who resolve issues daily. In order to achieve a speedy publication, Quick Tips may represent only partial solutions or work-arounds that are still in development or pending further proof of successfully resolving an issue. As such Quick Tips have not been reviewed, validated or approved by Dell and should be used with appropriate caution. Dell shall not be liable for any loss, including but not limited to loss of data, loss of profit or loss of revenue, which customers may incur by following any procedure or advice set out in the Quick Tips.