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!

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 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?

Answer 5

While there are ways to make this work with a split brain DNS, your best bet to fix this long term is to do a migration to a new forest. Check out the migration guide for ADMT 3.0 for details. This will allow you to not have to scrap your entire environment

Answer 6

This is Exchange 2007? Set the AutoDiscoverInternalServiceUri on the CAS server(s) to the correct internal URL. Outlook is going to look at the SCP this publishes first.