AD Domain with matching TLD FQDN, forwarding DNS requests

TechnoNewbie

12/28/23, 4:30 PM

I have the following scenario:

A brand new ADDS domain from a single PDC+DNS.
The FQDN of the domain matches our public website name (webname.com).
The gateway dictates the PDC/DNS as the first DNS resolver. The secondary DNS is a public entity like 8.8.8.8 from both gateway and the PDC.

With this we get errors navigating to our website tld.com. This makes sense because the PDC has a forward lookup zone for webname.com and custom A records, etc.

The problem: DNS records like our MX record will not resolve on the internal network now unless created in the PDC/DNS entries. If we do not declare the PDC as the first DNS resolver we have trouble joining domain and resolving hostnames internally.

I could manually clone all the records in place and maintain two copies, but is there a better way? I still need the local PDC/DNS to handle DNS internally for FQDN device names (device.webname.com) but I want all other DNS requests to head out to the web otherwise so that public DNS record changes are recognized internally without manual duplication. Is there an elegant way to do this?

I tried adding secondary name servers on the PDC to point at the public DNS NS but that didn't seem to make any difference. Testing using nslookup from inside the network shows me that I'm not touching the external NS still when looking for an MX record for example.

Thank you.

269

1 + 2

domain-name-system

active-directory

internal-dns

vidarlo

12/28/23, 4:45 PM

Have you reconsidered renaming one of the resources?

Greg Askew

12/28/23, 5:12 PM

Agree with @vidarlo, since this is "brand new" create a domain with the correct naming structure xx.domain.com. Also you should never use external DNS internally as a secondary or tertiary DNS, that is a DNS worst practice.

Score:4

Server

Esa Jokinen

12/28/23, 4:46 PM

Because you have...

A brand new ADDS domain from a single PDC+DNS.

...there indeed is a better way. It is not too late to change the AD domain name to meet the Best Practices for Internal Domain and Network Names. Do not use your external example.com for your AD domain, but use a subdomain like ad.example.com, instead.

The short answer, as best practice:

Microsoft strongly recommends that you register a public domain and use subdomains for the internal DNS.

So, register a public DNS name, so you own it. Then create subdomains for internal use (like corp.example.org, dmz.example.org, extranet.example.org) and make sure you've got your DNS configuration setup correctly.

The article also lists the disadvantages from using a single namespace (for internal and external hosts).

We also have a canonical question for Windows Active Directory naming best practices.

+ 1

TechnoNewbie

12/29/23, 3:41 PM

Thank you. I will amend the error of my ways.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: AD Domain with matching TLD FQDN, forwarding DNS requests

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.