We are working on setting up a AD domain for our company. We created it as a .com and when we had a some IT help from outside come in to assist in some things they said that a .com would cause us problems with DNS. He suggested using a .local domain. We are considering redoing out domain to .local but I'm thinking there are issues with this but I don't have any solid documentation to present a case against it.

57 Replies

General advice now seems to be to use a "proper" domain that you have registered, not necesserily one that you have for a website. If you search on the MS knowledge base, there are some articles in that about it - although I don't have links.

There is really no reason to change it if it is working. The only issue would be accessing an outside web site with the same company.com web site internally. Adding an A record in DNS to point to the external address is all you need to do. Leave it as is unless you are dead set on more work.

In this case you have to manage two zones for resolving hosts. I.e. your web site is hosted at x.x.x.x. You have to create a record in both zones for x.x.x.x to resolve that host (whether its internal or external). If your web-site changes you will be stuck with your internal domain having the old web-site name.

2)

-External Web Domain - [web-domain.com]

-Internal A/D Domain - [domain.local]

In this case you only have to manage 1 domain to resolve hosts, but, if one of those hosts is internal, you have to use loop-back rules on your router to re-direct it inward (assuming you are hosting services inside your network that are accessible from outside). In this case, if your web-site changes, you only have to change the web domain and your internal domain doesn't have any legacy references.

3)

-External Web Domain - [web-domain.com]

-Internal A/D Domain - [domain.local]

-Internal Zone for web domain - [web-domain.com]

This is basically the same as option 2, except that you add another zone to your DNS internally. In this case you have to manage two zones (internal and external) for resolution of your web-domain, but if your web domain changes, its very simple to add a new zone internally and externally and your A/D domain doesn't have any legacy references.

I think option 3 is the best scenario. It is split DNS (which I prefer to manage, rather than use loop-back), and it gives you the freedom to adjust if things externally change and it keeps your internal A/D domain clean.

What the "IT help" are referring to If you use the FQDN rather then .local when setting up AD is for example, you have a website hosted by another party on the internet then you wont be able to access the website from your network using www.yourdomain.com because it will try and resolve the website address locally rather then the IP address of the website hosting site. To get round this you would have to manually enter records in DNS so things like the example would work.

Using .local may cause other issues mainly with other operating systems like Mac OSX

If you have your A record set correctly, your biggest problem will end up being trying to explain to curious and observant users why your domain name functions so much differently when they're at home.

You can pretty much use .anything-you-want. The whole reason behind using a .com or .net or other publicly routable domain is if you want to actually route your internal network to the outside world. If you don't, you can name it anything your DNS server can handle.

I have always tried to use .com for outside/public resources, and .net for my internal network (assuming you own both domain names) just in case I ever needed that functionality in the future.

One of my clients uses a .vi to secure the VMware hosts - they just modify the vCenter's hosts file and use it for DNS - this way no client can directly connect to the ESX host (not my call, I just work here).

I think it is better to use a name that is not used on the internet. That being said you can't be sure what will not be used in the next 5-10 years. Best not to make somethign up or use something small - I wouldn't have thought that .cc would be a valid name on the internet and then, now it is.

If you have it working with a .com suffix then leave it and work with the DNS issue as others have stated. If this is too big of a headache (it will get worse) then you may want to rename your domain now (small headache) and resolve your issue.

.local was an issue for Mac's a while back - I have 3 in my .local and they don't have an issue. I don't have them in AD so that might be why they are ok - I have heard the issue with the .local on Mac systems is when you add them to an AD domain with a .local suffix.

Your outside IT provider was right. But now wrong. They should probably get up to speed on the changes coming down the pipe.

Internal named certs are going bye-bye.

So, this will cause a problem in the future as our best practices associated with MS AD names has changed. I would suggest getting versed on the new policies on certs and Microsoft's new position and then make sure you have implemented your solution with BEST PRACTICES by October of 2016.

We can all skin cats but there is really only one right way to do it - for now.

I did a lot of reading up on this myself several years back when starting up AD at our company. I didn't like the idea of having a non-routable .local and I saw the potential problems of using the website's domain so I decided to do a subdomain and named it ad.domain.com.

You may not have issues now but with the need for more certs for things like Lync and Exchange, it is best to start planning the move to only a publicly routeable name. Once this setup is live, it sure makes internal and external connectivity to these types of services nice. Less headaches from end users and autodiscover gets simplified. If you have done a Lync 2013 deployment, you know what I mean.

If your functional level is newer, doing an AD rename is not that big of a deal. Just plan out your DNS first for a smooth transition.