Resolving DNS issues in an Active Directory Domain ending in .com instead of .local

Question

I just started working for a customer who had a previous IT company setup their domain. They have about 30 computers in their domain and are running Server 2008 with Microsoft Exchange 2007.

Their previous IT guy named their domain with a .com instead of a .local, despite the fact that they DO NOT OWN the actual .com address. For sake of argument, we will call their domain: contoso.com. All networks I do work on end in .local.

This causes problems because all computers in a domain are technically subdomains. So if your domain is contoso.local and your computer name is computer1, the FQDN of your local computer is computer1.contoso.local. When you try and access a network share on computer2 or ping computer2, it looks up the FQDN in DNS to resolve the IP address. Because they are using contoso.com, it attempts to lookup computer2.contoso.com. As long as the computer has registered with DNS and it does exist, it will be found.

When I ping somethingthatdoesntexist.contoso.com, instead of failing to ping, I literally start getting ping responses back from a public IP address. The only DNS settings on all of the computers in the network point to our domain controllers. Both domain controllers only point to themselves. There IS a fowarder in the DNS Server in the primary domain controller to our ISP's DNS servers in addition to both opendns servers as backups. If I did not have any forwarding, nothing on the network would be able to resolve internet IP addresses.

However, programs like Outlook 2007 which automatically try and configure based on guessing subdomains are in for a rude awakening. When an address does not exist in the local DNS server for say, mail.contoso.com, it forwards out to our ISP's DNS servers which report back a public IP address (not owned by my customer). This is causing lots of little headaches and annoyances, besides the fact that Outlook 2007 will not autoconfigure.

I have resigned myself to the fact that changing from .com to .local would be too much work, especially since Exchange is involved. So my question is, how do I disable DNS from forwarding requests ending in contoso.com? This would be a quick fix.

Also, I would be open to any suggestions on switching from .com to .local if it doesn't involve scratching the current domain and recreating everything.

(In response to Joseph Kern...)

Have explained the situation to the customer. This is one of a bunch of major problems that we are dealing with. This is why the last guy was fired. Unlike the other problems, I have no idea where to start with this one.

Thanks!

Solution 1

It sounds like you need a domain rename but, unfortunately, domain rename isn't "supported" in an Exchange 2007 environment. It's rather galling, actually.

On the surface it sounds like you're talking about being in the old "we named our Active Directory domain the same as our Internet domain name" problem, except that the name chosen was somebody else's Internet domain name.

What I don't follow, though, is your statement "When an address does not exist in the local DNS server for say, mail.contoso.com, it forwards out to our ISP's DNS servers which report back a public IP address (not owned by my customer)". The Microsoft DNS server won't forward requests for names in a domain that it's authoritative for. Your statement has me a bit baffled. If your internal DNS servers are authoritative for "contoso.com" then they'll never forward any requests ending in ".contoso.com" to the Internet. Period.

It sounds to me like you might have public DNS servers specified in client or server NIC properties or DHCP options and those public DNS servers are resolving the Internet version of "contoso.com" for your clients. You should never specify non-domain controller DNS servers in the NIC properties of any computer joined to an AD domain (unless you really know why you're doing it).

So, do you have public DNS servers specified in NIC properties or DHCP options for client and / or server computers?

Solution 2

While not the best situation, it's certainly not the end of the world. At the end of the day the only thing affected should be access to the "real" contoso.com domain.

From what you've said there appears to be something wrong with your internal DNS. As Evan has pointed out, your internal DNS servers are authorative for the contoso.com domain and should never forward requests for that domain to any other name servers. In addition, the fact that you're unable to resolve external DNS records without the use of forwarders tells me that your DNS servers are not configured to use the root hint servers. This will work, but IMHO is not the best setup to go with. You're completely reliant on the safe, stable, and reliable operation of those forwarders. If they're broken, you're broken (for external DNS records).

My suggestion as a first step would be to run a packet sniffer on one of your client machines, filter for DNS, and attempt to resolve non-existent DNS records in the contoso.com domain. Look at the capture and see exactly where the DNS queries are going and what answers are being returned and from where. Then do the same thing on the next "link in the chain", meaning if the queries are sent to and answered by your internal DNS servers, then run the same capture on your internal DNS servers and see what shows up.

Solution 3

You shouldn't be using .local either... .local is supposed to be used with multicast DNS, which is an actual internet standard. You should be using a valid domain name that you have the right to use or one of the RFC 2606 reserved TLDs.

The fixes to this problem are registering the name that's in use or migrating a new domain with a valid name.

The "quick fixes" you're talking about are hacks that will probably cause problems down the line. Your client may not be willing to shell out for a real fix, but they need to be educated about them and understand the choices that they are making.

Solution 4

So my question is, how do I disable DNS from fowarding requests ending in contoso.com? This would be a quick fix.

This makes me want to cry. I understand your time constraints, but ...

This is not fixing the problem, if you try to gloss over it, you would be doing as much damage as the previous "admin".

Have you addressed this with your customer?

View more solutions

Comments

[Joseph Kern]

Oh. My. God. This will be a story you tell your kids.

[James Watt]

Evan thanks for your comments. I consider the computer which holds the role for PDC (per ntsdutil) the primary domain controller. I understand it has changed a lot and Microsoft wants to depreciate that whole term, but I still use it.

[Joseph Kern]

Take a look over to the right -> See all the Related questions ... This is a common problem. Well, common enough.

[Wesley]

I have yet to be presented with evidence that the old "we named our Active Directory domain the same as our Internet domain name" problem is in fact a problem. Aside from a trivial case of maintaining split DNS, it's just as good as a false TLD like .local or .internal. I'd love to hear your thought to the contrary (I've read a fair amount so far and found nothing of substance)... but that might be dragging this thread away from the original intent.

[Wesley]

Tell that to Microsoft who uses .local in most of their materials and also defaults SBS 2008 to a .local TLD unless you jump through hoops to create an answer file for the installation. +1 for saying that using your TLD is a valid way of naming an AD domain.

[Spence]

@Nonapeptide: When it comes down to it, it's about make-work versus no work. You gain no advantages by using the same name for your AD domain as for your Internet domain name. You do, however, gain the make-work job of having to keep split DNS up to date. If you want "domain.com" entered in a web browser to bring up "www.domain.com", you have the added requirement of having to run an HTTP server on every DC doing a redirect to "www.domain.com". So, if you get nothing of value by naming your AD domain the same as your Internet domain name and it creates make work why do it?

[Spence]

I'd be all for using the same name if you actually got something for it, but you don't. It's all down-side and no up-side. It's a "religious issue" to me, I guess, because I can't abide by IT workers creating make work. Silly make-work is part of what makes "bean counters" think of IT as an expense instead of an investment.

[duffbeer703]

You have to read Microsoft documentation with a critical eye, especially documentation the originated in the 90's, as many factions of the company pay little heed to minor things like generally-accepted standards. Case in point, my employer has a single-label domain with a made-up TLD that has tens of thousands of users and thousands of sites. This (bad) design was cooked up by some top-notch Microsoft folks back in 1999 when they were a beta AD site.

[duffbeer703]

It's not make-work at all. You use a subdomain of your domain and make your AD servers authoritative within it. The advantage of working this way is that things actually work when you do things need to federate with business partners.

[Spence]

@duffbeer703: You and I are on exactly the same page. I believe Nonapeptide is talking about using your second-level domain as the AD domain name. I am a big proponent of using a subdomain of, like "ad.example.com" for the AD domain name.

[Spence]

The make-work comes in when you use your second-level domain name for your AD domain name and have DNS servers both inside and outside the firewall that are authoritative for the same namespace. Then you're forced into an ugly make-work by-hand replication scenario to get RR's from the Internet DNS into the LAN DNS.

[Spence]

Ewwww... that sucks. I feel for you. We have one Customer with a single-label domain and it's a pain. I hope you haven't started using Exchange 2007 yet... msexchangeteam.com/archive/2008/02/15/448140.aspx

[Wesley]

Very good points, fellows. I admit I've worked in smaller deployments where the make-work of maintaining a split-DNS infrastructure ate up a whole 3 minutes and 45 seconds of the admins entire career -- and 3:30 of it was on the first day of deployment. Having a third level domain as the AD domain is a very good solution, IMO. I may do that on my next AD greenfield project. However there is one thing that using the same internal and external domain can help with:

[Wesley]

Some people are probably already shouting at their screen "Use alternate UPNs!!" and I have, however it's virtually impossible to make an alternate UPN the default UPN for a newly created user unless you do some black-art hacking into the AD schema. However, I suppose I could solve even that slight wrinkle by creating a nice Excel based AD user creation scripting widget that would then automatically include the alternate UPN. At least I'm assuming you can do that with dsadd, I haven't looked deeply into it.

[Spence]

@Jim B: I think the prevailing opinion in MSFT docs now is to use either a subdomain of your Internet name or a registered Imternet domain name that you don't otherwise use to host Internet resources. In the 2004 time-frame when I was teaching MCSE classes at a local college using "Microsoft Official Curiculum" docs the recommendations were pretty sound (finally).

[Wesley]

Either way, it appears that, bearing my UPN username demands in mind, roughly the same amount of time will be spent fixing /something/ whether you use an external or internal domain for AD. I still like the idea of a unique third level domain for AD... if only the alternate UPN thing could be worked around. Anyways, all of this to say that you've all made great points about not using your real-life domain for your AD domain. But in the end, there's nothing fundamentally, technically wrong with it save the expense to maintain split-DNS. Which some would say /is/ a fundamental wrong if admins...

[Wesley]

...are spending their time doing busywork like that. Point taken. I wish they'd let more characters go in a single comment. =)

[Spence]

@Nonapeptide: You already know that the UPN suffix has nothing to do w/ the domain name. The "default UPN suffix" is set by "Active Directory Users and Computers". If you create a user with "dsadd", "NET USER", ADSI, or via LDAP there will be no UPN suffix set. The "default UPN suffix" is purely an AD Users and Computers construct. I typically provision users via script anyway, so the UPN suffix assigned by AD Users and Computers is irrelevant to me. re: split DNS taking "3 minutes" -- You must not have Customers who have the IP address change on their external web hosting with any frequency.

[Spence]

Except that what the poster is describing can't happen with a Microsoft DNS Server. He's saying that the DNS Server is forwarding requests for domains it's authoritative for. That's not a possible behavior of a Microsoft DNS Server. Something else has to be afoot. Anyway, he already has "split-brain" DNS. He's got DNS servers behind his firewall that are authoritative for a real Internet domain name.

[Wesley]

"You already know that the UPN suffix has nothing to do w/ the domain name." I'm not sure I follow you on that. The default UPN suffix in a domain is the domain + the TLD so I see a connection between them. A new AD domain called newdomain.local will have users that default to "[email protected]". If I then create a new alternate UPN that mirrors the outside domain: external.com, all new users are still created with the assigned UPN as newdomain.local by default. My user orientation documentation that states "always use your email address as your username. Always." doesn't work.

[Wesley]

I then have to remember to change the user's UPN to the alternate UPN when the user account is created. I'm unsure if dsadd can handle changing the user's UPN to an alternate. I'll check that shortly. If the internal domain simply mirrors the external domain then there is no worries about an alternate UPN not being the default for new users. I do admit that this "problem" of mine is all because of my own desire for username semantics which was instated when I got my own domain to manage. The last place I worked at had some authentication issues that plagued the help desk...

[Wesley]

...because users were not putting the right username format in certain inputs. It even confused us, the IT staff, from time to time. Imagine hours of troubleshooting when you finally look at the other tech and say "Wait... did you try putting the domain PLUS the TLD in the username field?". For the record, I have never named an internal domain the same thing as an external domain, but instead deal with alternate UPNs. And am annoyed at it so far.

[Spence]

I agree that the UPN suffix AD Users and Computers chooses will be the domain's name (this has been covered here before: serverfault.com/questions/45576/…). This is a contrivance of AD Users and Computers and not some overarching default in Active Directory. If you create a user w/ "dsadd" (w/o the -upn argument) or "NET USER" you'll find no userPrincipalName attribute assigned to the new user object, "default" or otherwise. This behaviour you're seeing is purely in the code for AD Users and Computers.

[Spence]

As I said, I typically provision users via script (since I need to populate their group memberships, create their home directory, roaming profile directory, redirected "Desktop" and "AppData" directories, and set permissions on the whole lot of them) so the UPN gets set as part of that process. It would be trivial to write a script to reset all the UPNs in a domain, as well. I have AD deployments that are going on 9 years old, and several of those Customers have changed their external hosting providers, or had their hosting providers move to new IP addresses in that time. For some of the ...

[Spence]

ones that I've "inherited" that used their Internet domain name as their AD domain name I've had to handle keeping the internal DNS up w/ the external DNS. It's not a lot of work, certainly, but it's work that could have been alleviated by a better choice at the beginning. re: posting to Server Fault in the wee morning hours on Christmas Eve-- I'm really an AI and don't sleep anyway... >smile< (Actually, I think I'm going to finally get away from this computer and go lie down...)

[Wesley]

Thanks for seeing this comment jag through to the end. I was not aware that ADUC's meddling with the default UPN was unique to ADUC. I don't mess much with dsadd since I"m not currently managing a domain that adds much more than one or two users per year (!) and I was not in a position to muck with anything more than ADUC at my last workplace which had hundreds of users. In that case, I can use dsadd with -upn in a user creation script (or rather, an Excel spreadsheet that makes the script for me) and never again consider naming an internal domain the same as the external.

[Wesley]

I'm glad that no one brought up the canard about usernames being "more secure" if they didn't match the external domain. Oh. Puh. Leeze. This is all IMHO, of course. =) Go scrub your memory inputs... I mean, sleep. See you around tomorrow. What a solitary bunch we are. =)

[Spence]

Well, we've managed to score the coveted position of 2nd-most-commented posting in the last 30 days, per the moderator tools. 5 more comments and we'll be top... heh heh. Ohio, eh? Somewhere near Lebanon, by the sound of things. I work in Springboro / Franklin at least weekly. Maybe we'll have lunch sometime... >smile<

[Wesley]

Originally from Oregon, recently transplanted to a "lovely" place and now I'll be off to AZ soon. And when Matt Simmons was still in Ohio I used to think that it was something in the water. I started to drink more of it to get whatever you two guys had but only got a stomach ache from all the chlorine. I switched to Evian. sigh Maybe I'll have mod tools by my 40th birthday... =)

[Alnitak]

@duffbeer703 - actually mDNS isnt' an actual internet standard yet. There's only a internet draft.

[duffbeer703]

We support Exchange 2007 for multiple domains... believe me, it's a nightmare.