Website unreachable in a Windows environment with identical internal and external domain names

In all the examples below, the AD domain and registered domain are both named domain.com, and there is a company website named www.domain.com. The identical domain names create a split (or split-brain) DNS environment. In this situation, the internal and external DNS namespaces have the same name but are separate.

Issue 1: An externally hosted company website is 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, cannot be reached from inside the office by domain-joined clients. Machines outside the office have no issues reaching the website.

Issue 2: An internally hosted public website is inaccessible from inside the office.
This is a variation of issue 1 above. The difference 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. External users report no issues.

Issue 3: The website loads incompletely or will not load after issue 1 or 2 is addressed.
The site may not load at all or may load incompletely for internal users. Parts of the site may not display, and links within the site may not function. External users can access the website with no issues.

Issue 1: An externally hosted company website is inaccessible from inside the office.

The reason this happens can be shown by examining what happens when an internal user attempts to browse the company's website:

1. The user's computer queries the domain's DNS server, typically a domain controller (DC), for the IP address of www.domain.com.
2. The DC hosts a forward lookup zone named domain.com, so it looks in that zone for a host record named www.
3. The DC finds no host record named www, and since it is authoritative for the domain.com zone, it does not forward the query.
4. The DC responds to the user's computer, saying that it could not find an address for www.domain.com.
5. The browser on the user's computer shows "Page cannot be displayed" or a similar error.

The issue arises because an authoritative DNS server does not send queries for names in its zones to other DNS servers. It returns a "not found" response if there is no record matching a given query. In this example, there are other DNS servers with the correct record: the DNS servers that host the public domain.com zone. This is evident from the fact that machines outside the office can reach the website. Queries from internal machines are not sent to that server, though.

Issue 2: An internally hosted public website is inaccessible from inside the office.
The reason for the issue is similar to that in issue 1. Internal users in this case can correctly resolve the website's name to its public IP address. However, they are 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.

Issue 3: The website loads incompletely or will not load after issue 1 or 2 is addressed.
This can happen if the website code redirects browsers from www.domain.com to domain.com. Internal links may also refer to the site as domain.com rather than www.domain.com. The same symptoms are seen on internal machines whether the site is hosted internally or externally.

The issue 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 shows up as (same as parent folder) in the Windows DNS console. However, AD uses blank host records in the domain.com zone to represent DCs for the domain.com domain. If there are extra blank host records in the domain.com zone, delays or authentication issues may result.

For the reasons above, this issue cannot be resolved using DNS alone. Creating a blank host record with the website's IP address only intermittently resolves the website-access issue for internal users. The existing blank host records referring to DCs interfere with this, due to round robin DNS functionality. Since those records are automatically registered by the DCs, if they are removed from the DNS zone, they reappear regularly.

Issue 1: An externally hosted company website is inaccessible from inside the office.
The solution to this issue is simple. Create a host (A) 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 then receive the correct response and can browse the website.

Issue 2: An internally hosted public website is inaccessible from inside the office.
There is a simple solution to this as well. Create a host record named www in the domain.com zone on the DC, but give the record the website's private IP address. Internal machines resolve the website's name to that private address, while external machines continue to resolve the name to the website's public address.

Issue 3: The website loads incompletely or will not load after issue 1 or 2 is addressed.
The simplest way to resolve this issue is to modify the website's code to remove the redirection. Also, internal links should refer 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.

Note: The website must be accessed using the name www.domain.com in all these examples. Accessing the site using the name domain.com does not work or only works intermittently.

Best practices for Active Directory (AD) domain design advise against using a registered domain name as the name of an AD domain. There are two suggested alternatives to this:

• Use a non-public DNS suffix (.local or .lan, for example) in the AD domain name.
• Make the AD domain a subdomain of the registered domain (corp.domain.com, for example).

This is only possible if the AD domain has not already been created or if a rename operation is underway.