DNS Question, also pertains to Active Directory

[sornywrx]

I manage a small domain here at work with a single forest/single domain setup. Our domain name is the same as our public name (example.org) and we used to host our own web server here. We recently outsourced that to another place and are having a minor problem; when a user opens a browser and types in www.example.org they get our site. When they just type in example.org they do not get our site. I had to add the CNAME record for "www" and point it to the IP of the new web server and that works great.

I already know why when they type in example.org it doesn't load -- because the A records for "example.org", listed as "Same as parent folder" in Microsoft DNS, points to servers in our network, the DNS servers.

So I was thinking ok, great, I'll just delete the 2 A records for the domain and add a new one pointing to the off site web server. But then I started wondering if removing the "Same as parent folder" A records for the domain will screw up Active Directory. I thought all of the necessary AD DNS stuff was handled under the _MSDCS.example.org subdomain but don't want to delete the old A records in the example.org domain and then have issues.


Any ideas?

Also, might want to add that this change is only for the INTERNAL clients on our network. Of course if you're outside the network and using any other DNS server besides our internal (private) DNS servers the A record for example.org only points to the web server and works fine. It's just that the users here, who are pointing to our DNS servers inside, are having issues.

 

[GeekDrew]

But then I started wondering if removing the "Same as parent folder" A records for the domain will screw up Active Directory.

Yes - doing so will cause numerous problems. Don't do it. There is no supported way to do what you want -- Active Directory domain names should _never_ match the name of a "real" website.

 

[sornywrx]

Yes - doing so will cause numerous problems. Don't do it. There is no supported way to do what you want -- Active Directory domain names should _never_ match the name of a "real" website.

Well I couldn't think of a way it'd work and not cause AD problems but wanted to verify. However, although I know the rule used to be to use a .local (or other non-public) domain I thought that after I learned to do that Microsoft changed their mind and started recommending MATCHING the name to the real domain. Or have they switched back to recommending a private internal domain for AD?

 

[imagoon]

General recommendation is using a subdomain.

internal.company.com vs company.com or company.local.

 

[sornywrx]

General recommendation is using a subdomain.

internal.company.com vs company.com or company.local.

See, I've seen that even less often than company.com or company.local. When I was doing my MCSE (for 2003) all of the materials I went over was pushing .local. When I started studying some newer material (more like Server 2008) it all mentioned Microsoft recommending a good firewall and matching the company AD to the outside registered domain name. But it all may be more of the personal preference to whoever is writing the book or making the training videos.

 

[imagoon]

you can use company.com as long as you are aware that "company.com" will always land at a domain controller in your organization. I have seen it done all 3 ways, each has disadvantages. The least of which is using an internal subdomain. I normally see stuff like chicago.company.org and newyork.company.org etc.

 

[sornywrx]

you can use company.com as long as you are aware that "company.com" will always land at a domain controller in your organization. I have seen it done all 3 ways, each has disadvantages. The least of which is using an internal subdomain. I normally see stuff like chicago.company.org and newyork.company.org etc.

Well besides lazy people not typing in the "www" before our website, there's been any issues about it so it's not been a problem.

However, since we are using a 3rd party hosted DNS service and have no public DNS servers, anyone outside the LAN cannot access any machine inside the LAN except for one server, which has a static DNS record on our 3rd party public DNS pointing to its public IP. So company.com lands on a DC at work but outside it hits a public DNS that we don't even own.

 

[GeekDrew]

In my opinion, the _only_ sane way to name the domain is using a subdomain of a properly registered domain (i.e., dom.geekdrew.net). Making the domain match the outside domain name (geekdrew.net) will cause DNS resolution issues on one side or the other, and using ".local" causes certificate issuance issues - plus there's a non-trivial risk of duplicate domain names, since .local isn't registered.

As for books, yes, it's all author's opinion, and over the years, there have been many opinions. Back in 2003, federation and certificate issuance issues weren't nearly as obvious as they are today.

 

[sornywrx]

Back in 2003, federation and certificate issuance issues weren't nearly as obvious as they are today.

I believe certificate issues were one of the main reasons mentioned in the later materials I've read about switching from .local to matching with the public domain or a subdomain of the public domain.

 

[GeekDrew]

However, since we are using a 3rd party hosted DNS service and have no public DNS servers, anyone outside the LAN cannot access any machine inside the LAN except for one server, which has a static DNS record on our 3rd party public DNS pointing to its public IP. So company.com lands on a DC at work but outside it hits a public DNS that we don't even own.

That's generally not a bad thing -- you usually should not want people outside to be able to query your internal DNS resolvers. Those which are inside should _only_ ever query a domain controller.

 

[GeekDrew]

I believe certificate issues were one of the main reasons mentioned in the later materials I've read about switching from .local to matching with the public domain or a subdomain of the public domain.

If you can cite any materials recommending that you match a public domain name, please do so. Those books are materially incorrect.

 

[sornywrx]

That's generally not a bad thing -- you usually should not want people outside to be able to query your internal DNS resolvers. Those which are inside should _only_ ever query a domain controller.

Oh no, definitely not a bad thing and worrying about the security of public DNS servers is one less thing I have to worry about. I always have the option of setting up some public facing DNS servers in our DMZ and pointing our internal AD DNS servers to that but definitely not worth it.

 

[sornywrx]

If you can cite any materials recommending that you match a public domain name, please do so. Those books are materially incorrect.

I was scouring my laptop for a PDF copy of one of the books I used to study for the MCSE and do not have it on my laptop. I do still have all those books stored away at home. I had almost forgotten that they called it split brain DNS and the more I thought about it the more I remembered it being listed as an available option and not necessarily "recommended' over the other ways such as private .local names and subdomains but just being an available option at least. And I do remember in one of the training videos I had that it was mentioned as a side not about the recommendation going from using .local to subdomains or split brain.

 

[Genx87]

They used to push .local for this very reason. But apparently some protocol primarily pushed by Apple nobody uses has reserved .local for itself. And it could cause problems if you are using a non-microsoft DNS hosted AD partitions with apple products on the network.

You can use a sub domain or just use .local unless you plan to use that odd configuration. I'd probably suggest using a sub domain from now on.

 

[sornywrx]

You can use a sub domain or just use .local unless you plan to use that odd configuration. I'd probably suggest using a sub domain from now on.

Never having asked other people before I assumed split brain was the way to go from what I understood. But you guys all seem to agree about using a sub domain and when googling around (trying to find one of the books I was talking about) I kept seeing recommendation after recommendation to do the same. In the future, as I setup more domains, I'll use it.

 

[kevnich2]

Yeah I've always used .local for internal AD purposes myself. Leave it to apple to start screwing things up but hey I guess if you don't use that particular apple service, shouldn't be affected by it anyway.

 

[GeekDrew]

Yeah I've always used .local for internal AD purposes myself. Leave it to apple to start screwing things up but hey I guess if you don't use that particular apple service, shouldn't be affected by it anyway.

That's just one reason why, and never say never - you might have Apple equipment in the future, even if you swear you won't.

You also can't get any publicly signed certificates - which is an issue for some, and isn't for some. There are also federation considerations. In short, there are numerous reasons not to use .local - but there are no reasons _to_ use .local. Always make it a subdomain of a real domain, and you'll be safe in the long run.

 

[imagoon]

That's just one reason why, and never say never - you might have Apple equipment in the future, even if you swear you won't.

You also can't get any publicly signed certificates - which is an issue for some, and isn't for some. There are also federation considerations. In short, there are numerous reasons not to use .local - but there are no reasons _to_ use .local. Always make it a subdomain of a real domain, and you'll be safe in the long run.

So I am not that well versed in ADFS... is .local impossible to use or is there some long gyration needed to make it work?

 

[GeekDrew]

So I am not that well versed in ADFS... is .local impossible to use or is there some long gyration needed to make it work?

It's not impossible - most of the federation issues are resulting from certificates, duplicate names, proof of ownership, and policy.

 

[imagoon]

It's not impossible - most of the federation issues are resulting from certificates, duplicate names, proof of ownership, and policy.

It looks like since this org has UPNs that are valid (from exchange) that I can use the wildcard cert. Hoping that works correctly then.

 

[sornywrx]

It looks like since this org has UPNs that are valid (from exchange) that I can use the wildcard cert. Hoping that works correctly then.

Another admin I know who runs a AD with a .local domain has setup Exchange with UPNs and I remember him saying he just bought a widlcard cert from GoDaddy and its been working fine for him.

 

[drebo]

That's just one reason why, and never say never - you might have Apple equipment in the future, even if you swear you won't.

You also can't get any publicly signed certificates - which is an issue for some, and isn't for some. There are also federation considerations. In short, there are numerous reasons not to use .local - but there are no reasons _to_ use .local. Always make it a subdomain of a real domain, and you'll be safe in the long run.

That's bullshit. You absolutely can get certificates with .local domains in them. I get them all the time for my customers.

 

[imagoon]

That's bullshit. You absolutely can get certificates with .local domains in them. I get them all the time for my customers.

Not after 2015 you won't be able to. We had to reset all of our 3 year certs to 2 this year because the internal .local domain address was invalid because the cert expired after November 1st, 2015.

http://www.digicert.com/internal-names.htm

GoDaddy etc all have the same policy. We intend to rename the domain as a 2014 project...

 

[GeekDrew]

^ what imagoon said. 😉

Lesson? Think long-term from the beginning. Don't eliminate your options unnecessarily.

 

[kevnich2]

Not after 2015 you won't be able to. We had to reset all of our 3 year certs to 2 this year because the internal .local domain address was invalid because the cert expired after November 1st, 2015.

http://www.digicert.com/internal-names.htm

GoDaddy etc all have the same policy. We intend to rename the domain as a 2014 project...

Yeah that's definitely a game changer. Although it's not quite as easy as they make it sound to simply "switch to publicly available names on your servers" The other alternative is to configure your systems to use internal CA's and issue your own certificate's for internal purposes.