Source
r/sysadmin•
lcourage

DNS issue with root domain

So our local domain has the same URL as our website (ie brotoso.com). I created A records on my DC/DNS servers that point to the public IP of our sub-domain sites (sauce.brotoso.com, etc). That seems to work fine. However, I can't add DNS records for our root domain (brotoso.com) that point to the public IP of the website as it's the root record in DNS.

So it typically won't load when typed in as brotoso.com. This is a local domain with no public access except a connection to Azure AD.

Sorry if this is a nublet question but I am a solo sysadmin with only google as my friend.

Posted Mar 12, 2019, 1:31 PM UTC

68
chuckbalesCCNP|CCDP|CCNA-V|CMNA•

AFAIK you'd need IIS on your DCs to do an HTTP redirect to www.brotoso.com. This is why it's best to use a different domain for your website and AD.

10
the_bananalord•

Most of us inherited these incorrect setups

1
xarzillaIT Manager•

It's going to resolve to your domain controller as the root. Create a www record pointing to the external IP.

Edit: forgot to mention to instruct all your users to use www.domainname.com instead of domainname.com after you create the www A record for your external IP.

7
rswwalker•

Time to split brain your DNS.

The internal zone records for Active Directory really shouldn’t be public knowledge and as you found out some public zone records don’t play well with Active Directory.

Create a stand-alone DNS server (or pair) and host a separate public version of your DNS zone.

Yes it may mean updating some records in both sometimes, but it won’t be as often as you think because you’re not publishing your server and desktop records (you shouldn’t).

3
Frothyleet•

Teach people to use www.yourdomain.com, and create the relevant A record for that. Easiest solution.

3
Ssakaa•

This is why the majority of places I've seen do some variant on "ad.contoso.com"

2
SperatiParatiSomewhere between on fire and burnt out•

If you Active Directory domain is brotoso.com, then from your internal DNS - the root of that will (and must) resolve to a list of all your domain controllers rather than your webserver.

If you need people internally to access your website as brotoso.com, you have a few options:

  • Rename your AD domain to something like ad.brotoso.com (not necessarily an easy process)

  • Rename your website domain (probably not acceptable)

  • Install IIS on each and every one of your DCs to proxy your website to internal users (not good practice to run IIS on a DC)

  • Use netsh interface portproxy to send packets for ports 80 and 443 to the web server (least worst solution)

To packet forward, you want to take a look at the documentation for "netsh interface portproxy" https://docs.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-interface-portproxy

This is why your AD domain should not be the same as your web presence.

2
pdp10WOULDN'T YOU PREFER A GOOD GAME OF CHESS?•

Install IIS on each and every one of your DCs to proxy your website to internal users (not good practice to run IIS on a DC)

Mostly agreed about best-practice. But to play devil's advocate, those DCs are serving only a simple function at low load, perhaps using them as highly-redundant caching reverse proxies for the organization's external site wouldn't be such a bad idea at all?

Of course, the best answer is that AD domains should always be a subdomain of a domain-name already within your control (e.g., ad-dom.example.gov). That's how all of the early AD domains were set up, but apparently that practice became a minority as a lot of new sites adopted AD without much previous operational experience using DNS.

1