The unique (and not-so-unique) challenges and observations of an IT pro.

Tuesday, November 27, 2012

Why you shouldn't use .local in your Active Directory domain name.

This post was updated on 14 November 2013

There are an awful lot of .local, .corp, and .lan Active Directory domains out there for many reasons. Sometimes, there is no easy way to change this due to things like Exchange, custom apps that integrate tightly with AD, or just the massive amount of testing that a domain rename requires. I can understand if you walk into a situation like this that you did not create, but please don't ever do this on a new domain.

The correct way to name an Active Directory domain is to create a subdomain that is the delegation of a parent domain that you have registered and have control over. As an example, if I ever started a consulting business and used the Internet-facing website mdmarra.com as my company's site, I should name my Active Directory domain ad.mdmarra.com or internal.mdmarra.com, or something similar. You want to avoid making up a TLD like .local and you also want to avoid the headache of using mdmarra.com for the Internet-facing zone and the internal zone.

I hear a lot of different reasons why people might want to use .local, some a bit crazier than others. A select few are:"Since .local isn't a valid TLD, it's more secure since my AD can't be attacked from the Internet."

I actually heard this on an Active Directory certification training video today and I was shocked. It's just plain silly. You shouldn't be exposing your Domain Controllers to the Internet, period. They should be behind a firewall on the trusted side of your LAN. If you do expose them to the Internet, having a made-up TLD isn't going to help you much. This is a false sense of security that has no root in reality.

"Small Business Server defaults to using a .local TLD during the setup wizard."

Trust me when I say that SBS is not a product that you want to model your organization around. It is meant to be an out-of-the-box solution that can be managed by users with minimal knowledge of Active Directory or Windows Server. Microsoft is betting that people that install SBS either won't already own a valid Internet domain or won't understand what it means to use a third level domain name. SBS also has Active Directory, SQL Server, Exchange, and SharePoint all on the same server. Like I said, not something you want to model your environment after.

"I want my users to see Company\User as the login name. I don't want something ugly like AD\User or Corp\User!"

These two things aren't really related. You can set the NetBIOS name of the domain (the part before the backslash) to whatever you want during domain creation. You can also set the UPN (@whatever.domain.com) to anything that you want as well. This will allow you to have your AD's FQDN be something like internal.company.com, while your users will log in with Company\User or user@company.com. The FQDN of the domain has little to do with the format of a user's login name other than it picks a reasonable default during domain creation. You are free to change this default if you want to make it prettier.

As a best practice use DNS names registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names then the two infrastructures can never interact with one another.

Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name. For example, if your DNS root name were contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com, where the namespace concorp.contoso.com is not already in use on the network

Another reason, albeit a much smaller one, is that mDNS, otherwise known as Bonjour, uses .local to identify nodes on the local subnet without using a DNS lookup. According to Apple, this should only happen when there is a single label in front of .local, like server1.local. If your AD is called company.local – guess what – that's a single name in front of a .local. Not a good situation to be in. There are certainly workarounds for this, but I've worked in mixed environments with both .local and proper AD FQDNs and it's a lot less painful when you aren't using .local.

Really, there are zero good reasons to use .local in a new installation of Active Directory and there are plenty of reasons not to, so make it easier on yourself and your successors and put a little bit of planning into the naming of your forest root domain.

Update: Since this post was written, there has been a major new development with fabricated TLDs. The CA/Browser forum, which is a consortium of web browser vendors and public CAs has released a document titled: Internal Server Names and IP Address Requirements for SSL: Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses provided by the CA/Browser Forum. It can be found here (warning: direct link to PDF).

This document states that no major certificate vendor will issue an SSL certificate for an address with a made up TLD in it, such as .local, .lan, .corp, etc. This echos the best practices that have been published for years, but now has real tangible consequences attached to it.

135 comments:

I made just this error when I helped set up the first AD environment at my then-job. The AD deployment project ran from 2001 to 2003, and one of the decisions was what to name the freaking domains. Pushed for, and got, a "it'll never be used TLD". Being one of the junior members on that team, I saw it as a personal victory. Ahem.

In my defense there wasn't nearly as much literature on domain-picking back then, and the TLD-explosion ICANN is doing wasn't even on the horizon. That particular gTLD has now been applied for by three different entities, so... bad ideas can come around and smack you a decade later.

At my previous job, we had two separate forests and both were .local. I had to do a domain rename on one so that it ended in .edu and then I had to migrate 20k objects from the other forest into the newly consolidated domain. Talk about a nightmare.

Why, specifically, did you "have to" rename the Active Directory? Having your AD forest name match your public-facing domain name is not remotely "required," and it seems like a minimal/non-existent problem that "some other organization" might end up buying "yourdomain.local" and cause DNS issues. You should just purchase whatever domain name you're using, if your chosen TLD suddenly becomes publicly available... We're talking about < $20 per year here, people.

Vs. Weeks of planning and work to rename AD forests. That seems pointlessly wasteful with zero real benefit.

mDNS on versions of AD-joined OS X at the time did not play nice with .local AD domains. The decision was made to "fix" the AD forest to avoid future similar or unforseen issues rather than change the config on every Mac in the organization.

Hi Mark, regarding your statement: "you also want to avoid the headache of using mdmarra.com for the Internet-facing zone and the internal zone." You can do this, as long as you add the zone entries to address internet facing traffic - correct? Are you just saying that using the subdomain like ad.mdmarra.com is just plain simpler and avoids having to add these zones?

Well, first of all, internal clients wouldn't be able to get to the external mdmarra.com website. They'd have to use something like www.mdmarra.com. This is because the Domain Controllers for a domain register A records for themselves in the root of the zone they they're in. This means that internally, there will be one A record for mdmarra.com for each DC that points to the DC. Obviously you won't be hosting your site on the DCs, so you'll need to do something messy like installing IIS on your domain controllers to do redirection or teaching your employees that mdmarra.com doesn't work from the inside.

For other records like mail.mdmarra.com or anything else like that, yes, you just need to add them twice.

Imagine a situation where you have a split DNS infrastructure like what we're talking about. Now imagine that you have a partner that has the same setup. You have a private fiber link between you two. Can you imagine what would need to be done to make sure that only internal traffic traverses that link while traffic meant to hit your partner's external sites goes out over the Internet? It takes a ton of unnecessary work to make that happen.

Basically, there's no compelling reason to use an overlapping namespace. Sure, for some people it's fine, but for others it's not. You don't know how your company is going to grow or who it will partner with in the future. There's no downside to using a subdomain and there are plenty of gotchas when doing it any other way.

I work for a CA SSL provider and are running into trouble helping our clients get past the .local/internal name issue. We are required to limit their certs to a two-year term even though they want longer. I cannot find any relevant articles let alone walk-through's to reconfigure the exchange environment to not use .local's. For example when they go thru the CSR generation process and pick the services to enable, it automatically wants to generate a SAN for domain.local or just the server name.

There's no easy way for them to get off of .local. They'll need to migrate to a whole new AD domain. This is why it's critical to get the name of your AD correct during implementation, since it's months or even years worth of intense preparation to migrate to a new domain.

Unfortunately, Exchange 2007 and 2010 don't support a domain rename like Exchange 2003 did. Once you have exchange in a domain, it can no longer be renamed and requires an entire migration to a whole new domain.

We are running into what you've mentioned. A consultant named our (very small) domain the same as our external facing website. Now when people are on-site and try to go to domain.edu, they get sent to the DC and and not to the website. I had originally planned on going to domain.local, but then I found your site. I'm definitely not an AD expert...so, can we just rename our domain to ad.domain.edu with the domain rename tool? Or is it much more heavily involved? Users don't authenticate or really interact with this domain. It was simply setup in order to utilize DFS for some web servers.

You can rename it from domain.edu to ad.domain.edu with the domain rename tool, just make sure that you read, test, and fully understand the documentation and limitations (like you can't rename a domain with Exchange 2007+ in it.)

we have a domain currently with no TLD whatsoever, so if you name your company xyz, the name of our AD domain is simply xyz.I am thinking about renaming it according to what you have suggested here but I do have a exchange 2003 server running as well. According to Microsoft I can't do rename of the netbios domain name with any version of Exchange. Am I understanding this wrong or does it really mean I can't do a rename at all? Or does it mean that I won't be able to change the netbios name of the domain but I will be able to rename it to xyz.xyzpublic.com?

Ouch, a single-label domain name. I actually don't know the caveats of changing that since it's so rare. You *should* be able to just do a rename and change only the FQDN, but a domain migration using ADMT might be just as easy depending on your size. It really depends.

Make sure you read the documentation for either path carefully and check for caveats regarding single-label domains.

That's interesting. Are organizations able to register them to guarantee that they are unique? If not, they should still be avoided. If I'm example.xa and you're example.xa, we can never have a trust between us or resolve each others internal namespace for collaborative purposes.

Hi Mark and and everyone who is participating in this very excellent discussion--Hat's off to you Mark for this exemplary post. I currently inherited an AD environment (company.com with an externally hosted website company.com--and yes dns was and is a pain) with one sever running under windows 2003 r2, and is running AD/DNS services at a windows 2000 functional level. It is also running exchange server 2003 sp2. I am charged with migrating this whole thing to several new servers that will have 2008 r2. My plan is to have one server running ADDS and one server running exchange 2010. If I rebuild my AD from the ground up on these new servers, can I name my new domain, company.com like the old system was without worrying about users having access to their mailboxes--i.e. will the new system create new SIDs that will prevent me from importing/migrating our mail store into the new exchange? I want to hear what peoples' opinions are on this, or any recommended strategies. Has anyone had an experience like this before?

First of all, why are you starting a new AD? Why not just add new DCs to what you have?

Secondly, you should always have more than one DC. Always.

Finally, if you do actually need to stand up a new infrastructure for some reason, you'll need to create a trust (which you can't do if the domains have the same name) in order to move the mailboxes. Users won't have the same SID in each domain anyway, since the domain SID is derived from the SID of the first DC in the domain, which will be unique.

If you're not ever going to connect to the Internet all of these rules are totally moot, because you're probably on a classified or sensitive network so it totally doesn't matter. Government networks that run this way usually have access to issue "official" certificates via a delegation from a well-known CA.

This is a program available to any enterprise that can afford it through most of the "Big boys" of the CA universe, and well worth the money if you want everything to run encrypted and certified via "well-known CA" certificates.

Hi Mark !After reading your article I am making my mind to create move for domain.comPreviously we had several domain.com web and application services and locally we have domain.local. Now as a pilot project we are working on domain2.local with the same domain.com externally .But I am facing lots of certificate and SSO issues on implementing 2012 RDS deployment. I am thinking to replace this domain2.local with domain.com , Please help on these

1: should I go for domain.com or abc.domain.com 2: If we go for abc.domain.com , what advantages we can get on domain.local 3: If move with abc.domain.com , my domain.com certificates will still work ?

Mark,Thanks for a great article. Our very small company leases a dedicated remote web server from Hostgator. Initially it was intended for hosting .NET web applications via the internet. We also sell or rather "rent" a massive desktop applications written in VB6 (no flame please ... we are talking about a large vertical industry application that has grown and evolved over 12 years... our newer apps are written in .NET).

The "web" server was originally provisioned with Plesk control panel and no AD Domain. Some of our customers asked about a "cloud" version of our VB6 app. So I installed RDS 2008 on the Windows 2008 R2 server and it worked like a dream. Until I wanted to add another "cloud" customer that needed to see a distinct version of our application in RDweb. I found that I could not accomplish that scenario without full blown AD.

The server also serves as a registered name server. I was not sure how I could promote the server to DC, as it is and will always be the only domain member (we have our own local AD domain at our office location with members).

Now I will use a subdomain naming scheme when I elevate the server. You corporate guys will say "buy another server". We employees had to take a 20% pay cut as it is with the bad economy...so don't even mention that.

Hello Mr. Marra,I have a few questions regarding the installation of server 2008R2 Enterprise as it will ultimately relate to an exchange 2013 installation. I am in a 2013 Exchange class which is why part of these questions are relevant. 1. I have a domain which I will be using for the exchange services. I am limited at this time to only 1 server, if you will and will need to run all the required components on the same box; AD DC IIS Exchange, etc. I realize that the namespace; i.e. domain name is critical for correct operation or at least I think that it is. #2. I have played with the idea of giving the computer name, mail so when resolution will eventuaqlly occur it will look like mail.mydomain.com. Interestingly enough when all is said and done it will look more like mail.mail.domain.com. My box is behind a router/firewall and it is certainly not the best level of security but this is just an exercise for my class. There will be no data on this box. I will be using the outlook anywere process (web - owa only) so I do not think security will be an issue. So.....if I have my host point the mx records to my box without opening up the DNS or creating Name Server alias' will it really matter about the netbois and computer name being the same? Sorry for the long post but I am in a crunch with this class and really need any asistance possible. No one else has got this working so I want to get a heads up...Thank you in advance.

Your internal presence (the AD name and the server's hostname) have nothing to do with your external web presence, which could be something like mail.example.com. This is why you use UCC certificates with multiple SANs with Exchange. It allows you to secure both the internal naming and public naming of the server.

Even in this scenario, there's no reason to have your internal AD name overlap with your external name. It's a hard concept to grasp if you're new to DNS.

Hi Mark,Hi Everybody,First, thanks for this great article and discussion.I am handling a project migrating an Exchange 2010 Server1 from the Active Directory domain mycompany.local to another Exchange Server 2010 on the new Active Directory domain mycompany.comI know that to be able to migrate a exchange database to another server, the exchange organization name should be exactly same but what about the Active Directory domain name ?Thanks for sharing your practices.

I just want to point out that you are wrong according to SANS, and they are cooler than you!http://www.sans.org/reading-room/whitepapers/win2k/basic-security-issues-active-directory-191(page 6)"If your organization has a presence on the Internet, the name of your forest root domainshould be registered. An example would be the SANS Institute, which would use sans.com as a DNS namespace for the Internet, and sans.com would be the namespace for their Active Directory forest root domain"

First of all, thanks for such a great article. I was looking for alternate UPN suffixes when I found this article.

I inherited an 8 year old AD with internal name as "company.co" and external domain as "company.org". This month we migrated to Office 365 and got rid of on-premise Exchange 2003. This migration required me to add an alternate UPN suffix so that DirSync could map the users to the cloud AD. So far, so good. Users can log on as "user@company.org" internally as well as on O365.

Now, the problem was that our internal application servers (in fact all servers) are still named as "server.company.co". So, internally the users on LAN have to access "http://server.company.co" to use the app. But, when coming from outside, they need to access "http://server.company.org" to use the same app (I did an 'A' record on "server" subdomain on my external "company.org" domain DNS records to point to the static public IP on that server).

I was wondering how could I get rid of this situation as well? That is how I landed on this article while searching.

May I seek your expert insight/guidance, which could point me in the right direction.

Should I rename the internal domain? (No on-premise Exchange servers). But, then will the user and computer SIDs change? Will the current user-profile on client computers stop working? What are the pitfalls?

If I rename the internal domain to say "internal.company.org", then how would I map internal access to apps to "http://server.company.org" instead of "http://server.internal.company.org"?

You can approach this one of two ways - neither rely on you changing your internal namespace despite it being "incorrect"

1. Configure your network so that internal users can access servers by the external name. If you have something like an ASA and are using the internal and external zone interfaces, you'll have to configure NAT hairpinning.

2. Create a copy of your company.com zone on your internal DNS servers and replace their public IP addresses with their internal ones.

Thanks a lot Mark for taking time out to help me out. Much appreciated.

I did try the second option suggested by you earlier, but perhaps due to my inadequate knowledge, I couldn't make it work.

However, option #1 did it for me! We used to have ASA in HA mode earlier, but was de-commissioned long back. Cost-cutting measures by organization :( Got replaced by much cheaper local UTM devices. Surprisingly, these boxes supported mapping of internal name to external one in the NAT config area.

Works great now. Thank you so much again for pointing me in the right direction.

I have some counter points. Lookup DNS devolution, I have had this bite my users in the past, especially with the wpad bug, that tricky person who registered wpad.com.au had a field day.

I would also suggest you have a look at your firewall when you have some users out and about, and see the occasional 88, 389 and 135 hit from that users public IP, so possible plain text credentials of users going over the public internet or a hash you can use, perfect for a bad guy to MITM.

My counter to your trust issue, would be to think about your domain name and ensure it is likely unique; how likely is it that usa.contoso is going to be used by a competitor contoso just bought out, and how likely is it that the contoso TLD gets registered.

Just to be clear - verifier or not - if you've got logon/auth traversing the public internet, you've configured something wrong. I was just pointing out that your specific point is flawed, but flawed or not, it should not factor into a properly configured infrastructure at all.

I know how NTLM and Kerberos work, however if the NTLM hash is captured over the wire it can then be passed using "pass the hash" to authenticate as that user or the Kerberos packet brute forced to discover the NTLM hash then passed. The NTLM hash can also be thrown at an NTLM rainbow table handy to discover the users plaintext password. You don't even need to be in the middle to do this, just on the same broadcast network say a coffee shop wifi. There are torrents of the NTLM rainbow tables too.

DNS devolution problems are also pretty widespread, the WPAD bug I am talking about has reared its ugly head at least twice in my career (1999 and 2007); http://technet.microsoft.com/en-us/security/advisory/971888But DNS devolution does happen on machines, and a big enough network 10,000+ nodes you will see a few a day, adding to the noise, surely it is better to keep them from being able to devolve to wpad.domain.tld or wpad.tld as has been the case before. Who is to say there isn't another vulnerability of this ilk coming. I know microsoft have given us the ability to turn off devolution, but it hasn't always been there.

My point on auth traversing a public internet is still a valid one, lets say you set your internal domain to ad.contoso.com, and www.contoso.com and contoso.com are your public facing website, someone takes a laptop home and during the usual login process it attempts to resolved ad.contoso.com, obviously if you have proper split DNS it won't, unless for some reason you have created the subdomain ad.contoso.com or it does devolve to just contoso.com, then your auth will route to your public ip for your website. It can happen.

My last paragraph is addressing seemingly your only point of contention for why you shouldn't use a non-registerable domain. You say in case you need to setup a trust. I can see this, I had a client many years ago who's previous admin had set the domain as corp.local, they bought another business that just happened to have the domain corp.local... fortunately the other business only had a hundred or so users, but it still meant nuking their domain, no nice easy trust to migrate things. My point is, if you think about your domain a little more and pick one that is unlikely to be used by anyone else this problem is mitigated. If you pick USA.contoso it is not likely that contoso will be put into the new TLD's that are coming out, and unlikely that you buy a company that has the same AD domain in use in their organisation.

I think that we are going to have to agree to disagree here. All of the things that you mentioned can be mitigated with proper configuration. Not doing something because there was once a bug that impacted it isn't something that I take into consideration. There have been vulnerabilities and bugs in almost every part of every OS at one time or another. To pick and choose which ones you care about when making these decisions doesn't make sense to me. But, of course, I value feedback and you're certainly entitled to your own opinion. I've cited sources published directly from Microsoft that are clear on this issue. Deviate at your own risk.

I have a situation here and i would like our advise. I inherited an infrastructure in which the domain is named abc.local. There are others sites and all are on abc.local domain. We have 3 writable DCs and 3 RODCs. We dont use exchange but Google Apps. We also have another domain in the same company seperated as a Headquarter and on HQ.local. My compnay operates a Hub and Spoke network topology for the abc.local domain. Now based on business needs i am saddled with the task changing the HQ.local domain to abc.local or establish a trust between the 2 separate domains.

The easiest thing to do is just create a trust. That will take about 5 minutes of your time, whereas doing a domain migration will take significantly longer and has a much more visible impact to operations.

Do i need the 3 RODCs too. The last time i tried doing the trust thing i could not get a forest trust in my options.I only had Realm trust and windows domain options.However, two of the Writable domain controllers in abc.local are already talking to HQ.local. Will the trust still be successful if we are able to get the 3rd DC in abc.local to talk to the HQ.local server?

First off, thank you for also stating that it's a bad idea to use a TLD for your internal domain as well as your internet facing TLD. Also, this is something i've seen and even from my Microsoft Certification i recall adding a .local is preferred as opposed to a .com, .org, .net, anything that could be registered publicly. However, i'm curious because a .local does seem to add that additional security by not allowing the internal domain to be published publicly AND authentication to any resource outside (by VPN or application) would require that .local or .whatever (if you're using SPN)... but most would probably force the user to use the NetBios XXX/username for authentication.

Now, like you said all this can be avoided and secured with proper implementation, i get that.. it also seems to me the argument here pertains to only scenarios when multiple domains (internal) have the same name because you can't trust contosso.local with contosso.local... and i can see that being a nightmare with administrating a migration. I'm curious on your thoughts of security that it might add or take away...

For instance, if i register contosso.org, and i name my internal domain ad.contosso.org, even though the TLD is unique, contosso.org is registered publicly. Does that pose any threat because i have that part in my internal domain name as well?

Also what about a scenario where public domains don't match with internal domain names? And i'm not talking about contosso.com to contosso.local... what if i have my internal domain called by a totally different domain name? For example, my internal domain is JDOE.COM, but my external site is registered as JOHNDOE.COM. Is this still the same issue here as the .local even if JDOE.COM could be registered publicly?

> However, i'm curious because a .local does seem to add that additional security by not allowing the internal domain to be published publicly

It doesn't add any security. You have to actively try and expose your AD's DNS zones to the internet.

> AND authentication to any resource outside (by VPN or application) would require that .local or .whatever (if you're using SPN)... but most would probably force the user to use the NetBios XXX/username for authentication.

Not sure what you mean by SPN here, SPNs are related to Kerberos auth and have little to do with AD domain naming. Also, relying on NetBIOS for name resolution is bad news.

> it also seems to me the argument here pertains to only scenarios when multiple domains (internal) have the same name because you can't trust contosso.local with contosso.local.

Not just internal, it's quite common for companies that are partners to have private connectivity with a trust between them. This applies to that situation as well.

> and i can see that being a nightmare with administrating a migration. I'm curious on your thoughts of security that it might add or take away...

Again, using .local or any other made up TLD has nothing to do with security. At all. Ever.

> For instance, if i register contosso.org, and i name my internal domain ad.contosso.org, even though the TLD is unique, contosso.org is registered publicly. Does that pose any threat because i have that part in my internal domain name as well?

No. Only if you go out of your way to misconfigure your DNS.

> Also what about a scenario where public domains don't match with internal domain names? And i'm not talking about contosso.com to contosso.local... what if i have my internal domain called by a totally different domain name? For example, my internal domain is JDOE.COM, but my external site is registered as JOHNDOE.COM. Is this still the same issue here as the .local even if JDOE.COM could be registered publicly?

If you do this, you should register jdoe.com. It's common for a company to be example.com publicly and example.net for their internal AD network. This is fine as well, same idea roughly. Just make sure you register the domain name you use internally.

Err... i didn't mean SPNs, i meant UPNs: User Principal Names. Instead of authenticating by domain\username you're authenticating with username@domain.com (or username@domain.local according to my question). But you pretty much answered my question regarding security to a resource thats accessible from the outside that authenticates through AD. I see that it wouldn't matter if it's a .com or a .local. Even though most applications will automatically apply the UPN for authentication or NETBios name to the user account when authenticating. Thanks.

so let’s say we call our domain ad.company.com. our internal servers would then be server1.ad.company.com, server2.ad.company.com etc? and we would create similar entries on our external DNS, so users can always enter the same URL to get to the same site regardless of whether they were internal or external… but what about wildcard SSLs? They only work for one level of subdomain… so right now we are able to use a wildcard SSL to cover server1.company.com and server2.company.com etc. Wouldn’t naming our domain ad.company.com prevent us from being able to use wildcard certs for our internal URLs? (unless we keep internal DNS records for company.com but then we are back to split domain, which was what we were trying to avoid in the first place?)

You don't want to create an "ad" zone on your public DNS. You can configure your network to not have hairpinning issues so that internal clients can access public-facing resources on their public IP. Then you don't need split DNS. If you can't do this, split-DNS is the lesser of two evils here.

Hi Mark,very, very interesting articles.May I ask you a question about my situation at a customer?I'll try to explain:The official external domain is company.at, mail-gw in DMZ is mail.company.at. The internal domain is also company.at, the Netbios-name is company (same as real name of the company).I have two locations, on each a domain-controller (W2K8 R2), FQDN of the Servers are location1.company.at and location2.company.at. Both sides are connected through VPN (site-to-site). All users authenticate the same way on both sites.The internal Exchange-Server is a W2K3-server with Exchange 2003.All users in AD identify through netbios-name "company\user1" (on both sites)Now I have the situation, that the company changed the name to newcompanyname.What users there ask me:Is it possible to change the names (AD, Netbios) from company.at (AD) and company (Netbios) to newcompanyname.at (AD) and newcompany (Netbios)?The external newcompanyname.at is already set up and works with additional address-space in Exchange (additional default-mailaddresses user1@newcompanyname.at).Actually I didn't set up anything in AD or DNS with "newcompanyname.at or newcompanyname".At location1 (Headquarter, Financing, Sales) I have app. 30 client-pc's (and 6 Servers, one of them the W2K3-Exchange 2003, another SQL2005 on W2K8 R2), at location2 (production, stock, ...) I have app. 50 client-pc's (and 7 servers, one of them W2K3-Terminalserver, another also SQL2005 on W2K8 R2). I don't want to think about lot of work on setting up newcompanyname.at parallel to existing and moving users/pc's/servers to the new AD-/Netbios-Domainname. Is there a way to Change ?Thanks in advance for your appreciated advice.

Biggest problem I see when naming your internal domain the same as your public domain, is that your public domain name can change much easier and more often. This can leave you in a pinch down the road when your internal domain name is not relevant (or worse, hated).

For example: I register a public domain fruitcakes.com. I decide to name my new AD ad.fruitcakes.com. Sometime later my company restructures and we don't sell fruitcakes any more. Now we sell hammers, and we hate fruitcakes. So we register hammers.com. But my internal domain space is fruitcakes.com .. and will be forever unless I migrate to a new AD. No easy fix there.

However, if my internal domain name was corp.local, my CEO wouldn't harass me every day in the hallway about having that old name pop up from time to time. He really hates fruitcakes now.

Another unpleasantry would be if the public domain name was very long. Like: fortheloveofgiganticfruitcakeswithnuts.com.fc.local sure is easier to those managing AD.

Or what if my company name doesn't have anything do with my public domain name. If I register the domain freefruitcakes.com as the face of my company, but my company name is Microsoft, that doesn't make much sense.

Or what if I'm a cloud services provider in multi-tenant situation. I have multiple companies managed under the same domain or multiple domains. Using a public name would not be possible.

Or what if I own multiple public domain names. Which should I choose? Whatever I choose, I would have to keep renewing forever even if I hate the name now to make sure some other company doesn't snatch it up and name their AD the same as mine.

As for the internal server SSL problem, you can usually use an internal CA.

Finally, the odds are probably very low that your company merges with another company that uses the same internal AD name. Especially if both companies use their public domain name but just replace .com, .net, or whatever with .local. In fact, it would literally have to be two companies that own the same public name, but one owns .com and the other owns .net. Very rare.

Oh. And nothing prevents me from naming my AD the same as yours, despite your best efforts to be unique.

Mark, care to respond to this post? This is a very valid reason. We are now in a situation where our domain name does not represent our business. We are being harassed about it.Therefor with our new domain name we want to choose something universal. So if the organization name would change in the future we have no issues there.

We host all our services within our own domain (have our own CA as well), so what exactly would be my benefit of choosing a public domain name?

Besides not going to get a SSL certificate and maybe some bonjour issues I'm not reading that many strong arguments.

I think this falls under another best practice that states you don't name your domain after a product line. Your domain name should be well thought out and something that will age well. If you name your domain fruitcake.com, then well... you pretty much deserve to be harassed daily by the CEO. Better yet, you deserved to be fired. Your domain name doesn't need to be the same as your public web names. The only thing recommendation I see being made is that you also register your domain name so that it's guaranteed to be unique.

First Many thanks for clarifying lot of concepts with DNS. One question if I may ask. which you probably answered but will like to clarify as currently doing it in prod environment...Existing - Scenario : SMB Location with Windows 2003 Server AD/DC - DNS is messed up.Current DNS setting on the windows 2003 server is DNS Server IP address of ISP. User workstation have ISP DNS too .. Planned work going on : Building Windows 2012 r2 . AD / DNS.. Point user to IP address of the Win 2012 r2 server. Have root hints enabled by adding ISP IP addresses.

Question : when building AD DNS win2012 r2 you get prompted to create NEW FOREST then fill in Root domain name : can this root domain be named as i.e AD.company.com,Internal.company.com - where company.com is real registered domain name with website running as company.com and then do the AD NETBIOS name as i.e " ABCD " so when user logon it will be ABCD\username .. Am I on the right track here..

Your help to answer this and if I am doing this right is greatly appreciated. Regards ..

So if I have an internet domain called (for example) happyservice.com and an internal domain called happy.local, am I better off renaming my intranet domain to internal.happyservice.com or is it just as well to use happy.com? I like the subdomain idea, seems it would be better when you set up your UCC certificate, but internal.happyservice.com is a lot more to type into a username (internal.happyservice\username) than happy\username. Does it make any difference? Thx!

I'm going to install a new AD. abc.de is registered and has a website hosted. I'd go for ad.abc.de now. Will there be any trouble if the domain provider resolves all subdomains (even them which do not exist) to the IP of the webserver? There is no Exchange, nor any services which need to be accessed from outside.

You wouldn't happen to have a guide (or know of a guide) to setup a new domain using server 2012r2 with a subdomain of a registered TLD do you? All that I've been able to find are guides explaining either adding server 2012r2 to existing domains, or setting up a new domain using domain.local (etc).

I just recently inherited an environment with this exact .local ad domain issue. I am working on changing it but as you know it is quite a project.

In the mean time I am attempting to set up an additional mail server on a different domain on the same lan. The problem I am encountering is that when a message is sent from my new mail server to user@company.net it is unable to see it because the domain is company.local. This is causing the message to come in over our public address. How can I set up the local DNS server on company.local to recognize company.net look-ups and forward them to its mail server keeping everything internal...

I apologize if what I am saying is unclear. It is a little difficult for me to explain. I appreciate any insight you can provide.

There's one problem. Microsoft also says you shouldn't have a domain name of more than 15 characters, for whatever reason. That's an stupid constraint, since there are LOTS of domain names with more than 15 characters including the ".com" (that's just 11 characters worth of domain name, ridiculous!) so if I should use a real domain name and mine is longer than 11 characters (plus the dot com), what do I do then? Don't tell me I have to register a short domain name just for this!

I just found an updated Technet Article that is more current than the 2000 article you referenced above.See http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspxIt says that you need to have a registered domain name in order to interact with Azure.It also EXPLICITLY says not to use .local, .example, .test, among others since these are all actually "IANA Special-Use Domain name" reserved names.

I'm working with a customer to implement a complete new domain. The website is hosted externally and the domain is abc.com.ar. My idea is to name the domain as ad.abc.com.ar . Could you please confirm me if that is a good choice ?

Mark,I just found this blog, while fighting with a .local network, regarding a future problem with obtaining a UCC certificate. I have one domain controller Server 2008R2 Std (AD, FSMO roles, DHCP, ...) that is called abc.domain.local. The client has a domain name registered as domain.com. I just installed Exchange 2013sp1 on a member server (2012R2 Std) called xyz.domain.local. The network has about 40 computers/users. What should I do? I was thinking:1. uninstall Exchange 2013SP1, since it is not in production yet2. rename domain to ad.domain.com3. install Exchange again

Hi Mark, First of all I am glad to see the discussion still active. I am a consultant charged with restructuring AD DS for a conglomerate which has acquired several companies, and to bring them in to a single forest each with their own disjointed name space, and a single Exchange 2013 Org. to serve all domains in the forest. My plan is to have a root domain "ad.xyz" per your advice, for administration of the forest; and all subsequent domains having disjointed namespaces. However, the 2012r2 DC's in the root domain will be authoritative DNS servers for all domains configured with FLZ's. I have it set up that way in an OOB lab and it all works great. The main reason they want this setup is to save on the cost of Exchange Server Licensing. My question is: Is there any reason I couldn't use a .net for all the domains in the forest with a .com as my TLD?

I am reading this because our AD domain name is not registered by our company. The AD domain name is based on the name of our company, but is not the same. It's been setup that way since about 2000.

The domain name has been for sale for years, and they want > $15k to buy it (strange to me, because it doesn't seem like a name anyone would want.) So buying the name is out of the question.

This has never created any problems, but I am seriously considering doing an AD rename to something that we can register.

I am not looking forward to this process. We have two sites, 3 DCs, about 150 workstations, and about 40 Macs bound to AD as well (what in the world happens to them during a domain rename?)

Is it worth renaming the domain to something that we can register (or to a sub-domain of our web domain)? What are the reasons to do so? What are the risks of continuing to use an internal AD domain name registered elsewhere on the Internet?

Dear Mark, I have a domain name say xyz.com but netbios suggested during domain creation was xyz0. I used that. and now my users have xyz0\firstname as usernames. I would like to have an external internet facing domain, how can I register my domain?

Tortoise, when it comes to exchange and the email addresses, you shouldn't have to worry about doing anything with the UPN suffixes. Addresses in Exchange are determined by the email address policy. For instance our organization's domain and forest are denoted by (ex: contosso.org), while our email addresses to the outside world are ex: (supermelon.com). Now Exchange can take the UPN, but through the address policy you can tell it which domain names you want.. as long as you own that name and it is registered. which by your post it is. User UPN names will be still user@ad.mydomain.com while Exchange can give them an email address of user@mydomain.com.

Mark,Great article. I'm new to AD and building DC's, and wish I'd have seen this a week ago! I just finished building Win Server 2012 R3 Ess for a friend with a small business. The install defaulted to .local so I went with it not knowing. So far I only have one of his 4 workstations joined to the domain, and a company specific file share on the server they are using in a production mode. Since this is new and small... realistically how much work would it be to rename the domain (No Exchange) for an AD greenhorn?

We just ran into yet another reason to never use fake TLDs. We just enabled DNSSEC validation on our recursive servers. Even with forwarder records, our ".local" domains simply stopped resolving. After some head scratching, we realized it had to be the DNSSEC validation process causing it. That is because the recursive server will insist on going to the root to validate the DNSSEC chain from the root to .local, and then to xyz.local even though we had an explicit forwarder statement for the domain. As there is no such TLD, the first level validation fails... and subsequently all resolution for any .local domain fails (or anything that doesn't adhere to an officially designated TLD).

I bodged this by creating the local hierarchy on my recursive servers so that any xyz.local domains get properly delegated (and now do not need to reference the root servers), but that is just a stop-gap measure. It's not a truly valid solution to the issue.

I have a sbs2008 server on the blink and it has the .local on it. So I have 2 new servers with Windows 2012 r2 essentials and win 2012 r2 standard exchange 2013 planned to replace the sbs 2008 but need to migrate exchange and folders and mailboxes to new servers.So .local needs to change to server.abc.net and mail.abc.net but I don't know how to migrate the sbs if I change the domain? What do you suggest? Thanks

I have a sbs2008 server on the blink and purchased 2 servers installing win 2102 r2 essentials and win 2012 r2 standard with exchange 2013. I just found out about the .local as you have been discussing in this blog. How would you approach setting the the new servers up as I don't know how to migrate sbs 2008 with the .local domain to the new servers to server1.abc.net.How would you do this? Nothing on the microsoft tech net could i find to support this change.Thanks

I have a AD DC server with a DNS and DHCP server set up, and i would like to connect it to 2 client pcs. The error i get is "an active directory domain controller for the domain 'domainhere' could not be contacted.

This article has nailed exactly where we shouldn’t be. We just outsourced our migration (no-one in our company is very cluey when it comes to the MS world) from an old SBS machine to Exchange 2013 and Windows Server 2012 R2 for the DC’s. Unfortunately the outsourced company have migrated us to a .local domain (which I now see as being a clear mistake, particularly in light of the changes by registered CA's).

This is already causing us grief since we use a web service for email filtering. This service needs to to talk with our AD in order to authenticate users. Unfortunately, the filtering service will not accept self-signed SSL certificates (and CA’s apparently no longer sell certs for domains that are not publicly resolvable). This leaves the clear text option for LDAP, or nothing.

As I understand it, we can't do a domain rename due to the Exchange server, hence, we should build an entirely new AD domain (as a sub-domain of our existing public domain) and then migrate all the machines and mailboxes in a cross-forest migration.

Can we build the new domain on the DC's in parallel with the currently operational production domain (company.local) and then migrate everything over to the new sub domain (internal.company.com.au)?

Can you see any alternative to this domain migration, given that we need to have the machines talking securely to at least one web service that only accepts certs issued by registered CA’s?

Could we proxy LDAP and similar requests through a machine we setup on our public domain (but living behind the firewall) and set the public domain as being trusted by the machines in the .local domain?Is that a really bad idea from a security point of view? (all the machines involved are secured behind a firewall but even so, it seems risky to me to tell the DC's to trust the public domain....)

Could you please clarify the following sentence "The correct way to name an Active Directory domain is to create a subdomain that is the delegation of a parent domain that you have registered and have control over." From what I understood we should never create a delegation from the external to internal DNS Server to keep the local DNS data private. I'm not an native speaker, just looking for confirmation.

Hi Mark,Excellent article and insight to the situation I just inherited. I'm a one man show and our small network is comprised of VM 5.5 running 3 servers (2 are Serv. 2012 R2 & 1 is Serv. 2012) and one physical server running Serv. 2003 SBS. The company is growing and before we get to that "too big" thresh hold I would like to change the domain setup and remove the .Local. We are now using O365 so we have no Exchange and one of the 2012 R2 Vm's is slated to become the new DC. What can I expect if I change the domain and remove the .Local? What are the steps that would need to take for this as well?

When someone tells you in a sarcastic tone, "there are no stupid questions.", they should be pointed to this web site. Mark you hit several nails on the head and punished more than one troll. You deserve an award for having more patience than the entire industry of IT put together. It's no wonder to me that pay has dropped when this is the calibre of support companies must put up with. Kudos to you Mark for cutting through the bologna.

Hello Mark,Single Windows Server 2012 Domain Controller with 10 Windows 7/10 functioning workstations that have joined the domain and functioning.One of the workstations suddenly started to given an error message when logging in --- "The trust relationship between this domain and the workstation has failed.....". Since we don't have the local administrator password we may be dead in the water and this may require reinstalling the O/S on this workstation. This I can handle...BUT...So, I decided to take a new workstation and tried joining it to the Domain but a couple of screens into the wizard, I get the following error message -- "The specified domain does not exist or could not be contacted". I did ipconfig /all and saw the workstation received an IP address from DHCP and that the workstation does point to the DNS server on the DC.Is there something specific I can check to look for the problem...

I just recently started working for a company that uses their external domain name for their internal AD domain as well. My first job is to do a major revamp of their network to help them become HIPAA compliant, and this domain name is one of the big compliance issues they're encountering, as it is a security risk.

We're getting all new servers, and will be migrating to a new domain name to move away from this. However, I'm curious if it's possible for me to use best practice here given the situation. We have Exchange 2010, and will be moving to Exchange 2016, so we're doing a cross-forest migration of that anyway.

My issue is whether or not I can create a sub-domain (for example, we are company.org and I want to use internal.company.org) and set up the necessary forest trust for this transfer, or if a forest trust will fail because the new domain would technically be seen as part of the existing domain.

I'd like to resolve that question before setting up the new domain, so that I can avoid this issue if possible. Any suggestions?

I have an existing domain I've inherited using its public domain name for the internal domain as well. (For this example, say company.org)

We will be migrating to a new domain name to ensure HIPAA compliance, as this practice can cause security issues. However, because we need to migrate e-mail across the domain, I need to ensure I can set up a forest trust.

Will making the new domain internal.company.org cause forest trusts to fail, or will they work as intended even though that's technically a sub-domain of the current domain name? (I've not run into this particular situation before, thankfully.)

Linux also reserves .local for mDNS. The way some distributions are configured by the operating system does not even try to call the DNS resolver for .local domains. I'm ripping my hairs off trying to disable and/or uninstall the mDNS resolver from 900+ POS machines. Please don't.

I've been doing this all my life. Thanks for making me feel stupid. I mean, JEEZERS!!! I just realized that I've also made dozens of other people who listen to my advice stupid as well. I should have realized it sooner. Think about anybody who works in a Microsoft environment. Sure, you see "contoso" all over help documents and whatnot, but have you ever, I mean EVER seen a Microsoft document or internal memo or anything at all with "microsoft.local" on it? That should have tipped me off, but I'm stupid. So stupid.

Hi Mark, i think you're missing a few things. I don't see any reasons why I can't simply use .local .corp as a internal root ad top level domain name. What If I have a single forest single domain architecture and dividing AD based on location via OUs. It does make sense to have something like comapny.corp for the root ad domain and internal dns records like cz.company.corp, at.company.corp, com.company.corp instead of com.company.com. ??? And internal users are usually visiting company websites through internal dns records, that's what split dns is about. I think this post is completely useless, if somebody use .local tld it's for a reason !!!

It seems you've missed almost the entire point of everything I've said.

1. I'm talking about single domain forests, which is the preferred architecture in almost all cases. Empty forest roots were. A bad idea of the past.

2. If you don't use split DNS, you don't need to maintain internal DNS records for internal sites. If your public DNS is company.com, but your AD is ad.company.com, you don't need to keep records for company.com internally and externally. It's fewer DNS records to curate, which is a win for everyone.

3. If someone uses .local, it's because they think there is a reason, but they don't actually know what it is. I have yet to hear a single good reason to do it other than "I always have" which is never a good reason to do anything.

If you disagree, I'd love to here specific technical points. As it is, your current post adds very little to the conversation.

Hi Mark, I have named my AD ad.company.com and now I try to configure Exchange 2016 and my host is named mta.ad.company.com Now I will have two addresses that will point to autodiscover servicess mail.company.com for external and mta.ad.company.com for internal users. I would like to users only have to know a single namespace (e.g., mail.company.com) to access their data, regardless of where they are connecting. Naming my domain this way will enable me to avoid split brain DNS, but the exchange team states : "Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces." http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspx. My issue is how to keep configuration simple for my users.

If you want, you can split-brain by creating a company.com zone in your AD DNS. You don't have to name your AD "company.com" to do this. Or you can just have the users use the public "company.com" zone to connect to the mail infrastructure.

we are going to install new domain .we have site internally and public site and email that hosted locally .we also need to have SSO ,and our email is linux base server .do you suggest use best practice ?if yes please suggest the plan .

Hello Mark,First thanks for the article and you should be commended on your points and its clarity. I have to admit I implemented several SBS environments and have used the .local as suggested by the wizards. Each of them are SBS 2003, 2008, or 2011 with using Exchange and SharePoint's companyweb which made the SBS model very cost effective (even it is not recommended) but Microsoft provide the suggestion of the .local so I thought it made sense (at the time) and also Microsoft throttled down the SBS implementation so it could all reside on the same box/server.

So, now SBS is no longer available or at least not worth purchasing due to its duration for support.

Only recently has it caused a complication when getting certificates. Which caused me to do some reach and I found your article and I think that I have painted myself and the server in to a corner. In the past, I booted the new server with a migration answer file but that was SBS old to SBS new and then complete the rest of the migration process.

This is nothing that I have to do soon as I merely making plans due to your .local article and I ask the following per your experience in the .local to .edu rename and migrate in comments. Also, the existing environments are less than 20 computers so I was not completely worried about the disjoining computers and joining to the new domain. But, wished to avoid the renaming of the domain due to Exchange 2007 and 2010 limitations and exporting mailbox items to .pst and importing to the newly created mailbox.

When upgrading these clients from SBS 20xx to Server 2012 or 2016 and using HyperV for a virtual machine for the AD and another virtual machine for Exchange, do you think I will able to use an answer file technique per (https://technet.microsoft.com/en-us/library/gg563801.aspx) or ADMT to go from domainname.local to corp.domainname.com and migrate users and mailboxes as described in the following article http://blogs.technet.com/b/sbs/archive/2009/05/01/sbs-2003-to-sbs-2008-migration-to-a-different-domain-name.aspx? Or do you have another suggestion?

Your recommendation and opinion valued and THANK YOU in advance!! Anonymously as to not call attention to my poor decision of using .local.

I named my AD to x.y.com.sb and my exchange server pointing to y.com.sb - how can I set my AD to show my fQDN when creating new email users? currently when I want to create new users it will give users - john.smith@x.y.com.sb but I want users to be like - john.smith@y.com.sb

I totally get your point, Mark, but creating a dependency between a public web domain and your AD domain is not a great idea when considering mergers or company name changes. Like the example of the fruitcakes in one of the comments. On the other hand, when using a more generic name like insurance.local or finance.local, does not need to be renamed when company changes it's name, but could get messy when the company merges with another financial corporation, which thought insurance.local was a good idea.

Great discussion though!

I think registering a more generic public domain name which relates to your company's activities can be a good way to go.

Great examples, but by the same token, companies change lines of business as well. I have a customer who is in the health device field, but started as a jet rental company (not joking) so they log in with something like JETSETTER\user and they're not in the medical space.

Just goes to show that you can't predict the future, you can only plan for best practices of today :)

I have worked for the last 12 years in an environment where we had a split DNS infrastructure. We setup IIS to redirect to our web site. This has been my only experience with AD and it wasn't ever an issue. I am now at a new job and was hired to migrate from Novell to AD (currently there is no AD) and then integrate all our Macs (80/20 split of Macs to Windows). I have been convinced by blogs such as yours that using a sub domain is the better way to go. Also, our domain name is longer than 15 characters so keeping the name "pretty" will not be possible. The last piece of unknown to me is the Mac integration. We have narrowed down out Mac integration solutions to Dell Authentication Services or Casper. Does a sub domain add any complexities to the already difficult Mac integration process?

It is good to see this post is still continuing to generate questions and debate. My knowledge is limited to self research from posts like this, and I do have some questions; some basic so don't shoot the dumb ass.

I have two public websites at companyx.com and companyy.com. Those are managed on Goddady servers.

I have emails with O365 E3, as you can add more than one domain into one service. Recently I set up an internal server with a DC called companyz.com but panicked it would mess a future public facing site I was planning to launch and so I renamed the DC companyz.local to keep it separate.

Now this post is saying .local is bad practice and I was just about to create two more DCs as I want to create internal logins for companyx.com and companyy.com on the same box as my .local, but if I call the new DCs companyx.com and companyy.com I'm thinking that would affect the pubic websites... If I call them DC.companyx.com or AD.companyx.com how would that effect the user login name. I want them to log in to services with name@companyx.com and name@ompanyy.com so now i'm a little lost.

So my emails are managed on O365, my pubic sites on managed on hosted servers, my internal servers are for SQL and CRM and I want uses in companyx.com, companyy.com and companyz.com to all have access CRM as different business units.

Ps - I don't normally ask question on the net and normal find the answers, but the feedback on this post looks helpful to ask.

I've noticed that you have not received a response to your questions. I've been working with AD and DNS for many years now, ever since the old school of NT domains (predecessor to AD DS). I have no formal training in either. All my knowledge comes from years of experience which is accompanied with lots of trial and error. Which is a very dangerous kind of knowledge.

With that said I will attempt to shine light on your doubts if for nothing else to test my knowledge.

I see that you were confused when you questioned about what you will call your DC's. First of all you have to realize that, as Mark mentioned, you will be creating a second-level domains called internal.companyx.com, internal.companyy.com and internal.companyz.com. You will then name the DC's DC.internal.companyx.com, etc., etc. Now, internal.companyx.com is a subdomain of companyx.com and although there exists some trust relationship benefits, when it comes to your publicly visible domain companyx.com, there essentially separate.

You can also add the UPN Suffix to your domains so that users can log in using user@companyx.com instead of user@internal.companyx.com.

> You shouldn't be exposing your Domain Controllers to the Internet, period.

True, but... there is at least one vector of attack you may not be aware of. Windows DNS clients are a bit non-deterministic and it is very common for them to leak DNS requests out to the internet. An administrator might have set up a public DNS server in the list "for redundancy", in which case it will be used at random a small percentage of the time, or you may have a good old hijack. If your AD domain is registered externally by a bad actor and gets a DNS lookup sent to it, boom, that machine can be made to send AD requests to an arbitrary server. The attacker can then presumably get password hashes, or set up a netlogon share and get arbitrary code executed.

DNS outbound should be blocked, yes, but it isn't sufficient just to firewall your AD infrastructure.

" You shouldn't be exposing your Domain Controllers to the Internet, period."

Wow really... better tell Azure.

I'd say it's bad practice to tie an internal system to any external domain... Most companies have more than one domain name, so and the rate companies change branding... then the domain changes, then you rename you're whole forest... K.I.S.S.

There is nothing, nor will there be anything wrong with using .local on a AD setup in itself.

It's been a while since I installed SBS but if I remember correctly one of the first thing Installation asks is for your public company.com domain in order to correctly configure Exchange. Why did Microsoft than decided to use .local as opposed to internal.company.com for the local AD structure if such a use is "Best Practice"?

For example 1. I am going to register a public domain name called demoworkers123.com 2. Then I am going to create a new AD Infrastructue and call my forest root internal.demoworkers123.com 3. But the only problem with this is that all my users emails email address will be bob@internal.demoworkers123.com and I would like them to be bob@demoworkers.com

Hey Mark, I've just read your post and I loved it.However all docs that I find on this subjects are really old.Is it still a good practice to use ad.domain.com? Some guy on an Office 365 course said to me that he always use domain.local and there are no reasons to use subdomains...