Why use a .local?

I've seen a lot of companies use a .local domain internally and I've never really understood why? Say Company 1 have a domain called example.com, what are the advantage of using example.local internally vs example.com?

I would think that using example.com would be better because if they try to go to their website or whatever service they offer, they wouldn't have to go outside to resolve the name only to come back in

Find more posts tagged with

Comments

Daniel333

Consider you own the Chipotle company and you choose to use a public .com rather than the internal .local.

On the inside if you ping chipotle.com it will NOT resolve your web site. But actually your domain controller. Active Directory is setup to that a ping to the root of the domain will help you find your DCs. You don't want to override this behavior. This alone is a very valid reason to use the internal name space.

Next, suppose you slap a www in front of chipotle.com to force it to your web servers. You would still have to manually go into your DNS servers and give it a path to your web servers. This of course assumes you even have your web servers on your network. It's much more common these days to let a third party company host your web sites.

I would say the final reason is there is no reason for the public internet to be addressing your internal workstations or server by name. So we should not be implementing it. If you have devices that the public internet can address. They should not be on your domain and have their own DNS namespace in your physical DMZ.

ehnde

If it's internal, they can use .foobar if they want to. An internal .com domain is potentially confusing. If it's internal and it can't be accessed from outside of the network, .local makes sense. It serves as a reminder that the server being accessed is on a company network, not the public internet.

I would think that using example.com would be better because if they try to go to their website or whatever service they offer, they wouldn't have to go outside to resolve the name only to come back in

If example.com is, say, a company fileserver with sensitive documents about customers, would you want it to be on the all important outward facing company domain? Example.com is - ideally - a locked down webserver with only services that are absolutely necessary. As far as resolving the name goes, I'm assuming the example.local network has a domain controller. The domain controller would probably handle internal DNS requests, and this shouldn't be too big of a deal. Someone correct me if I'm wrong.

QHalo

Windows 2008 mDNS and .local domain names

pham0329

Consider you own the Chipotle company and you choose to use a public .com rather than the internal .local.

On the inside if you ping chipotle.com it will NOT resolve your web site. But actually your domain controller. Active Directory is setup to that a ping to the root of the domain will help you find your DCs. You don't want to override this behavior. This alone is a very valid reason to use the internal name space.

...but as long as everyone puts a www. infront of chipotle.com, there would be no problem, right?

Next, suppose you slap a www in front of chipotle.com to force it to your web servers. You would still have to manually go into your DNS servers and give it a path to your web servers. This of course assumes you even have your web servers on your network. It's much more common these days to let a third party company host your web sites.

There are lots of companies that hosts their own websites. It wouldn't be that much of a hassle to create a CNAME record.

I would say the final reason is there is no reason for the public internet to be addressing your internal workstations or server by name. So we should not be implementing it. If you have devices that the public internet can address. They should not be on your domain and have their own DNS namespace in your physical DMZ.

Maybe I overlooked something but how would the public internet access my internal DNS server?

ehnde

So using .local is a security risk because of multicasting?

pham0329

ehnde wrote: »

If it's internal, they can use .foobar if they want to. An internal .com domain is potentially confusing. If it's internal and it can't be accessed from outside of the network, .local makes sense. It serves as a reminder that the server being accessed is on a company network, not the public internet.

If example.com is, say, a company fileserver with sensitive documents about customers, would you want it to be on the all important outward facing company domain? Example.com is - ideally - a locked down webserver with only services that are absolutely necessary. As far as resolving the name goes, I'm assuming the example.local network has a domain controller. The domain controller would probably handle internal DNS requests, and this shouldn't be too big of a deal. Someone correct me if I'm wrong.

Either I missed a big chapter during my studies, or I'm not understanding what's being said in the last couple posts.

From what I understand, and someone please let me know if its incorrect, but just because I use an .com domain for my AD infrastructure, does not mean that it's accessable on the internet. It's the same reason why I can't put an MX record on my internal DNS to receive external mail.

ehnde

pham0329 wrote: »

Either I missed a big chapter during my studies, or I'm not understanding what's being said in the last couple posts.

From what I understand, and someone please let me know if its incorrect, but just because I use an .com domain for my AD infrastructure, does not mean that it's accessable on the internet. It's the same reason why I can't put an MX record on my internal DNS to receive external mail.

Yes, you're right. I'm saying that using a TLD in an AD infrastructure only accessible to a private network, and also using the same domain name externally is confusing. I suppose you could use int.domain.com (as opposed to domain.local). Sorry I suppose this point is trivial.

Other than the point made about .local, the AD naming scheme just needs to make sense to the network admin, and it doesn't matter what it actually is. At least this is what I was taught last Wednesday in class

undomiel

It is more of a problem of accessing external resources than accessing internal resources. Your internal DNS server will be resolving all of your example.com addresses to the internal addresses but won't forward any requests for an external address. So if they put in Example Web Page expecting to hit the external company website they won't get anything since your DNS server would check its example.com zone and find no www A record. Now you can get around that by manually adding and maintaining your www A record by pointing it to the address for the website but that does add some extra management overhead whenever things change on your external DNS. Going with .local or .foobar or whatever fake tld you want will make management a whole lot less of a headache for you.

Bl8ckr0uter

Oh my god does it cause problems when you don't own the external domain. We have that problem now. There was something with WINXP that it wouldn't register with top level domains and it was causing some interesting problems lol. It is never a good idea to name your domain after a top level, even if you own the public domain.

MentholMoose

pham0329 wrote: »

...but as long as everyone puts a www. infront of chipotle.com, there would be no problem, right?

If you have no external resources, or only one www that remains static, it doesn't matter much. But what about the future? What happens if your web site gets popular and your web group implements a load balanced infrastructure that needs DNS for servers www01 through www99, and those servers need to be on DHCP, and now your web site doesn't work for internal users unless you constantly maintain 100 A records manually?

Basically, using the same domain guarantees you some extra work, could be a potentially big problem, and there is very little, if any, benefit. Not having to go "outside" for DNS is not a benefit if you are allowing access to the outside for web sites. The default configuration of DNS on a DC will include caching so most of those queries for those resources outside will be cached anyway.

If you really, really want DNS on your DCs to have the external records, then make your internal domain ad.blah.com and setup blah.com as a secondary zone. AFAIK this is not more efficient that the standard caching, and is certainly more work (caching is the default, you don't have to do anything for it to work).

pham0329

MentholMoose wrote: »

Basically, using the same domain guarantees you some extra work, could be a potentially big problem, and there is very little, if any, benefit. Not having to go "outside" for DNS is not a benefit if you are allowing access to the outside for web sites. The default configuration of DNS on a DC will include caching so most of those queries for those resources outside will be cached anyway.

There are routers/firewalls out there that won't allow you to go outside, only to come back in because they deemed it as a security risk. For example, we have a client who is hosting Exchange and their CEO can't access OWA on her Ipad because their firewall won't allow them to go outside and come back in using the public IP.

I see the benefits of using a .local if it's a big enough environment, but for small businesses with maybe 2 or 3 servers, does it matter?

undomiel

pham0329 wrote: »

For example, we have a client who is hosting Exchange and their CEO can't access OWA on her Ipad because their firewall won't allow them to go outside and come back in using the public IP.

Did you just answer your own question here? SMBs like to use their iPads as well and get very grouchy when they don't work as expected on the internal wireless. From small networks to large networks it is still a royal pain to lump up extra DNS management baggage.

RobertKaucher

pham0329 wrote: »

I see the benefits of using a .local if it's a big enough environment, but for small businesses with maybe 2 or 3 servers, does it matter?

Because it requires a split in the DNS structure which increases the complexity of managing the environment.

1. Let's say that MyCorp .com is the internal and external domain name.
2. Let's assume that the company's web site is hosted via GoDaddy or whatever service since this is a small business it is unlikely they would host their own web site. Why pay for the static IP?

Ok, so the admin (who only works on a contract basis) has set up the DNS with a static entry for www to point to their web site. VP of Sales keeps typing MyCorp .com into his address bar and does not get to the web site. "Why not, I can do it at home? Why do I have to remember to type www while I'm here at work?" he complains. The GoDaddy changes the IP address associated with the MyCorp .com web server and suddenly no one in the office can get tot he web site. CEO is in a panic, the web site is down! He calls GoDaddy - "No, it is functioning normally," they say. He calls the Internet provider, "Why can't I access my company's web site?" "It is functioning normally," they say. Finally he calls the admin after wasting an hour of his day and the admin has to remote in and fix the DNS records.

You tell me... Does that matter?

jojopramos

For me, the best reason that administrators use .local for thier internal domain is because of security reason. You don't want to expose your internal domain to the internet. Okay, suppose you configure a packet filter on your firewall, it is still best as per Microsoft to hide the internal domain via using .local. Anyway, the companies external DNS will be the one to resolve the name externally via public IP to .com for example.

ehnde

I don't understand why a company's website should be accessed any differently internally than it should externally. Your AD infrastructure could be named simply contosoacc, and your website contoso.com.

Contoso.com should be on a DMZ. Internal users can get to contoso.com just like the companies customers outside of the network because you're a good network admin and know how to configure DNS.

changlinn

you will have problems with a TLD that can be resolved externally. There are issues of DNS devolution in some apps, including ones built into windows, there was one in WPAD (Windows Proxy Auto-Discovery): where IE would if set try to resolve wpad.dns-search-suffix.tld (the DNS-search suffix sets itself to the domain) and if wpad.dns-search-suffix.tld is not found it used to stupidly go to wpad.tld.
So if you have contoso.com and no wpad.contoso.com then it tries to get your proxy settings from wpad.com great for the person who owns wpad.com
I have seen even in recent times shortcuts to windows shares do this, one that was trying to resolve finance.dnssuffix.com.au then finance.com.au, it was even attempting to send the ntlm hash to finance.com.au which would have been great if you were out there listening for it on 445.
Microsoft best practices are to use non internet resolvable TLD, so .local .lan .whatever