Too bad I wasn't awake for the party, eh? I'll take a crack anyway.
I taught MCSE classes for several years, and Microsoft's recommendations were always fairly consistent between their various training materials.
Don't use a domain name you don't own for your Active Directory domain name (i.e. microsoft.com).
Don't use an FQDN for the domain that other DNS servers are already authoritative for (i.e. company.com)
Do use an FQDN for the domain that is globally unique (i.e. ad.company.com, corp.company.com).
I believe the ".local" TLD "recommendation" started about the time of Windows Small Business Server 2003. The ".local" TLD is not reserved by ICANN though it's doubtful, at this point, that it would ever be used "for real" on the Internet (the Zeroconf protocol has dependencies on the ".local" TLD, too, I believe).
I've been in too many environments where "company.com" got used for the AD Domain name, necessitating stupid ugly hacks involving manually copying DNS records from the Internet DNS servers into the DNS servers supporting AD. I've answered a boatload of questions on this site that came down to this poor domain name choice causing hacks to have to be implemented (having to run web servers to do redirects to the "real" "company.com" web site on every AD domain controller, etc).
I don't know why companies persist in doing the "company.com" naming scheme for AD domains. It only creates problems. There isn't any good argument why you should do it, and it "goes against" the basic tenet of DNS that only one set of DNS servers in the world should be authoritative for a given DNS domain name. (I often hear the "UPN suffix" argument. If you want users to have a UPN suffix of "@company.com", for example, you can do that w/o actually naming the domain "company.com". All your users can have "@whitehouse.gov" UPN suffixes if you want, regardles of the domain's name...)
I've always been partial to "ad.company.com", myself.
The "empty root" domain idea is purely a political construct. Originally (W2K timeframe) Microsoft touted "empty root" as a way to have isolation of security concerns between parts of an organization while still having a single AD infrastructure. Fortunately, they've let up on this attitude (though they haven't necessarily gone back and corrected all the documents that were erroneous) since it's been demonstrated that any member of "Domain Admins" in any domain of the AD forest can, fairly easily, make themselves into members of the "Enterprise Admins" group.
So, today "empty root" is only ever really used for political purposes. I would argue that there's no place for it at all because it adds needless complexity (never, ever have a multi-domain environmnet where a single domain environment will do) and offers no real advantages.
If you want security isolation between concerns in your organization you must use a multi-forest deployment (which is absolutely the least fun kind of environment and to be avoided at all costs).
It's perfectly normal for a client at one site to receive DNS resolution for the domain to a DC at a different site. This is because of all the "(same as parent)" A records for the domain forward lookup zone. Every DC is going to be listed round robin for the domain.
It's not the most ideal for DNS resolution efficiency (and can cause issues if some sites aren't available) but you can set up things like geotagged DNS to mitigate it and it's perfectly normal behavior. Once the client gets a DC, any DC, to respond, that DC will utilize the Sites and Zones configuration to fetch a DC in it's proper zone and inform the client to direct further requests against that DC. Once a client logs on, it caches its site and mostly utilizes the %LOGONSERVER% for future transactions.
Best Answer
From the doc you linked to:
You should not be creating your active directory domain name with the same domain name as your public website, because it's far too much of a nightmare to make both of them function at the same time.
If your public website is on
example.com
, make your active directorywhatever.example.com
. Your users can still log on with usernames likeguudluck@example.com
by setting the UPN (User Principal Name) suffix for your users toexample.com
You can still useexample
as your domain netbios name.But do not set your full active directory domain name to
example.com
because you're just in for a world of hurt.