1

It’s DNS. It’s always DNS. No, DNS is fine, it’s not DNS, trust me.
It was DNS. :slight_smile:

I’m posting because in the last few weeks we’ve had a few posts that turned out to be misconfigurations with DNS in a domain environment. Things like Domain controllers pointing at themself first for DNS, or having a public DNS server on the NIC of the Domain Controller or the clients. Hopefully this will help some people get out in front of potential issues.

The general rules for DNS in an AD Environment.

When you have more than 1 Domain controller (DC)

The NIC on the DC should point to another DC first, and itself (127.0.0.1) last. For many people it points to itself as secondary, but it may also be tertiary or quarternary. It just should not be primary.

In a multi site deployment, it’s common to see
Primary: Another DC in the same site
Secondary: Another DC in a different site
Tertiary: 127.0.0.1

There should never be a public DNS server such as 8.8.8.8, 4.2.2.2, etc. on the NIC of the DC. The only place public DNS gets defined is on the forwarders tab of the DNS server properties in the DNS management console.

Domain clients should only point to Domain Controllers for their DNS. The same warning applies here as well. A public DNS server such as 8.8.8.8 should not be used on domain joined system.

What happens if you have DNS on the NIC of a DC pointing to itself first and another DC second? That DC will eventually hiccup and stop replicating.

What happens if you have a public DNS on the NIC of your DC? Replication will break. If your DC tries to query 8.8.8.8 (or other public DNS) to locate your other DC, 8.8.8.8 has no idea what it is talking about. The DNS lookup will fail and the DC will not be able to replicate.

What happens if you have public DNS on the NIC of your domain member computer/server? That machine also runs the risk of asking public DNS how to find your DC and a public DNS server is not going to have an answer. End result? Login failures. This occurs even if you list your DC as primary and a public DNS as secondary. I see this far too often: “I want a backup just in case my DCs are down”. No, you don’t. You will have problems all of the time. If you are concerned about your DCs being down, then you don’t have enough DCs. Address the problem that way.

If you’re having authentication issues or replication issues, take a look at your DNS settings first because that’s a very likely candidate. You might save yourself a lot of troubleshooting time.

25 Spice ups
2

Something to note, for those who do not know.

Windows used to first try to use the primary DNS server, but if for some reason it cannot and falls back to the secondary, it will remain operational with the secondary until the NIC is reset or a reboot takes place (including ipconfig /flushdns).

NOTE Since Windows 10, all DNS servers are queried at once, so there is a good chance, the primary is not your primary. (Hence why having 8.8.8.8 is a bad idea, once the client is locked to a DNS server, it wont ask another until one of the above takes place to reset it - in this example, using a public DNS server will not find any internal services).

DNS does not ‘fall back’ to the primary when it is available, it stays with the last one that answered as it’s confirmed working.

10 Spice ups
3

Windows Server 2016, 2019, and 2022 should exhibit the same behavior.

6 Spice ups
4

How do we sticky this post?

Well done Patrick. This is the answer to 3 threads a week.

2 Spice ups
5

That’s why I posted it. I was writing out those instructions more or less to several people in posts in the last 2 weeks, and I thought it would be good to post it. Now I can just reference that post in the future :slight_smile:

3 Spice ups
6

Co-Pilot and I just had a discussion about this.

image
image918×100 4.92 KB

image
image907×547 24.3 KB

Even AI can learn a thing or two.

3 Spice ups
7

Co-Pilot is very good at putting things in perspective at times, it’s even linked me to posts where the reply has been my own to someone else.

4 Spice ups
8

Sorry for reviving an old thread, but this piqued my interest.

If Windows queries all DNS servers at the same time, why does it matter whether I make the DC its own primary DNS, or have it somewhere else in the list? Doesn’t that mean that I should not have the DC anywhere in its own DNS server list?

P.S. I came here from another thread where you were explaining to someone that they were being unwise in their DNS configuration on the DC. Thanks for linking to this thread.

9

No worries. Your logic is sound but unfortunately reality does not reflect it when it comes to domain controllers, especially older ones. Having managed an environment of over 1K DCs, I can tell you that any time I had replication issues with a DC it’s because someone misconfigured it with it pointing to itself first, and it was always rectified by pointing to another first, and 127.0.0.1 second. There were no cases of this ever happening the other way around.

Is it possible if you had a domain of all Server 2022, that it will work fine either way since it queries all DCs? Maybe, but I have no way of testing this as I don’t have a large domain with intentionally misconfigured DCs. Until proven otherwise, the old rule holds.

“Doesn’t that mean that I should not have the DC anywhere in its own DNS server list?”

Not sure how you came to that conclusion however. It has to be in it’s own server list in case it loses contact with the other DCs. For example you have a DC on either side of a WAN link and your WAN goes down, it would be unable to resolve anything.

1 Spice up
10

That makes sense. Stick with what has worked.

As for the last bit, I will try to explain my thinking. Rod stated that “once the client is locked to a DNS server, it wont ask another until one of the above takes place to reset it”. I think what is being said here is that the first respondent with a valid answer will be used going forward. Since the local DNS should always be the first respondent when multiple are asked at the same time, the DC should (except in rare cases) end up with itself as its primary. At that point we end up back at the situation of classically having your DC as its own primary DNS. The only time that situation would logically change is if the DNS Server on the DC fails without taking down the rest of the services on the DC, so that when it queries its own DNS server it gets a failure.

It is entirely probable I am misunderstanding some or all of how this works. That is just an explanation of how I got to my conclusion.

11

My post was generalized, DCs are the exception.

If all DNS servers on a DC queried all at the same time, it would be possible it gets mixed results, however, given that the DC is the DNS, the primary DNS server is always another DC - this is necessary for accurate replication, otherwise the DC would only ever rely on cached records. (querying itself).

Correct

Negative, unless you only have a single DC, the DC should point to another DC for it’s primary DNS and 127.0.0.1 as secondary, in my point above DCs are an exception otherwise they would only ever look at local records, which would break replication.
Because you set a primary DNS on a DC, it is then forced to replicate with that DC and use it for confirmation. Local loopback is used to retrieve cached data when the primary isn’t available in the case of a DC.

I see where the confusion comes from, but the post was about devices outside of a DC and not inclusive to them.

12

Very helpful discussion. Thank you both for your replies.

Additionally, I found this page of MS documentation that goes through the best practices for DNS on DCs. I found it very helpful.

13

From that article:

After you’ve verified that replication has completed successfully, DNS may be configured on each Domain Controller in either of two ways, depending on the requirements of the environment. The configuration options are:

Configure the Preferred DNS server in TCP/IP properties on each Domain Controller to use itself as Primary DNS Server.
    Advantages: Ensures that DNS queries originating from the Domain Controller will be resolved locally if possible. Will minimize impact of Domain Controller's DNS queries on the network.
    Disadvantages: Dependent on Active Directory replication to ensure that DNS zone is up to date. Lengthy replication failures may result in an incomplete set of entries in the zone.

And those disadvantages lead to Domain Controllers becoming orphans unable to replicate until they finally become tombstoned, which is why we don’t do that. You learn a few things when you have quadruple digit locations over slow wan links.

I have intense dislike for that article and I wish the person who wrote it actually maintained AD over multiple locations for over a decade.

1 Spice up
14

I just checked and both my DC’s were pointing to themselves for Primary DNS Server. :scream: I am sure because of the Microsoft article. I guess I should count myself lucky I haven’t had any major problems. I’m fixing it right now. Thank you for educating everyone.

1 Spice up
15

You’re welcome. I have not personally experienced it but it can also cause issues when NLA starts before the DNS server and causes the zone to get flipped on the nic. This words up causing issues because the wrong firewall profile becomes active. Pointing at another DNzs server first avoids this. Otherwise you have to restart NLA.

3 Spice ups
16

Excellent discussion, and I agree with it.

However, there is ONE exception to using a non-AD DNS server on domain clients:

When you have only one domain controller and you have an enterprise-grade firewall, you can configure that firewall to act as a DNS resolver where it forwards queries for your local AD domain to the AD DNS server (and queries for Internet hosts to Internet name servers). Specify the address of the firewall as a secondary DNS server for the AD members. You might want this functionality in the event your DC goes down, you’ll still be able to resolve Internet hosts. This can be important for some remote machine management (e.g., TeamViewer, SplashTop, etc.) so that you can troubleshoot issues remotely.

Another alternative, if you have a single domain controller, is to add the DNS service to another domain member server, as a replicated secondary DNS server that receives changes in a primary-secondary relationship from the domain controller. Then this other server can be a secondary DNS server for the domain clients.

HOWEVER, never specify a non-AD DNS server in the network interface configuration of a domain controller, even if the domain controller is the only one in the domain! Doing so can cause problems on startup, such as setting the DC’s network profile to “public” instead of “domain”. In the even you have only a single domain controller, you should have only 127.0.0.1 listed in the DC’s network interface DNS configuration. In order for the DC to configure itself properly on startup, it needs to either receive a valid reply to DNS queries or no reply at all; if it receives an NXDOMAIN (which it will by querying any non-DC server) it will throw the configuration off.

1 Spice up
17

Those possibilities seem somewhat contradictory to me. If you’re spending money on an enterprise grade firewall, and you need an enterprise grade firewall you likely know you should have and can afford to have a second DC. But this is IT, and we’ve seen it all, until we see something new, and it wouldn’t shock me to see that setup somewhere.

1 Spice up