Thinking about it that way gives me conflicted feelings. Much as I hate what Google has done here I also feel like any organization stupid enough to use their public domain name for their Active Directory domain name deserves every little pain they receive for it.

You lack the compassion that comes with experience.

My $dayjob has our AD root domain the same as our public root domain. Because we implemented AD in the year 2000, and this was Microsoft’s recommendation for domain naming way back then.

And if you use Exchange, you can’t rename your AD domain, you have to rebuild your forest and migrate piecemeal. So we’re stuck with it.

The practice of using Corp.example.com did not evolve until many years after Windows 2000 and Exchange 2000 were in the wild.

So we run http redirectors on each of our domain controllers to send traffic to www.

This one is kind of a "religious" topic for me, I guess. I'm sorry that it is, but it makes me exceedingly defensive.

I trained on Active Directory (AD) with a group of veteran sysadmins in 1999. I don't have access to the "Microsoft Official Curriculum" book from my class in '99 (long-since thrown away), but I have a distinct memory of a lively conversation in class re: the pitfalls of using a public domain name as an AD domain name (or, worse yet, a Forest Root domain name) during the class. It was very evident to our group of veteran sysadmins that using a public domain name in AD would create silly make-work scenarios (like installing IIS on every DC just to run redirect visitors to "www.example.com"-- just as you describe, albeit IIS didn't natively support sending redirects at the time).

I'd go further and suggest that anybody with a modicum of familiarity with DNS knows having multiple roots-of-authority for a single domain name is a bad idea. Microsoft not supporting split-horizon in their DNS server (like BIND does with 'views') compounded the difficulties with such a scenario in an all-Windows environment.

I certainly wouldn't argue that Microsoft has given exclusively good recommendations for AD domain names in the past (evidence ".local" in Windows Small Business Server), but I am reasonably certain that their documentation always suggested that using a subdomain of a public domain name was a supported and workable option.

I started deploying AD in 2000. I've deployed roughly 50 forests in different enterprises, and I've never used a public domain name as an AD domain name. I've domain-renamed all my subsequently-acquired Customers for whom it was an option (which it was, so long as they had not yet installed Exchange 2007), and have been rebuilding the Forests of Customers who made the wrong decision in the past, where it makes economical sense.

Microsoft has provided mechanisms for split-horizon DNS service since Server 2003. views are not the only way of providing split-horizon DNS service.

* http://jdebp.info./FGA/dns-split-horizon.html#SeparateConten...

Windows 2000 didn't support stub zones, however. At the time that Active Directory was new there wasn't a good way to do split-horizon DNS with the Windows DNS server.

As an aside: I really enjoy your writing about using SRV lookups. It makes me sad that SRV records aren't being as much as they could / should be.

I don’t know anything about AD, so this might be a stupid question: can you not just run a web server on the same host as the AD server or port forward all HTTP traffic to a different server?

A domain controller on the internal network might not be the right place to run a copy of the public-facing content HTTP server (which might be in a datacentre, or even managed and run by an outside party, and might not be served by IIS). Then there are considerations of firewalling rules, browser rules, anti-virus rules, and even DNS rules for machines on the internal network that access a public WWW site that DNS lookups map into non-public IP addresses. (To prevent certain forms of external attacks, system administrators have taken in recent years to preventing this very scenario from working by filtering DNS results.)

* http://jdebp.eu./FGA/dns-split-horizon-common-server-names.h...

* http://jdebp.eu./FGA/dns-ms-dcs-overwrite-domain-name.html

* http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html

From the two comments above, it sounds like yes, some people who named their AD the same as their root DNS zone now have to run Http forwarders.

And the other comment mentioned that this was a known issue 20 years ago because the old versions of IIS did not support redirecting.

We beat this to death on Serverfault.com 9 years ago, so I'll spare all the rehashing here: https://serverfault.com/questions/76715/windows-active-direc...

Having a disjoint DNS namespace (and the needless make-work that it creates) is the issue, more than running HTTP servers on all your DCs to do redirects. There is absolutely no practical advantage to running an Active Directory domain with a public DNS name. It's all downside. It has always been all downside, and anybody who had any experience with DNS could see that all the way back in the beta and RC releases of the product in 1999 and 2000.