Resolving Internal DNS Conflict: Accessing Public Website When AD Domain Matches External Domain Name


3 views

When your Active Directory domain name (example.org) matches your public website domain, Windows DNS servers will prioritize internal AD records over external DNS resolution. This creates a classic split-brain DNS scenario where internal clients can't reach your public website using the base domain.

Active Directory Domain Controllers automatically register DNS records for the domain root (example.org) to handle domain operations. These records include:

; DC records in DNS
example.org.      600    IN    A    192.168.1.10
example.org.      600    IN    A    192.168.1.11
_gc._tcp.example.org. 600 IN SRV 0 100 3268 dc1.example.org.
_ldap._tcp.example.org. 600 IN SRV 0 100 389 dc1.example.org.

Configure your internal DNS servers to forward requests for specific records to external resolvers:

# PowerShell to set conditional forwarding
Add-DnsServerConditionalForwarderZone 
   -Name "example.org" 
   -MasterServers 8.8.8.8,1.1.1.1 
   -PassThru

You can prevent DCs from registering the root domain name (not recommended for production):

# Registry modification to limit DC registration
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" 
   -Name "DnsAvoidRegisterRecords" -Value "LdapIpAddress, GC" -Type String

Ensure your web server handles both www and apex domains:

<VirtualHost *:80>
    ServerName example.org
    ServerAlias www.example.org
    Redirect permanent / https://www.example.org/
</VirtualHost>

For future deployments, always use a subdomain for AD (e.g., ad.example.org or corp.example.org). This completely avoids the collision issue while maintaining branding consistency.


This is a common infrastructure challenge where your Active Directory domain name (example.org) conflicts with your public website domain. When internal clients try to access http://example.org, Windows DNS servers return the IP addresses of domain controllers instead of your web server.

The root cause lies in how AD-integrated DNS works:

  • Domain controllers automatically register their A records in the DNS zone
  • Internal DNS queries prioritize AD records over external resolutions
  • The naked domain (example.org) typically points to DCs while www.example.org resolves correctly

Option 1: DNS Zone Delegation
Create a separate DNS zone for your web hostname:

# PowerShell to create DNS delegation
Add-DnsServerZoneDelegation -Name "example.org" 
-ChildZoneName "www" 
-NameServer "ns1.yourwebhost.com" 
-IPAddress "x.x.x.x"

Option 2: Split-Brain DNS
Maintain separate internal and external DNS zones:

# Sample BIND configuration for internal view
view "internal" {
    match-clients { localnets; };
    zone "example.org" {
        type master;
        file "internal/example.org.zone";
    };
};

Hosts File Workaround (temporary fix):

# Sample hosts file entry
203.0.113.45 example.org # Your web server IP

HTTP Redirect Solution:

# IIS URL Rewrite rule example
<rule name="Redirect naked to www">
    

For permanent solutions, I recommend either:

  1. Registering a dedicated AD domain (e.g., corp.example.org)
  2. Implementing proper DNS zone delegation

The most robust enterprise solution combines both DNS delegation and HTTP redirects to ensure seamless access from all locations.