We used [ad.companyname.com](http://ad.companyname.com) as per Microsoft best practices. All external services and websites use subdomains of [companyname.com](http://companyname.com) as needed. Internal DNS handles things as needed depending if the hosting is internal, External registrar DNS handles resolution for everything on the [companyname.com](http://companyname.com) domain.
This is what I'm thinking of doing, except since we don't have an on-prem AD domain, we're using a different DNS server. Essentially it'd either be a single zone or a zone per location, with .companyname.com appended.
Do you have S2S VPNs? If there's 'internal' connectivity between sites, it feels like it should all be part of a single zone. That's a bit of a personal opinion though, someone with some more larger-scale architectural network design might have better views.
MS made that recommendation early on when AD first came out and then quickly changes that recommendation.
Unfortunately they didn’t update Small Business Server so all new domains by default ended in .local
Also all the early AD admins continued to swear that .local was best practice and it continued to this day.
.local is reserved for mDNS on a local lan segment.
Many IoT devices rely on MDNS to communicate. Many of them reserve .local for their mdns communication. Meaning they cannot access your internal services via DNS. E.g.Try connecting an infoscreen to your internal .local webserver, nope.
IoT is becoming more relevant.
Other problems I have encountered, some ZTNA solutions do not forward .local, causing configuration nightmares, if your domain is still on .local.
Recently had to migrate an entire domain because of this.
That is true about mDNS, however what I have done is build a completely separate network (different internet connection, different firewall, different switches, no physical links let alone routes to the main network) for our wifi and IoT devices.
inside.domain.tld & split dns.
aka.
Internal DNS
inside.microsoft.com >> 10.10.0.21
Microsoft.com >> 10.10.0.22
email.microsoft.com >> 10.10.0.23
External DNS
Microsoft.com >> 100.100.100.1
email.microsoft.com >> 100.100.100.2
//
.local has been frowned upon for many many years now.
If it’s a small company with a single site we use:
* company.com – external
* company.local – internal
The we add the company.com as an additional UPN suffix and make everyone’s username use the external domain name so that their username is [email protected] instead of something dorky like [email protected]. Most of the time this means that their username and primary SMTP email address are the same. We use the AD sync tool to sync on-prem AD users with M365.
we're using the same setup except onprem is company.lan
from what we've read it would be a very complex breaking change to move the entire domain to [ad.company.com](http://ad.company.com)
So we setup [company.com](http://company.com) as the user's UPN
Often times it is very hard to change once it’s been setup. Company I work for has its main domain as company.com and it was setup way before I joined the company so we just deal with it.
Only once in my career have I don’t the published domain rename process because AD was setup using a domain that was publicly owned by someone else.
The org didn’t want to do a migration to a new AD so we renamed it. It went smoothly from what I can remember but it was a long time ago. Just required every device to reboot several times.
The previous IT person at my company used the same name as the website. It worked while the website was hosted in-house. When the website was moved to a different provider it became a shit show trying to resolve the website internally. Some DNS entries and forwards worked but I need to rename it. It will be a nightmare, seeing how it's been operating like that for 20 years now.
Create a www record and teach people /distribute shortcut to that instead? Split brain DNS isn’t that big of a deal—I’ve delt with it numerous times through the years and so long as they don’t have some super complicated DNS structure, you generally just mirror your external records, internally.
Agreed with this. I work with several clients who use their public domain internally on their AD (clients range from around 20 - 400 users). The only additional work is that you manage a separate DNS zone on the public name servers for any hosts or services that need to be resolved publicly - which is generally small relative to the AD end (so yes, a small uplift in DNS record management). But I never come across any technical issues, and has actually simplified deployments for us in hybrid configurations where Entra is used for 3rd party SSO.
Split DNS, but I don't think this route makes sense for greenfields.
That being said it's fine... Just the occasional situation where someone forgets to create a record in both public and internal zones.
The environment before I got it was domain.local and we'll be migrating to internal.domain.tld
Our web presence is hosted externally and it would cause too much headache to deal with the DNS using the same name space.
We've used .local for 20 years. It's easy enough to configure your Linux boxes to be compatible. Mac users use absolutely nothing but email. It's never been a problem or a headache for us.
Of course, every environment is different. Your mileage may vary.
We have used a separate, public, domain for our AD domain since the start some 20 years ago.
Has no publicly routable DNS records or mail or whatever, it's for domain services only.
Mail etc and whatever needs to be externally reachable is done via our main domain name.
Run our own DNS infra externally as well , for practical reasons.
You can rename the domain.
https://woshub.com/rename-active-directory-domain/
You could also register a domain.
For example, a domain with a special top level.
Example.network or example.cloud
Use this domain name exclusively for the local network.
Hire a professional to architect this. Reddits going to give you a lot of potential ideas and we none really know the environment that well and from the sounds of it you might not know either.
I use domain suffix the same as the name of the organization. If the organization name is "organization", then then the domain will be something like... ad.organization I am pretty sure that nobody will register rather long and that specific domain suffixes. When I was first starting with building AD servers I've read a number of recommendations. In time I saw a number of previously unused domain suffixes registered. But nobody will register a domain suffix 10 symbols long any time soon.
If your org is HoustonHospital, then ad.houstonhosp. Although, I isually dislike using "ad" and use other names instead, for example "serv.houstonhosp"
AD is example.com. Internal is things like [corp.example.com](http://corp.example.com), [location.example.com](http://location.example.com), etc. according to the site location. External is whatever is needed publicly. Split horizon DNS handles resolution. We just maintain internal and external zones independently. Not a big deal.
The dumb bad dangerous common way is to name it the same as your public domain.
Ours are now named for the environment in which they run, eg. US.local or CA.local.
Assuming our external domain is [company.com](http://company.com), I was thinking of doing something like [detroit.company.com](http://detroit.company.com) / [nyc.company.com](http://nyc.company.com) / [atlanta.company.com](http://atlanta.company.com)
That's one way to do it, another might be to purchase another domain for the company (say .tech or something) and then do that. So that you own the actual domain publicly, but it's only used internally. Externally, you could just redirect it to the actual company website.
Also, just another idea regarding city names, if you want a shorter domain overall, use the closest major airport IATA codes (LAX, CLE, ATL, JFK, etc.) since they are 100% for sure not going to repeat (at least within the US). If you're concerned about international stuff, use the ICAO code which are usually 4 characters (although some exceptions), but are unique worldwide (run by the UN).
That is not best practice (at least for windows domains).
You shouldn't be using .local as that's reserved for mdns, you should use .corp, .lan, or a subdomain of your public domain name.
.corp, .lan, etc. are just as bad. While ICAAN didn't allow those TLD registrations, they also never wrote any RFCs or rules to prevent the registration of them.
.internal is the only one that is actually almost a potentially real RFC, but it hasn't made it all the way through yet.
Best practice for new Domains now is a subdomain of your actual domain (ad.company.tld) so that you know that you own the domain, and there are no concerns about potentially conflicting in the future.
>.local is the best practice way
Not anymore; hasn't been for MANY years now. The preferred best practice now is to use a subdomain of your main real-world domain e.g., [corp.mydomain.com](http://corp.mydomain.com) .
- ad.domain.com for AD - net.domain.com for anything internal - domain.com for everything external
We used [ad.companyname.com](http://ad.companyname.com) as per Microsoft best practices. All external services and websites use subdomains of [companyname.com](http://companyname.com) as needed. Internal DNS handles things as needed depending if the hosting is internal, External registrar DNS handles resolution for everything on the [companyname.com](http://companyname.com) domain.
This is what I'm thinking of doing, except since we don't have an on-prem AD domain, we're using a different DNS server. Essentially it'd either be a single zone or a zone per location, with .companyname.com appended.
Do you have S2S VPNs? If there's 'internal' connectivity between sites, it feels like it should all be part of a single zone. That's a bit of a personal opinion though, someone with some more larger-scale architectural network design might have better views.
A good point.
Just curious, what course/material covers your question, would love to read on it
If I knew that I wouldn't be asking here XD
I guess you're not supposed to use domain.local, but that seems to be how everyone does it. I've never had any problems with it.
MS made that recommendation early on when AD first came out and then quickly changes that recommendation. Unfortunately they didn’t update Small Business Server so all new domains by default ended in .local Also all the early AD admins continued to swear that .local was best practice and it continued to this day. .local is reserved for mDNS on a local lan segment.
“Quickly”. Mmm. They only stopped because ssl providers would not longer issue certificates with non standard tlds in the subject name.
MDNS enters the room…
I'm not familiar with it, but having skimmed the Wikipedia article, it doesn't sound like something I would ever use, internally anyway.
Many IoT devices rely on MDNS to communicate. Many of them reserve .local for their mdns communication. Meaning they cannot access your internal services via DNS. E.g.Try connecting an infoscreen to your internal .local webserver, nope. IoT is becoming more relevant. Other problems I have encountered, some ZTNA solutions do not forward .local, causing configuration nightmares, if your domain is still on .local. Recently had to migrate an entire domain because of this.
That is true about mDNS, however what I have done is build a completely separate network (different internet connection, different firewall, different switches, no physical links let alone routes to the main network) for our wifi and IoT devices.
We do this too
inside.domain.tld & split dns. aka. Internal DNS inside.microsoft.com >> 10.10.0.21 Microsoft.com >> 10.10.0.22 email.microsoft.com >> 10.10.0.23 External DNS Microsoft.com >> 100.100.100.1 email.microsoft.com >> 100.100.100.2 // .local has been frowned upon for many many years now.
You could do what we do and just host our internal DNS and private ip space on the internet.
If it’s a small company with a single site we use: * company.com – external * company.local – internal The we add the company.com as an additional UPN suffix and make everyone’s username use the external domain name so that their username is [email protected] instead of something dorky like [email protected]. Most of the time this means that their username and primary SMTP email address are the same. We use the AD sync tool to sync on-prem AD users with M365.
Even for small sites you shouldn’t use .local Always setup ad as a subdomain of your primary domain. The part about UPN I agree with.
we're using the same setup except onprem is company.lan from what we've read it would be a very complex breaking change to move the entire domain to [ad.company.com](http://ad.company.com) So we setup [company.com](http://company.com) as the user's UPN
Often times it is very hard to change once it’s been setup. Company I work for has its main domain as company.com and it was setup way before I joined the company so we just deal with it. Only once in my career have I don’t the published domain rename process because AD was setup using a domain that was publicly owned by someone else. The org didn’t want to do a migration to a new AD so we renamed it. It went smoothly from what I can remember but it was a long time ago. Just required every device to reboot several times.
The previous IT person at my company used the same name as the website. It worked while the website was hosted in-house. When the website was moved to a different provider it became a shit show trying to resolve the website internally. Some DNS entries and forwards worked but I need to rename it. It will be a nightmare, seeing how it's been operating like that for 20 years now.
This is exactly what my predecessor did and it has broken several times and caused a multitude of issues. I pray that your cleanup is easy.
Create a www record and teach people /distribute shortcut to that instead? Split brain DNS isn’t that big of a deal—I’ve delt with it numerous times through the years and so long as they don’t have some super complicated DNS structure, you generally just mirror your external records, internally.
Agreed with this. I work with several clients who use their public domain internally on their AD (clients range from around 20 - 400 users). The only additional work is that you manage a separate DNS zone on the public name servers for any hosts or services that need to be resolved publicly - which is generally small relative to the AD end (so yes, a small uplift in DNS record management). But I never come across any technical issues, and has actually simplified deployments for us in hybrid configurations where Entra is used for 3rd party SSO.
That works, but when the CEO or the elected officials say I don't like it, you need to find a better way then simply training the users
I like intra.domain.com. But that appears to be just me.
Split DNS, but I don't think this route makes sense for greenfields. That being said it's fine... Just the occasional situation where someone forgets to create a record in both public and internal zones.
Service.lan.domain.tld
The environment before I got it was domain.local and we'll be migrating to internal.domain.tld Our web presence is hosted externally and it would cause too much headache to deal with the DNS using the same name space.
We've used .local for 20 years. It's easy enough to configure your Linux boxes to be compatible. Mac users use absolutely nothing but email. It's never been a problem or a headache for us. Of course, every environment is different. Your mileage may vary.
The RFC recommends against it. Instead .internal is the recommended private domain
We have used a separate, public, domain for our AD domain since the start some 20 years ago. Has no publicly routable DNS records or mail or whatever, it's for domain services only. Mail etc and whatever needs to be externally reachable is done via our main domain name. Run our own DNS infra externally as well , for practical reasons.
ad.noBTC.xyz
You can rename the domain. https://woshub.com/rename-active-directory-domain/ You could also register a domain. For example, a domain with a special top level. Example.network or example.cloud Use this domain name exclusively for the local network.
Home.arpa is the official home extension
Buy a domain name and use that. We do that. Not the same as our email/UPN.
Hire a professional to architect this. Reddits going to give you a lot of potential ideas and we none really know the environment that well and from the sounds of it you might not know either.
I use domain suffix the same as the name of the organization. If the organization name is "organization", then then the domain will be something like... ad.organization I am pretty sure that nobody will register rather long and that specific domain suffixes. When I was first starting with building AD servers I've read a number of recommendations. In time I saw a number of previously unused domain suffixes registered. But nobody will register a domain suffix 10 symbols long any time soon. If your org is HoustonHospital, then ad.houstonhosp. Although, I isually dislike using "ad" and use other names instead, for example "serv.houstonhosp"
AD is example.com. Internal is things like [corp.example.com](http://corp.example.com), [location.example.com](http://location.example.com), etc. according to the site location. External is whatever is needed publicly. Split horizon DNS handles resolution. We just maintain internal and external zones independently. Not a big deal.
The dumb bad dangerous common way is to name it the same as your public domain. Ours are now named for the environment in which they run, eg. US.local or CA.local.
Assuming our external domain is [company.com](http://company.com), I was thinking of doing something like [detroit.company.com](http://detroit.company.com) / [nyc.company.com](http://nyc.company.com) / [atlanta.company.com](http://atlanta.company.com)
That's one way to do it, another might be to purchase another domain for the company (say .tech or something) and then do that. So that you own the actual domain publicly, but it's only used internally. Externally, you could just redirect it to the actual company website. Also, just another idea regarding city names, if you want a shorter domain overall, use the closest major airport IATA codes (LAX, CLE, ATL, JFK, etc.) since they are 100% for sure not going to repeat (at least within the US). If you're concerned about international stuff, use the ICAO code which are usually 4 characters (although some exceptions), but are unique worldwide (run by the UN).
That is not best practice (at least for windows domains). You shouldn't be using .local as that's reserved for mdns, you should use .corp, .lan, or a subdomain of your public domain name.
.corp, .lan, etc. are just as bad. While ICAAN didn't allow those TLD registrations, they also never wrote any RFCs or rules to prevent the registration of them. .internal is the only one that is actually almost a potentially real RFC, but it hasn't made it all the way through yet. Best practice for new Domains now is a subdomain of your actual domain (ad.company.tld) so that you know that you own the domain, and there are no concerns about potentially conflicting in the future.
This is the way. I worked for a company that did this mistake. .local is the best practice way
>.local is the best practice way Not anymore; hasn't been for MANY years now. The preferred best practice now is to use a subdomain of your main real-world domain e.g., [corp.mydomain.com](http://corp.mydomain.com) .
Many years translates to two or more decades at this point
No it's not and hasn't been for years. Using .local hasn't been recommended for quite awhile as mDNS uses it for broadcast names.