up vote 1 down vote favorite
1
share [g+] share [fb]

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. 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 fowarding 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.

Thanks!

link|improve this question
Oh. My. God. This will be a story you tell your kids. – Joseph Kern Dec 23 '09 at 20:45
feedback

migrated from superuser.com Dec 23 '09 at 20:37

This question came from our site for computer enthusiasts and power users.

7 Answers

up vote 3 down vote

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.

link|improve this answer
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. – WesleyDavid Dec 24 '09 at 0:53
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 Dec 24 '09 at 3:14
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 – Evan Anderson Dec 24 '09 at 3:56
@duffbeer703 - actually mDNS isnt' an actual internet standard yet. There's only a internet draft. – Alnitak Dec 24 '09 at 8:27
We support Exchange 2007 for multiple domains... believe me, it's a nightmare. – duffbeer703 Dec 25 '09 at 15:31
feedback
up vote 3 down vote

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?

link|improve this answer
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. – WesleyDavid Dec 24 '09 at 0:51
1  
@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? – Evan Anderson Dec 24 '09 at 2:17
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. – Evan Anderson Dec 24 '09 at 2:20
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. – duffbeer703 Dec 24 '09 at 3:19
@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. – Evan Anderson Dec 24 '09 at 3:47
show 20 more comments
feedback
up vote 3 down vote

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.

link|improve this answer
feedback
up vote 1 down vote

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?

link|improve this answer
Take a look over to the right -> See all the Related questions ... This is a common problem. Well, common enough. – Joseph Kern Dec 23 '09 at 21:01
feedback
up vote 1 down vote

Evan Anderson - When I ping somethingthatdoesntexist.contoso.com, instead of failing to ping.. I literally start getting ping addresses 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.

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.

Duff Beer - We have been using .local on domains for as long as I can remember without problems. It is what Microsoft suggests when you go through their training (or at least when I went through). I am confused by your answer?

link|improve this answer
A terminology nitpick: There are no "primary domain controller" computers in Active Directory. The PDC emulator FSMO role-holder has some special duties, but it's in no way a special "primary" copy of AD. All DCs in a domain host equal copies of AD. Nitpicking aside, you need to sniff traffic as joeqwerty suggests, then. There's no way that a Microsoft DNS Server is going to resolve a name through a forwarded if it's authoritative for the domain. You've got something else going on. – Evan Anderson Dec 24 '09 at 2:22
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. – James Watt Dec 24 '09 at 4:14
feedback
up vote 0 down vote

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

link|improve this answer
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. – Evan Anderson Dec 24 '09 at 4:27
I see your point I was thinking that the internal DNS had to be set up as caching only and the ISP dns was authoritative. – Jim B Dec 24 '09 at 16:39
feedback
up vote 0 down vote

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.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.