1

The MSP for a law firm office that has just joined our company is using a FQDN as an internal AD Domain and has been doing so for sometime apparently. They have this issue in that they have a website of the same FQDN which is hosted offsite, so when they try to browse http://theirdomain.com they get the IIS7 page of their DC rather than the website which we (outside of their local network) see. http://www.theirdomain.com works fine internally because they have a forward lookup on their DC, but I've asked them to do the same for the hostless A record of the website and the MSP said that would need to be researched first and might have to be dealt with as a project because of the implications on the local domain and RDS environment. Is this the case? Isn't all AD domain lookups done via UNC and IP rather than DNS lookups?

Reece
  • 783
  • 2
  • 12
  • 30
  • What did they use as the AD domain name? – Michael Hampton Mar 10 '16 at 02:04
  • same as the website: "theirdomain.com" with dc-server, rds1 and rds2 as the servers. – Reece Mar 10 '16 at 02:11
  • 1
    OK, yes, it's going to be a very large project. But whoever chose the AD domain name to begin with is at fault. If it was the MSP they should eat the cost. – Michael Hampton Mar 10 '16 at 02:13
  • 1
    `1.` Why do they have IIS installed on the Domain Controller? `2.` There isn't anything you can do, short of renaming the domain. – joeqwerty Mar 10 '16 at 02:13
  • to answer #1... It might be SBS2011 as they also have on-prem exchange 2010. I haven't yet been given access to any of their servers so can't confirm this. #2... what about putting a .301 redirect in the DC's IIS7 config to forward it through to www.theirdomain.com? Or will this break client PC AD-domain lookups too? – Reece Mar 10 '16 at 02:15

1 Answers1

5

This won't work. Domain Controllers register A records for the AD DS Domain that they are authoritative for. This is why domain naming is so important.

So if your DCs are 10.1.1.1 and 10.1.1.2 and your domain is company.com, the internal AD-integrated company.com zone will have A records at the apex of the zone for 10.1.1.1 and 10.1.1.2.

As an aside, you should be concerned that IIS in installed on your DCs. That's generally not good.

Community
  • 1
MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • Perfect! Is there a way around it? like modifying the DC/DNS server's hosts file or a different type of forward lookup? – Reece Mar 10 '16 at 02:13
  • Short of capturing that web request on your DCs and forwarding it to the web server (not recommended at all) or renaming your domain (major undertaking) no. People that are in this situation generally just live with it. – MDMarra Mar 10 '16 at 02:15
  • ie. Train the staff to add a www. if they get the IIS7 page when they try to access their website? haha, LOL! – Reece Mar 10 '16 at 02:16
  • @MDMarra: So here's a question; the A records for the DC's at the apex exist to assist non-SRV aware clients in locating a DC. SRV aware clients (Windows clients joined to the domain) use SRV records to locate a DC, so they don't use the DC A records at the apex. If the OP were to create an A record at the apex for the non-WWW website what potential issues could there be other than causing problems for non-SRV aware clients? I honestly don't know so I'm wondering what insight you have. – joeqwerty Mar 10 '16 at 02:18
  • Well, you'd have to delete the other records first, and then stop *just those records* from registering dynamically (yes, they're part of the dynamic registration process of a DC). So assuming you could do that, I really don't know what it would disrupt. I suppose anything doing a DNS lookup against the root of the domain. If you simply add the extra A record without removing the others, it will get served up round-robin with the others. It's a good question but I think the answer about what will break is really "it depends on what's in the environment" – MDMarra Mar 10 '16 at 02:21
  • Right, you could configure the DC's to not register those A records by editing them out of the netlogon.dns file, but who knows what unforeseen things may break. – joeqwerty Mar 10 '16 at 21:04