Why your AD domain should not be your public domain

Naming the internal directory after the public domain creates split-brain DNS, and you pay for it for years. A subdomain costs nothing and avoids it.

Promoting a server to a domain controller asks you for a domain name. It looks like a formality — you own example.com, so you type example.com — and it is the single decision in this whole build that is hardest to undo.

What goes wrong with the obvious answer

If the internal Active Directory domain is called example.com, and example.com is also the domain your website and your mail live on, you have created split-brain DNS: two authoritative sources for the same zone, one internal and one public, which do not know about each other.

It works on day one. It costs a little every year afterwards, and the costs arrive as mysteries: a service that works from home and not from the office, a certificate renewal that fails only internally, a mail route that behaves differently for staff.

The answer that costs nothing

Use a dedicated subdomain for the directory:

ad.example.com          ← the Active Directory domain
corp.example.com        ← same idea, different taste

The internal DNS becomes authoritative for ad.example.com, which is a zone nobody outside uses. Queries for example.com are forwarded outward and answered by the public DNS, as they should be. There is exactly one authority for each name.

Users still get the address they should

The obvious objection: if the domain is ad.example.com, do users become [email protected]?

No. The directory name and the sign-in name are separate things, and this is the step that makes the subdomain choice free.

In Active Directory Domains and Trusts, add example.com as an alternative UPN suffix. Then set each user’s logon name to use it. Users are [email protected], matching their email address and their Microsoft 365 account, while the directory underneath is called something else entirely.

The rest of the promotion

Install the Active Directory Domain Services and DNS roles.
Promote to a domain controller in a new forest, with the subdomain as the domain name.
Set DNS forwarders — the firewall or a public resolver — so the server can resolve everything that is not its own zone.
Add example.com as a UPN suffix in Domains and Trusts.
Create an organisational unit for the users who will be synchronised, plus a dedicated admin account and one test user.
Snapshot, named for what it is.

The organisational unit in step 5 matters more than it looks: directory synchronisation can be filtered by OU, and having the accounts that belong in the cloud already separated from those that do not makes that filter a single click rather than a rethink.

Three things about the machine itself

A domain controller is critical infrastructure. Trusted network segment, always on, snapshots and backups. Not on the same VLAN as the IoT devices, and not a machine anyone powers off to free up memory.

Synchronisation is one-way. Once directory sync is running, the on-premises directory is the source of truth. Synchronised attributes are edited on-premises; changing them in the cloud either fails or gets overwritten at the next cycle. Worth knowing before someone fixes a surname in the wrong portal.