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

If your AD domain and your public domain are the same name, you meet this the first time you publish anything.

Your domain controller holds an authoritative zone for the domain. Authoritative means it answers for every name under it. Ask it for a host it does not have, and it returns NXDOMAIN - it does not fall through to public DNS, because as far as it is concerned it already knows the answer, and the answer is no.

So the site you just published works from everywhere in the world except your own network.

Confirm this is what you have

Ask a public resolver and your internal one the same question, and compare.

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

On Windows:

Resolve-DnsName www.example.com -Server 1.1.1.1
Resolve-DnsName www.example.com

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 public DNS returns. It works this afternoon.

It breaks in eight months, silently, when your host changes its addresses - and it breaks only for people inside your network, which is the hardest kind of fault to hear about. If the site is behind a CDN or a proxy, those addresses are shared infrastructure and change without notice.

Delegate the subdomain instead

A delegation tells your domain controller: "I am not authoritative for this child name, go and ask these nameservers." Your internal clients then get whatever public DNS currently says, forever, with no addresses written down anywhere.

In DNS Manager on the domain controller:

1. Expand Forward Lookup Zones and select the zone for {{DOMAIN}}
2. Right-click the zone, choose New Delegation
3. Delegated domain: {{SUBDOMAIN}} (just the label, not the full name)
4. Add the nameservers your public zone uses: {{NS1}} and {{NS2}}
5. Finish, and give it a minute

Verify from a machine inside the network

ipconfig /flushdns
Resolve-DnsName www.example.com

You should now get the same answer a public resolver gives. Test the site itself too, not just the lookup - name resolution and a working TLS handshake are different things.

Why not point the apex at it as well

Tempting, and usually a mistake.

The apex is the name your domain controller answers with the addresses of your domain controllers. That is load-bearing for domain join, authentication and service location. Adding a public identity to the same name means the apex means two different things depending on where you ask, and every future DNS question becomes ambiguous.

Keep the public site on a subdomain. If you want the apex to reach it for outside visitors, do that with a redirect at your public DNS provider, not by changing what the apex means internally.

The alternative if you cannot delegate

Some environments will not allow a delegation. A conditional forwarder is sometimes suggested, but note that an authoritative zone normally wins over a forwarder for names inside it, so it may not do what you expect.

The honest fallback is a CNAME in the internal zone pointing at a stable public name that you control and that will not change. That still writes a name down, but a name is a far more stable thing to write down than an address.