DNS on Windows Server: The Settings That Actually Matter

Windows Server DNS has dozens of tick boxes, and most of them you will never touch. A handful, though, decide whether Active Directory replicates cleanly, whether your clients resolve internal names quickly, and whether your zones slowly fill with stale records until something odd starts happening on a Tuesday afternoon.

This guide covers the settings that actually matter in day-to-day operation, what each one really does, and the configurations that cause the most call-outs. It assumes you already have the DNS role installed on a domain controller running Windows Server 2019, 2022 or 2025.

Forwarders versus root hints

When a client asks your DNS server for something outside your own zones. Say a public website. The server has two ways to find the answer. It can walk the public DNS hierarchy itself starting from the root hints, or it can hand the query to a forwarder and let that server do the work.

Forwarders are almost always the right choice on a business network. They are faster because the forwarder has a large warm cache, they keep your recursive traffic on a predictable path out of the network, and they let you point at a filtering resolver if you use one. Root hints should be treated as the fallback, not the plan.

Add forwarders under the DNS server properties, Forwarders tab. Use two, ideally from different providers or your ISP plus a public resolver. Leave the option to use root hints if no forwarders are available ticked unless you specifically want resolution to fail closed.

Conditional forwarders. The underused one

A conditional forwarder says: any query for this specific DNS suffix goes to this specific server. It is the correct answer to almost every question that starts with “we need to resolve names in the other domain”.

Typical uses are a partner organisation you have a VPN to, a separate Active Directory forest after an acquisition, or an appliance that runs its own internal namespace. Compared to a secondary zone, a conditional forwarder needs no zone transfer permission on the other side and no replication. It just asks.

If you store the conditional forwarder in Active Directory, tick the replication option so every DNS server in the domain gets it. Otherwise you will spend an afternoon working out why resolution works from one DC and not another.

Ageing and scavenging. Enable it in both places

Dynamic records get registered by clients and, in theory, removed when they go away. In practice laptops disappear, DHCP leases churn, and zones accumulate records pointing at addresses that now belong to something else. Scavenging is the cleanup process, and it is the single most commonly half-configured feature in Windows DNS.

It has to be enabled twice. Once at the server level, which sets the scavenging period. How often the server actually goes looking. And once at the zone level, which sets the no-refresh and refresh intervals for records in that zone. Turning on only one of them achieves nothing, and there is no warning that tells you so.

The defaults, seven days no-refresh, seven days refresh. Are sensible for most networks. The important rule is that the sum of those two intervals must be shorter than your DHCP lease duration is long, or you will scavenge records for machines that are still very much alive.

Zone transfers. Lock them down

If your zones are Active Directory integrated, replication happens through AD and you do not need zone transfers at all for internal replication. The Zone Transfers tab should be set to allow transfers only to servers listed on the Name Servers tab, or disabled entirely.

Leaving transfers open to any server is a genuine information disclosure. An attacker who can pull your zone gets a map of your entire internal estate in one request. Check this on every zone, including reverse lookup zones, which are frequently forgotten.

The client-side settings on domain controllers

This is where most real DNS incidents start, and it has nothing to do with the DNS console. Each domain controller has its own network adapter settings, and what those point at determines whether the domain heals itself after a reboot or sits there in a stand-off.

The pattern that works: on a DC, set the primary DNS server to another domain controller, and set the secondary to itself. Either its own static address or 127.0.0.1. If a DC points only at itself, and it comes up before the rest of the environment, it can end up authoritative for a view of the world nobody else shares. This is the island problem, and it is easier to avoid than to unpick.

With only two DCs, cross-point them: DC1 primary is DC2, secondary is loopback. DC2 primary is DC1, secondary is loopback. With three or more, point each at the next one round the ring.

Diagnostics that actually tell you something

Skip ping for DNS troubleshooting. It resolves through the client cache and tells you very little. These are the commands worth knowing.

# What does this specific server say, bypassing the client cache?
Resolve-DnsName server01.corp.local -Server 10.0.0.10 -DnsOnly

# Is the DC registering its service records correctly?
nltest /dsgetdc:corp.local /force

# Clear the server cache after fixing a bad record
Clear-DnsServerCache -Force

# Clear the client cache on the machine you are testing from
Clear-DnsClientCache

# Show every forwarder and conditional forwarder on the box
Get-DnsServerForwarder
Get-DnsServerZone | Where-Object ZoneType -eq Forwarder

The -DnsOnly switch on Resolve-DnsName is the useful part. It skips NetBIOS and LLMNR fallbacks, so you find out what DNS genuinely returned rather than what Windows managed to work out by other means.

Four mistakes worth avoiding

• Adding a public resolver to the DC network adapter. Clients that pick it up will not resolve internal names, and domain join will fail in ways that look unrelated.
• Creating a secondary zone when a conditional forwarder would do. More moving parts, more permissions, more to go wrong.
• Enabling scavenging at the zone level only. It quietly does nothing, and you will not find out until the zone is a mess.
• Deleting a stale record without clearing the server cache. The old answer keeps being served until the TTL expires.

Glossary

Frequently asked questions

Should a domain controller point its DNS at itself?

As a secondary entry, yes. As the primary entry, no. Point the primary at another domain controller and keep itself as the backup. This avoids the island problem after a restart.

Do I need forwarders if I have root hints?

You do not strictly need them, but you almost certainly want them. Forwarders are faster, more predictable, and far less likely to be blocked by an egress firewall rule.

Why is scavenging not deleting anything?

Almost always because it is only enabled in one of the two required places. It must be turned on at the server level and on each individual zone.

Can I use a conditional forwarder and a secondary zone for the same namespace?

You can, but you should not. If both exist the local zone data wins, which makes troubleshooting confusing. Pick one.

What is a safe DHCP lease length with default scavenging?

With the default seven-day no-refresh and seven-day refresh intervals, keep leases at eight days or longer so live machines always get a chance to refresh before scavenging looks at them.

Disclosure: this post may contain affiliate links. If you buy through one of them, we may earn a small commission at no extra cost to you. We only recommend products we’ve tested or genuinely rate.