Windows Server DNS: Zones, Records, and Configuration Guide

Windows Server DNS is the name-resolution layer Active Directory relies on for DC locator, Kerberos service discovery, Group Policy processing, and domain join. A DNS outage can break new lookups and authentication workflows immediately, while cached records, existing Kerberos tickets, and established sessions may keep some activity working temporarily. This guide covers what the DNS Server role actually manages: zone types, record types, and the configuration decisions that are hard to walk back once production traffic depends on them.

What the DNS Server role actually does

Windows Server DNS resolves names to IP addresses (and the reverse) for anything that needs to find anything else on the network – domain controllers locating each other, clients finding a DC to authenticate against, mail servers routing by MX record, internal apps resolving each other by hostname. On a domain-joined network, DNS isn’t optional infrastructure – it’s the lookup layer AD’s own protocols (Kerberos, LDAP, Netlogon) depend on to function.

The AD DS Configuration Wizard selects the DNS Server option by default when creating a new forest or domain, and it commonly remains selected when additional domain controllers are promoted – which is why most Windows Server DNS deployments are also domain controllers. That’s a common pattern, not a universal rule: in supported scenarios an administrator can deselect it, and DNS can run as a standalone role on a member server or workgroup box. An AD-integrated zone, though, can only be hosted by the DNS Server service running on a domain controller.

Forward versus reverse lookup zones

Forward zones resolve hostnames to IP addresses (server01.contoso.com → 10.0.0.5) – this is what most people mean by “DNS.” Reverse zones do the opposite, IP to hostname, and live in a separate zone object under the in-addr.arpa (IPv4) or ip6.arpa (IPv6) namespace.

Creating a forward zone doesn’t create the matching reverse zone automatically – it’s a second, deliberate step. Skipping it is a common oversight when provisioning a new subnet, and some applications and security tools fail closed without a working PTR lookup.

Zone roles and storage models

Windows DNS separates a zone’s role from how its data is stored. A primary zone can be file-backed or stored in Active Directory. Stub zones can also be file-backed or AD-integrated. Secondary zones remain read-only copies obtained through zone transfer.

Primary – the writable role for a zone. AD-integrated primary zones store data in AD DS and replicate via AD replication (multi-master: any writable DC hosting the zone can accept updates). File-backed primary zones store data in a local .dns file and replicate to secondaries via zone transfer instead.

Secondary – always a read-only copy, pulled from one or more primary servers via AXFR/IXFR zone transfer. Useful for load distribution and for authoritative DNS on segments where a writable copy isn’t wanted. Full zone transfer troubleshooting: DNS Zone Transfers on Windows Server.

Stub – contains the SOA, NS, and required glue address records needed to identify the authoritative DNS servers for another zone, not the full record set. It can be file-backed or AD-integrated and refreshes its data from configured master servers. Stub zones are commonly used to support resolution between separate DNS namespaces or to maintain an automatically updated list of authoritative servers for another zone.

AD-integration is a storage and replication choice, not a fourth zone type sitting alongside the other three. For domain zones in an AD environment, it’s the right default: multi-master means no single DC’s downtime blocks writes, and replication piggybacks on AD’s existing Kerberos-authenticated, encrypted transport. Microsoft’s AD-integrated DNS zones documentation covers the storage and replication model in full.

Zone form	Storage	Replication / update method	Best fit
AD-integrated primary	AD DS	AD replication, multi-master writes	AD domain zones and internal writable zones hosted on DCs
File-backed primary	.dns file	Single writable primary; zone transfer to secondaries	Non-AD environments and transfer-based integrations
Secondary	Local read-only zone file	AXFR/IXFR from one or more primary servers	Read-only authoritative copy and transfer-based redundancy
Stub (file-backed or AD-integrated)	File or AD DS	Refreshes SOA, NS, and glue data from master servers	Maintaining authoritative-server awareness for another namespace

On a DC that’s a Read-Only Domain Controller, the picture changes slightly: an RODC holds a read-only copy of the zone, and updates are handled through a writable DNS server/DC per normal Windows RODC replication behavior, not written locally.

Zone delegation, briefly

A parent zone delegates a child namespace to a different set of name servers using NS records – and, when the child’s name servers live inside the parent’s own namespace, glue (A/AAAA) records so resolvers can find them without a circular lookup. A stub zone is related to delegation but serves a different purpose: it gives the DNS server hosting the stub an automatically refreshed list of authoritative servers for another zone. It does not create the delegation itself and is not limited to the parent DNS server.

Replication scope versus resolution path

Replication scope controls which DNS servers on domain controllers host an authoritative copy of an AD-integrated zone – domain-wide (the default, DomainDnsZones), forest-wide (ForestDnsZones), or a custom application directory partition you define, where the enrolled servers determine who gets the data.

That’s a separate question from whether other domains can resolve the zone. A domain-scoped zone isn’t hosted by DNS servers in other domains, but those servers can still resolve it when a valid delegation, conditional forwarder, stub zone, or ordinary recursion path exists. Use forest-wide scope when DNS servers across multiple domains genuinely need to host the zone directly – not simply because clients in those domains need to resolve records in it.

Full breakdown of scope selection and the DomainDnsZones/ForestDnsZones partition model: Windows Server DNS Replication Scope.

Record types that matter in production

Not every record type shows up daily. These are the ones that actually drive troubleshooting tickets and design decisions – Microsoft’s DNS resource-record documentation covers record creation, management, and the common record types supported by Windows Server.

Record	Purpose	Where it commonly bites people
A / AAAA	Hostname to IPv4/IPv6 address	Stale entries after a server’s IP changes without re-registration
CNAME	Alias to another hostname	Chained CNAMEs slow resolution and complicate troubleshooting; avoid pointing a CNAME at another CNAME
SRV	Service location (protocol, port, host) – critical for AD: _ldap._tcp, _kerberos._tcp	Missing or wrong SRV records break DC locator; usually an AD/Netlogon registration issue, not a manual DNS edit
PTR	Reverse lookup: IP to hostname	Reverse zones are easy to forget when provisioning new subnets – some apps and security tools fail closed without working PTR
MX	Mail routing priority and target host	Priority values misordered, or the target host has no valid address record (A and/or AAAA)
NS	Authoritative name servers for a zone	Stale NS records after decommissioning a DNS server
SOA	Zone metadata: serial number, refresh/retry/expire timers, primary server	Windows DNS normally manages serial increments automatically; a stuck serial is an edge case, more likely when a third-party secondary transfers from multiple AD-integrated servers with different local serial state
TXT	Arbitrary text – commonly SPF, DKIM, domain verification	Multiple SPF records instead of one merged record breaks mail authentication

Why operators get this wrong: SRV and PTR records are the two types people manually “fix” most often, and both are usually symptoms of something upstream – SRV of a Netlogon registration failure, PTR of a missing reverse zone – not something to hand-edit unless the actual root cause is already confirmed.

Configuring a new zone

The decisions that matter happen at zone creation, not afterward – some of them, namespace in particular, are expensive to change later.

1. Choose the zone role and storage. AD-integrated primary for any domain zone in an AD environment; file-backed primary when there’s a specific reason to avoid AD dependency – non-AD environments, transfer-based integrations, isolated namespaces where storing the zone in AD DS is inappropriate. For public authoritative DNS, many organizations use a managed external DNS provider rather than exposing internal Windows DNS infrastructure directly.
2. Set the replication scope. Domain scope (default) is right for most single-domain deployments. Forest scope matters only when DNS servers in other domains need to host the zone directly, not just resolve it.
3. Configure dynamic updates deliberately. “Secure only” requires authenticated dynamic updates and enforces the ACLs on the zone and individual records – authorized clients, DHCP servers, or delegated service accounts can create or update records according to those permissions. “Nonsecure and secure” additionally accepts unauthenticated updates, substantially increasing spoofing and record-hijacking risk, and should be limited to a documented compatibility requirement, not a default. Microsoft’s dynamic update documentation covers the full permission model.
4. Set up the matching reverse lookup zone if PTR resolution matters for this subnet – it’s a separate zone object and doesn’t get created automatically alongside the forward zone.
5. Leave aging and scavenging off until there’s a deliberate plan for it. Default state is off; turning it on requires understanding which records are dynamically registered (normally eligible for aging) versus manually created (normally timestamp zero, excluded unless aging is explicitly turned on for them). Microsoft’s DNS aging and scavenging documentation covers the timestamp and refresh-interval mechanics in full. See DNS Scavenging on Windows Server before enabling it anywhere with legacy static entries.

Creating a zone and record: a compact example

GUI path: DNS Manager → Forward Lookup Zones → New Zone → Primary zone → Store the zone in Active Directory → select replication scope → Secure only.

Equivalent PowerShell, creating an AD-integrated forward zone, its matching reverse zone, and one A record with an automatic PTR:

Verifying DNS server health

A few PowerShell checks confirm the server is actually functioning the way its configuration implies, rather than assuming the GUI reflects reality:

A direct query against the forwarder’s IP only proves that the upstream resolver answers the test host. Query the Windows DNS server that clients actually use to confirm client-facing external resolution. That result still doesn’t prove whether the answer came through the configured forwarder or through root-hints fallback – use packet capture, DNS analytical/debug logging, or a controlled test with fallback disabled when the actual upstream path must be verified.

Security basics

DNS is a common target because it’s foundational and often under-hardened relative to its blast radius. A few defaults worth confirming rather than assuming:

• Static zones should use “Do not allow dynamic updates,” not Secure only. Secure only is the right default for zones that need to accept registrations – it’s not a blanket setting to apply everywhere regardless of whether the zone actually needs dynamic registration.
• Disable zone transfers where no secondary server or integration requires them. Where transfers are required, restrict them to explicitly approved secondary-server IP addresses – an unrestricted AXFR can expose the full contents of that zone, including internal hostnames and addresses useful for network reconnaissance.
• DNSSEC is available for zone signing but adds real operational overhead (key rollover, resolver compatibility) – most SMB and homelab environments don’t need it; it matters more for externally-facing zones with a specific threat model.
• Cache locking defaults to 100 percent and normally doesn’t need adjustment. Response Rate Limiting is available on supported Windows Server versions but is not simply “on by default” the way cache locking is – verify its current mode and thresholds explicitly rather than assuming, especially on an internet-facing authoritative server:

FAQ

What’s the difference between a forward lookup zone and a reverse lookup zone?

Forward zones resolve hostnames to IP addresses. Reverse zones do the opposite – IP to hostname – and live in a separate zone object under the in-addr.arpa or ip6.arpa namespace. Creating a forward zone doesn’t create the matching reverse zone automatically; if PTR lookups matter for a subnet, that’s a second, deliberate step.

Should every zone be AD-integrated?

No. AD integration is most common for AD domain zones, but it isn’t limited to namespaces that match an AD domain. Any primary zone hosted by the DNS Server service on a domain controller can be stored in AD DS when multi-master AD replication is the desired model. Use file-backed primary, secondary, or stub zones when AD DS is unavailable, when the zone must be hosted on a member or workgroup server, or when a transfer-based design is required.

Why does a new record I added manually keep disappearing?

Manually created records normally have timestamp zero and are not eligible for scavenging. A manual record can be removed if it was created with aging enabled, if “Delete this record when it becomes stale” was selected, if PowerShell was used with an aging option such as -AgeRecord, or if a later dynamic update replaced it with an aging-enabled record. Check both Get-DnsServerScavenging for the server-level state and Get-DnsServerZoneAging for the specific zone before assuming the record was static.

What’s the difference between a stub zone and a conditional forwarder?

Both point queries for a specific namespace elsewhere, but a stub zone stores the target zone’s NS/SOA/glue records locally and refreshes them automatically as the target zone’s authoritative servers change. A conditional forwarder is just a static list of IPs to query for a given namespace, with no awareness of whether those IPs are still correct. Stub zones self-maintain; conditional forwarders don’t. Full comparison: Windows Server DNS Forwarders.

Can I run DNS on a member server instead of a domain controller?

Yes, for file-backed zones. AD-integrated zones specifically require the hosting server to be a domain controller, since the zone data lives in the AD database. A member server can host file-backed primary, secondary, or stub zones as part of a deliberate transfer-based design. In many AD environments DNS stays colocated with domain controllers regardless; larger organizations sometimes use dedicated DNS appliances or managed platforms instead.

How do I tell if a DNS problem is server-side or client-side?

Querying a specific DNS server narrows the fault domain but doesn’t make the result purely server-side or client-side. If a direct query with Resolve-DnsName -Server fails, test UDP and TCP 53 reachability and repeat the query from the DNS server itself – network path, firewall, and VPN/ACL issues between the test host and the server are still on the table. If the server answers directly but normal client resolution still fails, investigate the client’s configured DNS servers, suffix search list, NRPT/VPN policy, cache, and network path. Full triage workflow: Windows Server DNS Troubleshooting.

What Windows Server version is this guide based on?

The core zone, record, AD-integration, and dynamic-update concepts apply to Windows Server 2019, 2022, and 2025. Version-specific defaults and PowerShell behavior – like the exact Response Rate Limiting configuration – should be verified against the Microsoft Learn documentation for the deployed release rather than assumed from this guide alone.

Final thoughts

Many recurring Windows Server DNS problems trace back to three decisions made at zone creation and rarely revisited: replication scope, dynamic update security, and whether scavenging is even supposed to be on. None of these are hard to get right up front. All three are considerably more work to fix after months of production traffic and a namespace full of records nobody’s sure are safe to touch.

The zones and records covered here are the foundation the rest of the DNS cluster builds on – forwarders, replication scope, scavenging, and troubleshooting each get their own deeper treatment linked throughout this guide.