11

Related to this previous question of mine about why it's a bad idea to use the root domain name as your Active Directory forest's name...

I have an employer, whom I will refer to as ITcluelessinc, for the purposes of simplicity (and honesty). This employer has an externally hosted website, www.ITcluelessinc.com, and a few Active Directory domains. Being clueless about IT, many years ago, they set themselves up on an Active Directory forest named ITcluelessinc.prv, and performed unspeakable atrocities against it. These unspeakable atrocities eventually caught up with them, and with everything collapsing around them, they decided to pay someone a huge chunk of money to "fix it ," which included migrating off the horribly broken ITcluelessinc.prv forest.

And of course, being clueless about IT, they didn't know good advice when they heard it, accepted the recommendation to name their new AD forest ITcluelessinc.com, instead of the sane advice they also got, and started putting stuff on it. Fast forward to a few hours ago, and we have a company with most of its stuff joined to and using the old ITcluelessinc.prv Active Directory forest, with a fair amount of newer stuff joined to and/or using the ITcluelessinc.com forest. To make this work together relatively seamlessly, I've used conditional forwarders in DNS to send the ITcluelessinc.com traffic over to ITcluelessinc.prv, and vice-versa.

enter image description here

(The corp.ITcluelessinc.com and eval.ITcluelessinc.com domains are properly named domains I came in and set up later, and are not relevant just yet.)

Back to a few hours ago, and a non-technical employee of ITcluelessinc has noticed that she can't browse to www.ITcluelessinc.com from her workstation (inside the ITcluelessinc corporate network) and decided that this is a problem, so she contacts VIP employee of ITcluelessinc, who decides this must be resolved most Ricky-tick. Typically, not a huge deal, add an A record for www under the DNS zone for ITcluelessinc.com, and you can browse the site, so long as you don't try the naked link.

enter image description here

So, it seems like it's all setup properly. Forwarders, www host entry in DNS, and yet, clients using the ITcluelessinc.prv domain controller as DNS servers get a connection timeout when trying to browse to www.ITcluelessinc.com, instead of the webpage that I get from my home network.

Does anyone have any thoughts as to how I can allow internal clients of the ITcluelessinc.prv domain to browse www.ITcluelessinc.com, given the presence of the ITcluelessinc.com Active Directory forest and the conditional forwarders it needs? Or, alternately, is anyone [else] convinced that the only way to make it work is to get rid of the ITcluelessinc.com Active Directory forest?

It does seem like the setup I have now should work, but it's clearly not, and I have no idea where I'd procure a testing environment this messed up to experiment with. And for what it's worth, I've somewhat politely suggested that the only way to fix this is migrate to the properly-named forests I set up, and when that's not a good enough answer, plan to host a mirror of the website on all our ITcluelessinc.com domain controllers until that breaks everything.

Community
  • 1
HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • 1
    That should work - it mirrors the setup I had at an old job (such a bad domain to use for your forest, you have my sympathy), minus the two namespaces and forwarders. Are the client systems getting an NXDomain DNS response trying to resolve the `www` name, or are they getting an incorrect address? Or, alternately, are they getting the right address but not able to connect to that address (is the website hosted on servers inside the network, causing a hairpin NAT problem)? – Shane Madden Nov 25 '14 at 20:03
  • 1
    @ShaneMadden: My thoughts exactly and discussed in a private conversation. It should work, but doesn't, and I'm clueless as to why not. The only other thing I would suggest at this point would be to fire up a packet capture on a .prv client and see what's happening when they try to browse for www. – joeqwerty Nov 25 '14 at 20:08
  • @ShaneMadden They do seem to get the right address with an nslookup, and there **shouldn't** be any hairpin NAT involved, as the website is externally hosted. (Client -> .prv DC -> .com DC -> firewall -> interwebs). I've seen this work before when the machines on the rootdnsname domain were trying to access the rootdnsname, but have yet to see clients joined to a different domain that need to access rootdnsname and rootdnsname website. ... So that's kind of what I'm thinking the problem must be. – HopelessN00b Nov 25 '14 at 20:21
  • 1
    I agree with Evan. Halfway related, and having worked for another company who has engaged in split brain nonsense, one trick worth mentioning is that you can get your public facing DNS servers to control a record (or subdomain) by inserting `NS` records. Provided that the firewall permits communication from the DCs to the externally facing DNS server, this alleviates the nightmare somewhat and the public facing records can be managed on the public facing server. – Andrew B Nov 25 '14 at 23:02
  • @AndrewB True story, ITcluelessinc has outsourced its DNS to an external vendor, but doesn't know which one, and can't figure it out, hence no NS tricks on the external nameservers. But I'll keep that in mind for $next_job, thanks. – HopelessN00b Nov 25 '14 at 23:07
  • @HopelessN00b My eyes are bleeding. Between a [trace](http://www.digwebinterface.com/?hostnames=ITcluelessinc.com&type=&trace=on&ns=resolver&useresolver=8.8.8.8&nameservers=) and WHOIS you probably know who to annoy already, but there it is anyway. – Andrew B Nov 25 '14 at 23:12

1 Answers1

8

If the clients are resolving the hostname properly then you've got another problem. DNS is out of the picture once the hostname is resolved by the client.

Some things to think about:

  • Are clients using any kind of HTTP proxy to access the Internet? Does the proxy have the correct DNS information available?

  • What's the DNS cache look like on the client after a failed access attempt? Are you seeing the right IP address cached for the hostname?

  • What's actually happening on the client? Are you seeing a connection stuck in SYN_SENT state to the correct server IP address, TCP port 80?

  • Are there any firewall rules that might relate to blocking access to the website's address?

This smells like a firewall / proxy / cache / filter problem, not a DNS problem.

Unfortunately, there's nothing really compelling I can say about getting rid of the badly-named Active Directory domain. It's unfortunate that they chose to do that route, but technically this can work. (I hate this kind of bad naming practice, too... "vile", I believe, is how I've referred to it in the past... Wish I had some good advice to forward a domain-rename argument to you...)

Community
  • 1
Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • 1
    `If the clients are resolving the hostname properly then you've got another problem.` Dammit. If that's the case, it's probably our asstastic webproxy. I was much happier when I thought it might not be technically resolvable, and they'd have to finally fix their $#@^%ing mess already. :( – HopelessN00b Nov 25 '14 at 20:36
  • 2
    Test with a server or internal computer that bypasses any webproxy, etc. and test again. Like Evan and Shane said, it's definitely doable with a www record. What isn't doable is just a default record like itcluessinc.com resolving to the website in this instance. – TheCleaner Nov 25 '14 at 20:54
  • Yeah, so guess what happens when IT doesn't manage the websites and the department that does decides to change hosting companies? That's right, the old `www` A record doesn't work, the sysadmin gets pissed off and aggravates his cirrhosis. – HopelessN00b Dec 08 '14 at 20:25