Windows DNS Server

What Is Windows DNS Server?

DNS is the industry-standard protocol that maps computer names to IP addresses. In Windows Server, DNS is installed as a server role, and every Windows computer — client or server — runs a matching DNS Client service that queries it. When you build a new Active Directory forest, DNS is installed automatically alongside it, because AD has nowhere else to publish itself.

Think of DNS as an enormous, constantly updated phonebook, and Windows DNS Server as the phonebook company an organisation runs for its own staff, rather than trusting someone else’s directory. Each phonebook chapter is a zone, each entry is a resource record, and the DNS Server service is the company printing, indexing, and correcting those chapters as people join, move desks, or leave.

Windows DNS Server does not require Active Directory. It runs perfectly well as a standalone resolver hosting public lookup zones, and plenty of organisations run it that way. What changes with AD in the picture is how the zone data itself is stored and replicated — covered in Zone Types below.

How DNS Resolution Works

A DNS client normally sends a recursive query: it hands the DNS server a name and expects a final answer, success or failure, with no further work on its side. The DNS server that receives a recursive query does the legwork, issuing its own iterative queries against other servers until it has an answer or exhausts the search.

Resolving www.contoso.com from scratch might mean the local DNS server asks a root server, gets referred to the .com name servers, asks them, and gets referred again to the name servers authoritative for contoso.com — each of those being an iterative query — before it can finally answer the client’s single recursive request. A forwarder short-circuits this: if configured, the server sends unresolved queries straight to an upstream resolver instead of walking the root hierarchy itself. Root hints are only used once forwarders fail to respond.

Answers are cached along the way. Each resource record carries a Time to Live (TTL), and both the DNS server and the client’s own resolver cache honour it, serving repeat queries from memory until the TTL expires rather than re-querying every time.

Why Run Your Own DNS Server?

An organisation could point every machine at a public resolver and never run its own DNS server — except that a public resolver has never heard of corp.example.com, cannot accept dynamic updates from your clients, and cannot enforce who is allowed to update which record. Running the role internally is what makes private namespaces, dynamic registration, and Active Directory discovery possible at all.

This is the layer Active Directory is built on. Every domain join, logon, and replication cycle starts with a DNS query for a service record, and the discovery mechanics themselves — SRV records, the DC locator process, the LDAP ping — are covered in depth in AD Part 8: DNS & Active Directory. This post stays one layer down, at the DNS Server role itself.

DNS Zone Types

A zone is the unit of authority — a DNS server is authoritative for a name only if it loads the zone containing that name. Windows Server supports several zone types, and picking the right one is mostly about how the data should be replicated and updated.

Active Directory-integrated zones are the default for a reason. Because every domain controller running DNS holds a writable copy, there is no single point of failure for updates and no separate zone-transfer topology to maintain — the zone simply rides the same multi-master replication that carries the rest of the directory. It is also the only zone type that supports secure dynamic update, covered next.

Installing and Configuring DNS Server

The role installs the same way as any other Windows Server feature, through Server Manager or PowerShell, and does not require a reboot.

# Install the DNS Server role
Install-WindowsFeature -Name DNS

# Find the IP address to bind the server to
Get-NetIPAddress | fl IPAddress,InterfaceAlias

# Restrict the server to listen on one interface only
$DnsServerSettings = Get-DnsServerSetting -All
$DnsServerSettings.ListeningIpAddress = @("10.10.0.10")
Set-DnsServerSetting $DnsServerSettings

# Point unresolved queries at internal forwarders instead of the internet root
Set-DnsServerForwarder -IPAddress "10.10.0.1","10.10.0.2"

# Create a standard primary zone (file-based)
Add-DnsServerPrimaryZone -Name "corp.example.com" -ZoneFile "corp.example.com.dns"

# Create an Active Directory-integrated zone, replicated to every DC in the domain
Add-DnsServerPrimaryZone -Name "corp.example.com" -ReplicationScope "Domain"

# Add a conditional forwarder for a partner organisation's namespace
Add-DnsServerConditionalForwarderZone -Name "partner.example.com" -MasterServers 10.20.0.5,10.20.0.6

Dynamic Updates

By default, a Windows client registers its own host (A) and pointer (PTR) records the moment it gets an IP address, and refreshes them roughly every 24 hours. This is what makes DHCP-assigned addresses usable in DNS without anyone hand-editing records.

Standard file-based zones do not accept dynamic updates unless you explicitly enable them, and even then the updates are unauthenticated — any client can attempt to overwrite an existing record. Active Directory-integrated zones behave differently: once a zone becomes AD-integrated, Windows Server defaults to secure dynamic update only, negotiated over Kerberos, so only an authorised computer account can register or modify its own name.

Default TTLs vary by what registered the record: 10 minutes for records the Netlogon service registers on a domain controller, 15 minutes for records the DHCP Client service registers, and 20 minutes for records the DNS Server service registers for its own zones. These are short on purpose — a wrong record should not linger in caches for long.

Aging and Scavenging

Dynamic update adds records automatically. It has no equivalent mechanism to remove them when a computer disappears from the network without deregistering cleanly — a laptop that loses power, a decommissioned server, a VM that was simply deleted. Left alone, these become stale records: entries that answer queries with information that stopped being true.

Aging and scavenging solves this with two clocks per zone. The no-refresh interval is a window, seven days by default, during which the server ignores refresh attempts for a record it has just timestamped — this exists purely to cut down on write traffic. Once that window closes, the refresh interval begins, also seven days by default, during which the record can still be refreshed. Only after both intervals pass without a refresh does a record become eligible for scavenging.

# Enable scavenging on the DNS server, checking every 7 days
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones

# Enable aging on a specific zone with the default 7-day intervals
Set-DnsServerZoneAging -Name "corp.example.com" -Aging $true -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

# Stamp every existing record in a zone with a current, non-zero timestamp
# (needed once, after converting an existing zone to use aging)
dnscmd /ageallrecords corp.example.com /f

PowerShell & Command-Line Reference

Beyond installation and zone setup, these cover day-to-day record management, verification, and cache control.

# Add a host (A) record, with an associated PTR record created automatically
Add-DnsServerResourceRecordA -ZoneName "corp.example.com" -Name "app01" -IPv4Address "10.10.0.50" -CreatePtr

# List every zone hosted on this server and how it is stored
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated

# List every record of a given type in a zone
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType A

# Resolve a name using the client resolver (PowerShell equivalent of nslookup)
Resolve-DnsName -Name "app01.corp.example.com" -Type A

# Query a specific DNS server directly, bypassing the client's configured servers
nslookup app01.corp.example.com 10.10.0.10

# Clear the local resolver cache after a record changes
Clear-DnsClientCache

# Force this machine to re-register its own DNS records
ipconfig /registerdns

# Run the DNS-specific health checks on a domain controller
dcdiag /test:dns /DnsBasic

DNS Resource Record Types

Troubleshooting Cheat Sheet

Final Thoughts

Windows DNS Server rarely gets its own maintenance window. It sits underneath everything else, gets configured once during a domain build, and is then mostly forgotten — right up until a scavenging interval set too aggressively deletes a production record, or a forwarder goes dark and every outbound query starts timing out.

Treat the zone type, dynamic update setting, and aging configuration as deliberate decisions rather than installer defaults. They are cheap to get right up front and expensive to diagnose once records start behaving strangely across an entire domain.