Ahmad Gul Zadran

Publish a public website on the same domain your Active Directory owns

If Active Directory uses the same domain as your website, computers inside cannot open the site. Here is the fix.

intermediate15 minupdated 2026-10-13active-directorydnssplit-horizonwindows-serverDownload script.sh

Before you start

  • One domain name used for both Active Directory and your public website
  • Admin access to the DNS zone in Active Directory
  • The public zone at a DNS provider, and its nameserver names

Your values

Fill these in and every command below updates to match. Nothing is sent anywhere.

Run this at your own risk. These steps worked on my hardware; yours may differ. Take a backup first, read each command before running it, and see the disclaimer.

If your AD domain and your public domain have the same name, you will see this problem the first time you publish a website.

Your domain controller has an authoritative zone for the domain. Authoritative means it answers for every name in that domain. If you ask it for a name it does not have, it answers NXDOMAIN ("this name does not exist"). It does not ask public DNS, because it thinks it already knows the answer, and the answer is no.

So your new website works everywhere in the world, except in your own network.

Confirm this is what you have

Ask a public DNS server and your internal one the same question, and compare the answers.

bash
nslookup www.example.com 1.1.1.1
nslookup www.example.com

On Windows:

bash
Resolve-DnsName www.example.com -Server 1.1.1.1
Resolve-DnsName www.example.com
expected output
Name                    Type   IP Address
----                    ----   ---------
sub.example.com         A      203.0.113.10

Resolve-DnsName : sub.example.com : DNS name does not exist

Public says yes, internal says no. That is the whole problem.

Do not just add an A record

The obvious fix is to add an A record internally, with the same addresses that public DNS returns. It works today.

But it breaks months later, without any warning, when your hosting provider changes its addresses. And it breaks only for people inside your network, so nobody outside reports it. If the site is behind a CDN or a proxy, these addresses are shared and can change at any time.

Delegate the subdomain instead

A delegation tells your domain controller: "I do not answer for this subdomain. Ask these nameservers instead." Then your internal clients always get the same answer as public DNS, and you never have to write down any addresses.

In DNS Manager on the domain controller:

  1. Expand Forward Lookup Zones and select the zone for example.com
  2. Right-click the zone, choose New Delegation
  3. Delegated domain: www (only the first part of the name, not the full name)
  4. Add the nameservers your public zone uses: ns1.example-dns.net and ns2.example-dns.net
  5. Click Finish, and wait a minute

Verify from a machine inside the network

bash
ipconfig /flushdns
Resolve-DnsName www.example.com

You should now get the same answer as from a public DNS server. Also open the website itself, not only the DNS lookup. A correct DNS answer does not prove that the HTTPS connection works.

Why not point the apex at it as well

It is tempting, but usually a mistake.

The apex is the domain name itself, without a subdomain. Your domain controller answers it with the addresses of your domain controllers. Domain join, sign-in and finding services all depend on this. If the same name also points to your public website, it means two different things depending on where you ask. Every DNS problem after that becomes harder to understand.

Keep the public website on a subdomain. If you want visitors from outside to reach it through the apex, set up a redirect at your public DNS provider. Do not change what the apex means inside your network.

The alternative if you cannot delegate

In some networks you cannot add a delegation. Some people suggest a conditional forwarder. But for names inside an authoritative zone, the zone usually wins over the forwarder, so it may not work as you expect.

The best fallback is a CNAME in the internal zone. Point it to a stable public name that you control and that will not change. You still write something down, but a name changes much less often than an address.