2

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!

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
James Watt
  • 213
  • 1
  • 4
  • 11
  • Oh. My. God. This will be a story you tell your kids. – Joseph Kern Dec 23 '09 at 20:45
  • 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 02: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 04:14

6 Answers6

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.

duffbeer703
  • 20,077
  • 4
  • 30
  • 39
  • 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. – Wesley Dec 24 '09 at 00: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 03: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... http://msexchangeteam.com/archive/2008/02/15/448140.aspx – Evan Anderson Dec 24 '09 at 03:56
  • @duffbeer703 - actually mDNS isnt' an actual internet standard yet. There's only a internet draft. – Alnitak Dec 24 '09 at 08:27
  • We support Exchange 2007 for multiple domains... believe me, it's a nightmare. – duffbeer703 Dec 25 '09 at 15:31
3

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?

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • 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 Dec 24 '09 at 00: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 02: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 02: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 03: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 03:47
  • 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. – Evan Anderson Dec 24 '09 at 03:51
  • @nonapeptideI have to agree with Evan on this. While every Microsoft doc recommends naming the domain the same as your internet name, and I think it's even on one of the exams, reality has to set in and when you think about it there is exactly 0 upside to using your external name as your internal name. I agree that it is trivial to maintian a split dns, it invites mistakes. Maintain a seperate .internal and .com DNS space is the same work and makes maintenance simpler and easier. – Jim B Dec 24 '09 at 03:57
  • 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 Dec 24 '09 at 04:16
  • I always liked having usernames that mirrored peoples email addresses. I have my users use the UPN format of their username at all times to cut off authentication problems when certaine inputs want the domain included and others don't. Most people in my experience are confused by the domain username format, not remembering where the slash goes or even what the domain name is and sometimes what the TLD is (some authentication schemes for certain products want the TLD of the domain... go figure). – Wesley Dec 24 '09 at 04:18
  • 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. – Wesley Dec 24 '09 at 04:18
  • @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). – Evan Anderson Dec 24 '09 at 04:19
  • 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 Dec 24 '09 at 04:20
  • ...are spending their time doing busywork like that. Point taken. I wish they'd let more characters go in a single comment. =) – Wesley Dec 24 '09 at 04:20
  • @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. – Evan Anderson Dec 24 '09 at 04:24
  • "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 "newUser@newdomain.local". 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 Dec 24 '09 at 04:44
  • 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 Dec 24 '09 at 04:45
  • ...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. – Wesley Dec 24 '09 at 04:45
  • "You must not have Customers who have the IP address change on their external web hosting with any frequency." Very true. If the IPs changed that frequently on external hosting, my first inclination would be to see something wrong with the external hosting more than the internal DNS. Maybe I'm wrong? BTW, sorry for the lengthy comments. And what are we doing up at nearly midnight on the night before Christmas Eve??? =) – Wesley Dec 24 '09 at 04:46
  • I agree that the UPN suffix AD Users and Computers chooses will be the domain's name (this has been covered here before: http://serverfault.com/questions/45576/set-default-upn-suffix-for-creating-new-users-in-windows-2003-active-directory). 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. – Evan Anderson Dec 24 '09 at 04:57
  • 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 ... – Evan Anderson Dec 24 '09 at 05:00
  • 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...) – Evan Anderson Dec 24 '09 at 05:02
  • 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 Dec 24 '09 at 05:09
  • 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. =) – Wesley Dec 24 '09 at 05:11
  • 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 – Evan Anderson Dec 24 '09 at 05:18
  • 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... =) – Wesley Dec 24 '09 at 05:27
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.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
1

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?

Joseph Kern
  • 9,809
  • 3
  • 31
  • 55
  • 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
0

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

Jim B
  • 23,938
  • 4
  • 35
  • 58
  • 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 04: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
0

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.

Brian Desmond
  • 870
  • 4
  • 7