DNS design

Design reference

Part II — Design Reference: DNS for Windows / Active Directory Enterprise Environments (as of October 2026)

The authorities agree on a common DNS baseline for Active Directory, and they disagree in a few specific places. The baseline: name the forest under a domain you have registered. Use AD- integrated zones that accept only secure dynamic updates. Run DNS as at least two fault- tolerant servers that keep internal and external roles apart. Send all outbound resolution through an authorized, policy-enforcing (Protective DNS) forwarder, and block every other path to the internet. Turn off LLMNR, NetBIOS name resolution and mDNS. Log DNS centrally on synchronized time. The authorities disagree on DNSSEC for internal zones, on NSEC versus NSEC3, on whether DNS should run on domain controllers or on dedicated servers, and on how to build split-brain DNS. NIST SP 800-81r3 (March 2026) and the DISA Windows DNS STIG are the two government documents that most often pull in opposite directions.

TL;DR

• Baseline: Name the forest as a subdomain of a domain you have registered, or use ICANN’s reserved .internal. Never use .local or single-label names. Store zones in AD with “Secure only” updates. Run at least two DNS servers on different network segments. Resolvers should forward only to an approved Protective DNS service, outbound port-53, DoT and DoH should be blocked for everything else, and recursion should be off on any authoritative server that faces the internet. Disable LLMNR, NetBIOS and mDNS. Send DNS analytic and audit logs to a SIEM on synchronized time.
• Integrity and confidentiality: NIST SP 800-81r3 recommends DNSSEC for zones that face the internet. It advises against signing internal zones unless a policy requires it, and it prefers NSEC to NSEC3. The DISA STIG requires DNSSEC records, NSEC3 for all internal zones, and client validation enforced through the NRPT. Signing with SHA-1 is now prohibited (RFC 9905, November 2025); use ECDSA P-256/P-384 or RSA/SHA-256 with keys of 2048 bits or more. Windows Server 2025 DNS has supported client-facing DoH since the June 2026 security update, but traffic to forwarders, zone transfers and dynamic updates is still unencrypted.
• Where authorities conflict: NIST says DNS should run on dedicated servers, while Microsoft’s AD-integrated design puts DNS on domain controllers. DISA wants split DNS on separate internal and external servers, while Microsoft supports split-brain through DNS policies on a single server. Root-hint fallback conflicts with the federal rule that all outbound DNS goes through Protective DNS. Read each control in light of the authority that applies to you: FCEB (CISA/OMB), DoD (DISA), or general enterprise (Microsoft/NIST/CIS).

Authoritative design-source overview

1. Namespace design

Decision at stake. You must choose the DNS name of the forest root domain and decide how it relates to your public namespace. Changing it later is hard, because the forest root name becomes the name of the forest.

Realistic options.

• Split-brain (same name inside and out): for example, contoso.com is used both internally and publicly.
• Delegated or undelegated subdomain of a registered domain: for example, corp.contoso.com or ad.contoso.com.
• A separate registered domain used only internally.
• A reserved private-use name: .internal (ICANN) or home.arpa (RFC 8375, residential).
• An unregistered or ambiguous suffix such as .local, .corp, .lan or a single label (not recommended).

What the government and vendor guidelines say.

• Microsoft.
• Use DNS names registered with an internet authority, and do not use single-label DNS names.
• If the organization has an internet presence, use names relative to the registered name. The example given is corp.contoso.com under contoso.com.
• Avoid “names that are used in internet-standard special features, such as .local,” and avoid top-level internet names on an intranet because of resolution errors.
• Since Windows Server 2008 R2, Dcpromo has not allowed single-label domain names.
• Keep the NetBIOS domain name the same as the DNS prefix where possible.
• ICANN.
• Board Resolution 2024.07.29.06 (July 29, 2024) permanently reserves .INTERNAL from delegation in the root zone “to provide for its use in private-use applications”. This follows SSAC advice SAC113.
• The accompanying ICANN-authored Internet-Draft says organizations should either use subdomains of a name they control or use .internal.
• The 2018 Board resolution stopped the .corp, .home and .mail applications because of name collision. This shows such strings are unsafe, but it does not reserve them for private use.
• IETF.
• RFC 6761 lists special-use names (.test, .example, .invalid, .localhost, and .local for mDNS via RFC 6762). .test and .example are reserved for testing and documentation, so they must not be used as production namespaces.
• RFC 9499 defines “split DNS”/“split horizon” terminology.
• NIST SP 800-81r3.
• NIST does not prescribe a naming scheme.
• For DNSSEC and mobile hosts it notes that “network administrators can avoid this problem by using different names for internal and external zones”. If internal zones are signed, it recommends a separate delegation from the external parent so a chain of trust exists, while acknowledging that this leaks the delegation name.

Trade-offs.

• Split-brain keeps user principal names and URLs identical inside and out. The cost is maintaining two copies of the same zone. Public records must be mirrored internally, or internal clients cannot reach the public site.
• A subdomain of a registered name is unambiguous, can get publicly trusted certificates, and gives a clean chain of trust for DNSSEC. Its weakness is that internal names may leak in queries to public resolvers unless outbound DNS is controlled.
• .internal is guaranteed never to collide. However, no public CA can issue certificates for it, and it cannot chain to the root for DNSSEC.
• .local conflicts with mDNS (RFC 6762). .corp and other unregistered strings are at risk of collision and leakage.
• Disjoint namespace (a computer’s primary DNS suffix differs from its AD domain name) is supported but adds SPN, registration and suffix-search complexity. Use it only when an existing DNS structure requires it.
• Single vs multiple namespaces:
  • One forest with one contiguous tree is simplest.
  • Several trees, or forests linked by trust, need conditional forwarders or stub/secondary zones (see §2–3).
  • Microsoft notes that DCs cannot forward-resolve the other forest’s names if those names are not registered.

Conflicts.

• None of the authorities reviewed endorse .local.
• Microsoft prefers a subdomain of a registered domain. ICANN now offers .internal as an alternative that never collides. These two do not contradict each other, but Microsoft’s AD naming pages do not yet mention .internal; that absence was not verified on every page.

2. Zone design

Decision at stake. How zones are stored and replicated, who can write to them, and how other namespaces are reached.

Realistic options.

• AD-integrated primary zones. Replication scope can be:
  • all DNS servers on DCs in the forest (ForestDnsZones),
  • all DNS servers on DCs in the domain (DomainDnsZones, the default),
  • all DCs in the domain (the legacy Windows 2000-compatible domain partition), or
  • a custom application directory partition.
  • File-based standard primary/secondary zones using AXFR/IXFR.
  • Stub zones, conditional forwarders, or secondary zones for reaching other namespaces.
  • The GlobalNames zone for single-label names.
  • Delegation of child-domain zones.

What the government and vendor guidelines say.

• Microsoft.
• AD-integrated zones replicate through AD rather than zone transfer. Secure dynamic update is supported only for AD-integrated zones and is their default.
• Use forest scope when names must be resolvable across domains, for example the _msdcs forest zone.
• Reverse zones can be created AD-integrated by network ID (for example 10.1.0.0/24).
• For trusts, the remote domain’s DNS records must be resolvable, through forwarders or secondary/stub zones.
• GlobalNames holds static CNAMEs for important servers. Dynamic updates cannot register names in it. Support must be enabled on each DNS server. Microsoft describes it as “not designed to be a complete replacement for WINS”.
• DISA STIG.
• Secondary servers must cryptographically authenticate zone transfers. The STIG states that for AD-integrated zones this authenticity “is accomplished by AD replication”.
• Primaries must send transfers only to listed secondaries.
• NS records must point to active authoritative servers.
• All authoritative servers must hold the same zone version.
• Zone records must be validated annually.
• No zone may contain IPv6 link-local addresses, and AAAA records are only for hosts that are actually dual-stack.
• NIST SP 800-81r3.
• Restrict zone transfers with ACLs and authenticate them with TSIG (or SIG(0)). ZONEMD can verify zone integrity, and TLS (XoT) adds confidentiality.
• Disable transfers on secondaries unless they feed other secondaries.
• Keep NOTIFY on.
• Tune SOA refresh between roughly 1200 s and 86400 s to avoid “zone drift/thrash”.
• Check delegations regularly for lameness.
• IETF.
• RFC 2317 (BCP 20) defines classless in-addr.arpa delegation using CNAMEs for subnets smaller than /24.
• RFC 6303 (BCP 163) says resolvers should serve locally the reverse zones for private and special address space (for example RFC 1918 ranges), so those queries do not leak to the public DNS.
• RFC 1912 lists classic configuration errors, such as missing PTRs and CNAMEs at the zone apex.

Trade-offs.

• AD-integrated zones are multi-master and their replication is secured by AD. This satisfies DISA’s authenticated-transfer rule without TSIG. The catch is that the zone can only live on DCs, which ties DNS availability to DC availability (§6).
• File-based secondaries allow DNS servers that are not DCs, but transfers then need ACLs and TSIG. The Windows DNS server’s support for standard RFC 8945 TSIG on zone transfers was not verifified in this research. Windows uses GSS-TSIG for secure dynamic update.
• Stub zones follow changes to the target’s NS set automatically.
• Conditional forwarders are simple and can be AD-replicated, but they depend on fixed IP addresses.
• Secondary zones give full local copies and resilience, but they need the partner to allow transfers.
• Reverse zones: for each private range, host an internal reverse zone. If you don’t, PTR lookups leak to the public DNS.

Conflicts. NIST frames zone protection in terms of TSIG and ACLs, while Microsoft relies on AD replication. DISA explicitly accepts AD replication as equivalent, so the guidance is consistent in practice.

3. Resolution and forwarding design

Decision at stake. How internal resolvers reach internal partner namespaces and the internet, and which servers are allowed to recurse.

Realistic options.

• External resolution: root hints, forwarders (including a Protective DNS service), or forwarders with root-hint fallback.
• Partner and split namespaces: conditional forwarders.
• Recursion: enabled, disabled (authoritative-only servers), or selectively controlled with recursion-scope policies.
• Fully closed (air-gapped) designs with no external resolution.
• Client transport: encrypted (DoH/DoT/DoQ) or traditional port 53.

What the government and vendor guidelines say.

DC resolver order (Microsoft).

• On a DC that runs DNS, list a replication partner first and the loopback (127.0.0.1 / ::1) second or third, never first.
• The BPA warns that if loopback is first, “Active Directory might be unable to find its replication partners”, and that a DC pointing only to itself can become an “island”.
• The first DC in a new forest points to itself.
• Never point DCs at an ISP’s DNS servers.
• Some Microsoft Q&A answers argue the opposite (self first). The BPA rule is the authoritative published position.

Recursion and role separation.

• NIST SP 800-81r3:
  • An instance that the internet can reach should be authoritative or recursive, not both.
  • Purely internal servers may combine the two roles, which it calls “acceptable and practical”.
  • Recursive servers should accept queries only from internal clients.
  • Enable QNAME minimization where supported.
• DISA:
  • Prohibit recursion on authoritative servers that have no forwarders configured.
  • Restrict caching servers to known client ranges.
  • Implement internal/external role separation.
  • Forwarders on an authoritative Windows DNS server must point only to an internal, non-AD-integrated DNS server or to DoD Enterprise Recursive Services.
  • Servers authoritative for local zones must point root hints only at the internal root.
  • NIST SP 800-53 SC-22 requires the name-resolution service to be fault-tolerant and to implement internal/external role separation.

Protective DNS and egress.

• NIST SP 800-81r3:
  • “Employ protective DNS wherever technically feasible”.
  • It prefers a hybrid of cloud and on-premises RPZ/DNS firewall where feasible, so that a cloud outage that fails open still leaves local protection.
  • Block outbound DNS (UDP/TCP 53) from everything except authorized forwarders. Block unauthorized DoT (TCP 853), DoQ (UDP 853) and DoH (RPZ plus firewall).
  • Use MDM/EMM so users cannot configure unapproved resolvers.
• CISA: FCEB agencies are required to route all DNS traffic leaving agency networks to CISA’s Protective DNS, which supports DoH and DoT over IPv4 and IPv6.
• NSA/CISA PDNS CSI:
  • It sets selection criteria such as blocking malware and phishing domains, high availability, logging, and handling of roaming clients.
  • It warns that the provider can see all your queries, so you must understand how it uses the data.
  • It explicitly does not endorse any vendor.
• CIS Controls v8.1: Safeguard 4.9 configures trusted DNS servers on enterprise assets; Safeguard 9.2 uses DNS filtering services.

Encrypted DNS.

• NIST says to encrypt internal and external DNS “wherever feasible”, while making sure browsers’ own DoH does not bypass the enterprise resolvers.
• CISA requires encrypted DNS between FCEB endpoints and agency DNS infrastructure where technically supported, and allows DNS proxies for legacy endpoints.
• Microsoft:
  • Windows Server 2025 DNS gained DoH for client-facing traffic in the February 10, 2026 update (preview). It became generally available with the 2026-06 security update KB5094125.
  • Microsoft states that upstream traffic (forwarders, conditional forwarders, authoritative servers), zone transfers and dynamic updates “remain unencrypted”. Policies that filter on transport protocol do not match DoH queries.
  • Microsoft Learn’s “Secure DNS Client over HTTPS (DoH)” page says not to enable “Require DoH” on domain-joined computers, because AD DS relies heavily on DNS and the Windows DNS Server service did not support DoH queries; it suggests IPsec connection security rules for encrypting AD DNS traffic instead. That page predates the 2026 server-side DoH feature.

Split-horizon resolution.

• Microsoft supports split-brain on a single server through zone scopes and query-resolution policies, including in AD. The zone scopes replicate through AD, but the policies do not and must be copied to each server.
• DISA requires internal and external records to be kept separate. With separate servers, the internal server must be unreachable from outside and the external server unreachable from inside resolvers.

Air-gapped and segmented networks.

• No source reviewed recommends root hints in closed networks.
• DISA’s internal-root rule and NIST’s egress blocking both point to: no direct external resolution, with an internal root or forwarder hierarchy instead.
• ICANN/IANA publish the root hints for internet-connected resolvers.

Trade-offs.

• Root hints remove dependence on a third party, but they bypass Protective DNS and egress control.
• Forwarding only to PDNS centralizes policy and logging, but it becomes a single dependency. Fail-open designs reintroduce bypass, which is why NIST suggests on- premises backup protection.
• DoH to Windows DNS protects the client-to-resolver hop. It adds certificate management, needs NTP-accurate time, and makes passive network monitoring harder. It does nothing for traffic between the DC and its forwarders.

Conflicts. See the conflicts section below: root-hint fallback versus PDNS mandates; whether internal DoH is required or optional; and split-brain on separate servers versus DNS policy.

4. Dynamic update and record-management design

Decision at stake. Who is allowed to create and change records, how stale records are removed, and how DHCP registrations are secured.

Realistic options.

• Update mode: “Secure only”, “Nonsecure and secure”, or “None”.
• Who registers: client self-registration, or DHCP registering on the client’s behalf.
• Infrastructure hosts: static or dynamic records.
• Scavenging: aging and scavenging on or off.
• DHCP Name Protection on or off.

What the government and vendor guidelines say.

• Microsoft:
  • Secure dynamic update is available only for AD- integrated zones and is the default after conversion. Standard primary zones accept unsecured updates.
  • A DHCP server that registers on a client’s behalf becomes the owner of that record.
  • To avoid ownership and stale-record problems, configure DHCP with a dedicated, low-privilege credential for DNS updates and use the DnsUpdateProxy group carefully. Records created by members of DnsUpdateProxy are not secured.
  • DHCP Name Protection (which uses DHCID records) stops non-Windows clients from taking over names already registered.
  • Aging and scavenging are disabled by default. The no-refresh and refresh intervals are 7 days each, and the default scavenging period is 7 days. Both server-level scavenging and zone-level aging must be enabled.
• NIST SP 800-81r3:
  • Accept updates only from authorized senders (TSIG or ACL); TSIG timestamps help against replay.
  • Use dedicated hidden primaries for zones that accept dynamic updates, because floods of updates can starve query service.
  • Keep a history of DHCP leases for incident response.
• DISA:
  • Restrict dynamic updates to known clients and protect their authenticity through transaction signing.
  • Record who added, modified or deleted zone data.
  • The DNS server’s own IP address must be static.
  • Validate zone records annually.

Trade-offs.

• Static records for DCs, DNS servers and other infrastructure avoid accidental scavenging and spoofed registration, but they have to be maintained by hand. Note that DCs register their own SRV records dynamically, and that must keep working.
• Aggressive scavenging cuts stale records, which are a source of spoofing and dangling records. Set too short relative to DHCP lease length, it deletes live records. A common rule of thumb is no- refresh plus refresh greater than or equal to the DHCP lease; that rule is not stated in the sources reviewed here.

Conflicts.

• NIST’s hidden-primary model does not fit AD’s multi-master model, where every DC hosting the zone is a writable primary.
• DISA’s “transaction signing” is satisfied by Windows GSS-TSIG secure updates.

5. DNSSEC and integrity design

Decision at stake. Whether to sign zones (external and/or internal), with which algorithm and denial-of-existence method, where the private keys are kept, and whether resolvers and clients validate.

Realistic options.

• Sign external zones only, sign both external and internal, or sign nothing.
• Online signing (keys on the server, which allows dynamic updates) or offline signing.
• A KSK/ZSK split or a combined signing key.
• NSEC or NSEC3.
• RSA/SHA-256 or ECDSA P-256/P- 384 (Ed25519/Ed448 are listed by NIST).
• Validation on the resolver only, or with clients enforcing it through the NRPT.

What the government and vendor guidelines say.

NIST SP 800-81r3.

• Deploy DNSSEC to protect integrity.
• Signing internal zones “is not recommended” unless something (for example, a government requirement) mandates it. The reasons:
• It is hard to build a chain of trust without extra trust anchors.
• Dynamically updated zones must be re-signed constantly.
• It is pointless when the same servers are both authoritative and recursive, which is the usual AD pattern.
• Algorithms (Table 1, from RFC 8624, SP 800-57 and SP 800-131A):
• RSA/SHA-256 (alg 8) with 2048-bit keys or larger
• ECDSA P-256 (13)
• ECDSA P-384 (14)
• Ed25519 (15)
• Ed448 (16)
• ECDSA and EdDSA are preferred because their responses are smaller.
• 112-bit security strength is acceptable until 2030, after which 128-bit is required.
• Keys have a maximum lifetime of 1–3 years.
• Store the KSK in an HSM where practical.
• Keep DNSKEY RRSIG validity short (about 5–7 days).
• Avoid TTLs of 30 s or less on signed data.
• Prefer NSEC. If NSEC3 is used, set its parameters per RFC 9276.
• Signers and validators need authenticated time (for example NTS).
• Validating resolvers should configure the root trust anchor and enable automated RFC 5011 rollover.

DISA STIG.

• Enable DNSSEC records, and validate the authentication chain.
• Use NSEC3 for all internal zones, changing the salt at every full re-sign.
• The signature algorithm must be FIPS- compatible.
• RRSIG validity on DNSKEY and DS should be between 2 days and 1 week.
• Keep the ZSK private key only on a server that supports dynamic updates.
• If the primary does not take dynamic updates, keep both the KSK and ZSK private keys off it (offline signing).
• Export trust anchors and distribute them to validating servers, and enable automatic trust-anchor update.
• Use Group Policy NRPT to make clients require DNSSEC validation.

NIST SP 800-53.

• SC-20 requires authoritative responses to carry origin-authentication and integrity artifacts and a verifiable parent–child chain. SC-20(1) has been withdrawn and folded into SC-20.
• SC-21 requires resolvers to request and perform that verification.

IETF.

• RFC 9364 (BCP 237) is the DNSSEC roadmap.
• RFC 4033–4035 are the core specifications.
• RFC 6781 covers operational practice: KSK/ZSK roles, rollovers, and algorithm rollover ordering.
• RFC 9905 (November 2025) makes RSASHA1 and RSASHA1-NSEC3-SHA1 “MUST NOT” for signing and SHA-1 DS digests “MUST NOT”. Validators should still accept them during the transition.
• RFC 9904 moves algorithm recommendations to the IANA registry.

Trade-offs.

• Windows’ online signing of AD-integrated zones keeps dynamic updates working, but the signing keys stay on DCs. That runs against NIST’s HSM preference and DISA’s offline- key rules for static zones.
• NSEC3 slows zone walking. NIST points out that it can often still be reversed and adds CPU cost.
• ECDSA keeps responses below fragmentation limits. RSA has wider legacy support.
• Note that NSEC3 itself hashes with SHA-1. RFC 9905 deprecates SHA-1 signature algorithms, not the NSEC3 hash, and NIST says to migrate once a replacement is specified.

Conflicts.

• Internal signing: NIST says generally don’t; DISA says do.
• NSEC versus NSEC3.
• On algorithms, DISA’s “FIPS-compatible” requirement overlaps with NIST’s table: RSA/SHA-256 and ECDSA are both FIPS 186 algorithms. Microsoft Learn’s “Sign DNS Zones with DNSSEC” page lists RSA/SHA-256 (default), ECDSA P-256/SHA-256, ECDSA P-384/SHA-384, RSA/SHA-512 and the SHA-1 variants, but not Ed25519 or Ed448; its default DS generation includes SHA-1, which RFC 9905 now prohibits.

6. Availability and placement design

Decision at stake. Whether DNS runs on DCs or on dedicated servers, and how many DNS servers to deploy and where.

Realistic options.

• AD-integrated DNS on every DC, or on some DCs.
• Dedicated (appliance or Windows) resolvers in front of DCs.
• Caching-only resolvers at branch sites.
• Anycast resolver addresses.
• Cloud resolvers.

What the government and vendor guidelines say.

• NIST SP 800-81r3:
  • “Deploy dedicated DNS servers to reduce attack surfaces”. If that is not feasible, co-locating with related core services such as DHCP may be acceptable.
  • Every zone needs a primary and one or more secondaries. At least two authoritative servers should sit on different network segments and in different places.
  • Use a hidden primary.
  • Stubs should be configured with at least two recursive servers. Anycast can hide the loss of a single server, which matters for applications that use only one server.
  • Remove DNS server software from hosts that are not name servers.
• NIST SP 800-53 SC-22 Discussion: at least two authoritative servers in two geographically separated subnetworks.
• DISA:
  • Authoritative servers must be geographically dispersed and on different network segments.
  • There must be a documented procedure to re-role a secondary as primary.
  • Administrators must be notified when a component fails.
• Microsoft:
  • Run DNS on DCs with AD-integrated zones so the DC locator works and replication is secured.
  • Configure DCs as in §3.
  • Point member servers and clients only at internal DNS servers.
• CIS 4.9: assets use enterprise-controlled or reputable DNS servers.

Trade-offs.

• DNS on DCs: simpler, gives multi-master AD-secured replication, and keeps locator records local. On the other hand, a compromise of DNS or a DC affects both services, and DCs then process untrusted recursive traffic.
• Dedicated resolvers (forwarding internal AD zones to DCs): smaller attack surface on the DCs, room for PDNS/RPZ and DoH capacity, and alignment with NIST and DISA role separation. The costs are more infrastructure and the need for conditional forwarding or stub zones toward the DCs.
• Caching-only branch resolvers cut WAN traffic but add another layer of caching and TTL to manage.

Conflicts. NIST’s “dedicated DNS” recommendation and Microsoft’s DNS-on-DC model are the main tension (see below).

7. Hardening-by-design (architectural security choices)

Decision at stake. Which protective features are built in from the start.

What the government and vendor guidelines say.

• RRL. DISA requires Windows DNS response rate limiting to be enabled (V-259417), and requires that the server cannot be used to launch DoS attacks. NIST lists DoS and resource exhaustion as threats.
• Cache locking and socket pool (Microsoft).
• Cache locking prevents cached records from being overwritten for a percentage of their TTL. The default is 100%.
• The socket pool randomizes source ports. It is on by default with 2,500 sockets, configurable from 0 to 10,000.
• Both defend against cache poisoning. Keep the defaults.
• Recursion off on authoritative servers. NIST and DISA (§3).
• Zone transfers. Disable or limit them to listed secondaries, and authenticate them (NIST, DISA). For AD-only zones, transfers can usually be turned off entirely.
• Information leakage.
• NIST says to keep HINFO, RP, LOC and similar records out of zones that face the internet, and to judge TXT records case by case.
• DISA says HINFO, RP, TXT and LOC must not be used in the zone SOA, and the server must refuse version queries.
• Disable WINS lookups on the DNS server (DISA).
• Policy-based controls. Microsoft DNS policies support split-brain, recursion scopes (selective recursion by interface or subnet) and query filtering. DoH queries cannot be matched by transport-protocol filters.
• LLMNR, NetBIOS and mDNS.
• The CIS Windows Server 2022 Benchmark v4.0.0 sets:
  • 18.6.4.1 “Configure multicast DNS (mDNS) protocol” = Disabled
  • 18.6.4.2 “Configure NetBIOS settings” = Disable NetBIOS name resolution on public networks
  • 18.6.4.4 “Turn off multicast name resolution” = Enabled (disables LLMNR)
  • Older CIS text adds that NetBIOS over TCP/IP should also be disabled per NIC to fully mitigate name-resolution poisoning.
  • DISA Windows Server STIGs contain equivalent OS hardening; the exact rule IDs for the DNS client were not verified in this research.
  • Removing these fallbacks means DNS must be complete. For legacy single-label needs, use GlobalNames or DNS suffix search lists rather than WINS. Microsoft Support KB5071836 (November 2025) states that Windows Server 2025 will be the final LTSC release to include and support WINS, with standard support through November 2034.
  • Platform. NIST says to harden the host operating system. DISA requires zone files and keys to be writable only by the DNS service and administrators, and requires FIPS- validated cryptography.

Trade-offs.

• RRL can drop legitimate bursts from NATed clients, so tune exemptions.
• Fully disabling NetBIOS can break legacy applications. CIS’s “public networks only” setting is a compromise; stricter environments disable it everywhere.

Conflicts. CIS’s partial NetBIOS setting is less strict than the full disable that hardening guides commonly recommend. Organizations covered by both CIS and DISA should adopt the stricter one.

8. Logging and monitoring design

Decision at stake. What DNS telemetry to capture, how long to keep it, and how to correlate it.

What the government and vendor guidelines say.

• Microsoft:
  • DNS audit events (configuration changes to zones, records and server) are on by default and have negligible cost.
  • Analytic events (every query and response, via ETW) are off by default. Microsoft Learn’s “Enable DNS Logging and Diagnostics” page cites a 5% performance degradation at 100,000 QPS on modern hardware and “no apparent performance impact” at 50,000 QPS or below.
  • Legacy debug logging to a file is heavier and is meant for troubleshooting.
  • DoH has its own analytic events.
  • The Sentinel “Windows DNS Events via AMA” connector streams only analytic events.
• NIST SP 800-81r3:
  • Log current and historical DNS traffic for incident response.
  • Always log queries and responses that protective DNS classifies as malicious.
  • You may filter known-good domains before sending to the SIEM, but keep a complete log for forensics. dnstap or selective logging are options at scale.
  • Correlate with DHCP lease history.
  • Integrate PDNS logs with the SIEM.
  • Check validator logs for DNSSEC failures.
  • Use authenticated time (NTS) on signers, validators and encrypted-DNS servers.
• NIST SP 800-53:
  • AU-8 requires timestamps from internal clocks, in UTC or with a fixed or recorded offset. AU-8(1) and AU-8(2) have been moved to SC- 45(1) and SC-45(2).
  • SC-45 requires clocks to be synchronized; SC-45(1) adds an authoritative source and SC-45(2) a secondary source in another region.
  • SC-45 is not in the 800-53B baselines; it appears in the SP 800-82r3 OT overlays.
• DISA:
  • The DNS server log must be enabled.
  • The “Manage auditing and security log” right is limited.
  • Record who changed zone data.
  • Back up audit records at least every seven days to a different system.
  • Notify administrators of DNSSEC/TSIG failures and anomalies in signed transfers.
• CIS v8.1: 8.4 standardizes time synchronization, 8.6 collects DNS query audit logs, 8.9 centralizes logs, and 8.10 retains them.

Trade-offs.

• Analytic logging on busy DCs costs CPU and storage, and the default circular ETL behaviour can drop events. Forward events in near real time with an agent rather than relying on local retention.
• Logging at the PDNS forwarder catches egress but loses client attribution behind the forwarder. NIST discusses putting RPZ “closest to the client” versus “closest to the internet” for this reason.
• Encrypted DNS removes passive network visibility, so log at the resolver.

Conflicts. None of substance. The sources differ only in prescriptiveness: DISA sets a fixed 7- day backup interval, while NIST and CIS leave retention to organizational policy.

Where authorities agree, differ, or conflict

Caveats and items that could not be verified

• DISA DNS STIG release. Mirrors show V2R4 (2026-02-23) and V2R5 (2026-06-03). A DISA announcement listing mentions “Ver 2, Rel 6”. The official cyber.mil page would not render, so confirm the current release and any changed rule IDs (V-259xxx) on cyber.mil before citing them.
• The Five Eyes AD guide. Its DNS-specific recommendations were not extracted and checked line by line here. Its lead author is ASD; only the CISA/NSA co-authorship is treated as the source.
• Statements not confirmed on primary pages:
  • Microsoft’s advice against “Require DoH” on domain-joined clients (Microsoft Learn DoH client page) predates the 2026 server-side DoH feature and may be revised; the WINS end-of-support statement is confirmed by Microsoft Support KB5071836.
  • Whether Windows DNS supports standard TSIG for zone transfers was not confirmed; Microsoft Learn’s DNSSEC signing page lists no Ed25519/Ed448 option.
• Benchmark and control versions:
  • The current version of the CIS Windows Server 2025 Benchmark was not verified, and no CIS benchmark specifically for the Microsoft DNS Server role was identified.
  • The CIS 8.10 retention minimum and the exact CIS licence terms should be checked against current CIS pages.
• SP 800-53 control text. It was taken from consistent mirrors of Release 5.2.0, not from the CPRT pages directly.
• RFC 8624 (cited by NIST). Algorithm recommendations have since moved to the IANA registry under RFC 9904. The IANA “DNS Security Algorithm Numbers” registry currently lists RSASHA256 (8) and ECDSAP256SHA256 (13) as RECOMMENDED for signing, ECDSAP384SHA384 (14) as MAY, and RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) as MUST NOT for signing.
• Licensing.
  • US federal works (NIST, CISA, NSA, DISA) are generally not subject to US copyright. Joint international products may include foreign-copyright material.
  • Microsoft Learn content falls under the Microsoft Terms of Use.
  • IETF RFCs fall under the IETF Trust Legal Provisions.
  • CIS content is free for non-commercial use under CIS’s licence.
• Applicability. This reference does not tailor anything to an environment. Mandates (CISA PDNS, DISA STIG) bind only FCEB and DoD systems respectively; for everyone else they are best-practice benchmarks.

Annotated source catalog

Reference Collection: DNS Security and Deployment (Windows/Enterprise), October 2026

Scope note. This DNS source collection has been scoped to government and vendor guidelines — official Microsoft guidance plus government guidance (NIST, CISA/OMB/NSA, DISA, CIS) and the IETF and ICANN — to match the rest of this compendium. Other governments' source sections (UK NCSC, Australia ASD/ACSC, Canada/CCCS, France ANSSI, Germany BSI, EU ENISA) and their crosswalk columns were removed from the broader multi-country collection they were drawn from. A separate standalone DNS source document also exists but could not be merged from this session.

There is now a clear common baseline across the authorities. NIST SP 800-81r3 (final, March 2026), federal mandates, DISA and Microsoft’s own documentation all point to five things: DNSSEC, restricted recursion, protected dynamic updates and zone transfers, protective DNS/filtering, and query logging. They split mainly on how to encrypt DNS (DoH vs DoT, and whether to encrypt inside the network) and on how much logging is required. This collection verifies the preliminary items against publisher pages where possible, corrects several of them, and states plainly what could not be re-verified.

TL;DR

• Microsoft’s platform caught up in 2026. Server-side DNS over HTTPS for the Windows Server 2025 DNS Server role became generally available with the June 9, 2026 update (KB5094125). It covers client-to-server traffic only: forwarders, zone transfers and dynamic updates stay unencrypted. An older Microsoft Learn page still warns against “Require DoH” on domain-joined clients because the DNS Server role “doesn’t support DoH queries”, which is now outdated.
• Corrections to the preliminary pass:
  • Protective DNS there is one of three acceptable mitigations, not a standalone mandate.
  • RFC 9904 obsoletes RFC 8624.
  • Third-party mirrors list the Windows Server DNS STIG at V2R5 (2026-06-03), but this was not confirmed on DISA’s own site.

1. Overview of the guidance landscape

General reuse note:

• US federal works (NIST, CISA, NSA, OMB, DISA) are generally not subject to US copyright. DISA STIGs are distributed via DoD Cyber Exchange.
• IETF RFCs are under IETF Trust Legal Provisions.
• CIS Controls are CC BY-NC-ND 4.0.
• Microsoft Learn content is under Microsoft’s Terms of Use. Some documentation repositories carry CC BY 4.0, so check per page.

2. Section A: Microsoft official guidance (by topic)

A1. DNS Server role overview and “what’s new”

• “What is Domain Name System (DNS)?” (Microsoft Learn, learn.microsoft.com/windows-server/networking/dns/dns-overview), free.
  • Lists the DNS Server features: AD integration, dynamic updates, DNSSEC, forwarding/conditional forwarding, caching, monitoring/logging, DNS policies, Anycast.
  • Notes that DNS is installed automatically with a new AD forest/domain and is the DC location mechanism.
• What’s new. The Windows Server 2016 “what’s new” page is the last to give a dedicated DNS Server section: DNS policies, RRL, DANE (RFC 6394/6698), unknown record support (RFC 3597), IPv6 root hints, and PowerShell support.
• Windows Server 2022. DNS client support for DoH.
• Windows Server 2025.
  • DC Locator improvements; mailslots are not used for DC discovery because of the WINS/mailslot deprecation.
  • Server-side DoH, delivered via the June 2026 update (see A11).

A2. AD-integrated zones and replication scope

• “Active Directory-Integrated DNS Zones” (Learn, .../identity/ad-ds/plan/active-directory-integrated-dns-zones).
  • Zone data replicates via AD replication, so no separate zone-transfer topology is needed.
  • Any DC running DNS can write updates (multi-master), and secure dynamic updates are supported.
  • Zones are stored in application directory partitions created at AD DS install: forest-wide ForestDnsZones and per-domain DomainDnsZones.
  • Custom application partitions can also be used as replication scope (Microsoft troubleshooting article on custom application directory partitions).

A3. Secure dynamic updates

• “Dynamic update” (Learn, .../networking/dns/dynamic-update).
  • Secure update is available only for AD-integrated zones.
  • After a zone becomes AD-integrated, Windows DNS servers default to secure only. File-backed zones default to no dynamic updates.
  • Clients try a nonsecure update first, then fall back to secure. Negotiation uses TKEY and signs with TSIG over Kerberos.
• KB 816592 “How to configure DNS dynamic updates in Windows”.
  • Repeats these defaults.
  • Warns that when a DHCP server performs secure updates on behalf of clients, records can become stale or owned by the DHCP server.
• Supporting standards. RFC 2136 (and GSS-TSIG).

A4. Aging and scavenging

• KB 816592 describes aging/scavenging as the DNS Server feature that “can scan and remove records that are no longer required.” The Microsoft Learn dnscmd reference gives the server defaults: no-refresh and refresh intervals of 0xA8 (168 hours, i.e., 7 days) each, and scavenging disabled by default (/defaultagingstate 0).

A5. Forwarders, conditional forwarders, root hints, recursion control

• “DNS forwarding in Windows Server” (Learn, .../networking/dns/forwarding).
  • Order of resolution. Server-level forwarders handle names not covered by a hosted zone, conditional forwarder or delegation. Without forwarders, the server uses root hints when recursion is enabled.
  • Dynamic Forwarder Reordering is on by default. Microsoft Learn says it “resets the list to the configured order approximately every 15 minutes” (no more precise figure is published). A response slower than 1 second counts as slow, and three consecutive slow responses or timeouts move a forwarder to the end of the list.
  • Windows Server 2022+ behaviour. If no forwarder responds, the server uses only the first one until the service restarts. Disable reordering to restore cycling through all forwarders.
  • Fallback to root hints happens by default when recursion is allowed and UseRootHint is $true.
  • Security guidance: “Allow recursive queries only from trusted clients and networks, and don’t expose recursive DNS service to untrusted networks.”
• Recursion scopes. These are part of DNS policies (A6).

A6. DNS policies

• DNS Policy Scenario Guide (linked from the WS2016 what’s new page).
  • Policies select responses by client subnet, time of day, transport, query type and other criteria.
  • Use cases include split-brain DNS, query filtering, recursion scopes and traffic management/load balancing.
• DoH caveat. Policies with a Transport Protocol filter do not match DoH queries, and you cannot write a filter that matches only DoH (DoH concept page, 2026).

A7. Response Rate Limiting

• Set-DnsServerResponseRateLimiting (PowerShell reference, WS2025 view).
  • Parameters: ResponsesPerSec, ErrorsPerSec, WindowInSec, IPv4/IPv6PrefixLength, LeakRate, TruncateRate, MaximumResponsesPerWindow, and Mode (LogOnly/Enable/Disable). - ResetToDefault restores defaults.
  • LeakRate example: at 3, the server answers one in three dropped queries. TruncateRate example: at 2, one in two receives a truncated response.
• Defaults. The cmdlet page does not list the numeric defaults. Microsoft’s Open Specifications [MS-DNSP] (DNS_RPC_RRL_PARAMS) give them: 5 responses/sec, 5 errors/sec, a 5-second window, LeakRate 3, TruncateRate 2, IPv4 prefix /24, IPv6 prefix /56, and 1,024 total responses per window (MaximumResponsesPerWindow). Microsoft’s DNS team blog “Response Rate Limiting in Windows DNS Server” states that RRL is disabled by default.

A8. Socket pool and cache locking

• Microsoft Learn training module “Secure Windows Server DNS” (unit 5):
  • Cache locking prevents cached records from being overwritten for a percentage of their TTL. The default is 100 (%).
  • The socket pool randomises source ports and is enabled by default. The default size is 2,500.
  • Configure with Set-DnsServerCache -LockingPercent and the socket pool setting (dnscmd /config /socketpoolsize, range 0–10,000 per long- standing Microsoft guidance).

A9. Global Query Block List (GQBL)

• dnscmd reference / Set-DnsServerGlobalQueryBlockList.
  • The default block list contains isatap and wpad, described as “two commonly deployed protocols that are particularly vulnerable to hijacking.”
  • The service may remove either name on first start if it finds that name in an existing zone.
  • Set-DnsServerGlobalQueryBlockList replaces the whole list.

A10. DNSSEC (signing, algorithms, NSEC/NSEC3, Key Master, trust anchors, validation, NRPT)

• “What is DNSSEC?” (Learn).
  • Covers the record types: RRSIG, NSEC, NSEC3, NSEC3PARAM, DNSKEY, DS.
  • A zone uses NSEC or NSEC3, never both. NSEC3 prevents zone walking.
  • Trust anchors on DCs are stored in the forest directory partition and can replicate forest-wide. On standalone servers they are stored in TrustAnchors.dns.
• “Sign DNS zones with DNSSEC” (Learn).
  • Algorithms offered: RSA/SHA-256 (default), ECDSAP256/SHA-256, ECDSAP384/SHA-384, RSA/SHA-1, RSA/SHA-1 (NSEC3), RSA/SHA-512.
  • Keys: KSK default 2048-bit with a 755-day rollover. ZSK default 1024-bit with a 90-day rollover.
  • Rollover methods: double-signature for KSK, prepublish for ZSK.
  • Defaults: DNSKEY/DS signature validity 168 h, zone record validity 240 h, DS digests SHA-1 and SHA-256.
  • The wizard labels NSEC3 as “recommended.”
  • Private keys must use the Microsoft Software KSP if they are to be distributed via AD.
  • The SHA-1 options sit uneasily with RFC 9905, which says MUST NOT sign with them (see Section 5).
• Key Master.
  • “Transfer Key Master role” covers online transfer and offline seizure.
  • After seizure, re-sign the zone and replace trust anchors.
• Validation.
  • “Validate and secure DNS responses using DNSSEC” covers RFC 5011 automatic trust-anchor update, supported since Windows Server 2012.
  • Clients request validation through the Name Resolution Policy Table (NRPT) in Group Policy. The DISA STIG requires this (V-259381).

A11. DNS over HTTPS (client and server)

• Client: “Secure DNS Client over HTTPS (DoH)” (Learn).
  • Supported from Windows Server 2022 and Windows 11.
  • Group Policy setting: Confifigure DNS over HTTPS (DoH) name resolution.
  • Works only with servers on the known-DoH list or ones you add.
  • The page still says not to enable “Require DoH” on domain-joined computers “because the Windows Server DNS Server service doesn’t support DoH queries”. This statement predates server GA.
• Server: “DNS encryption using DNS over HTTPS” (Learn, updated 2026-06-12) and “Enable DNS over HTTPS in DNS Server”.
  • Available from the 2026-06 Security Update KB5094125 for Windows Server 2025.
  • Not encrypted: upstream traffic (forwarders, conditional forwarders, authoritative servers), zone transfers, and dynamic updates (by default).
  • Classic port-53 DNS keeps working unless disabled.
  • Prerequisites: a certificate with Server Authentication EKU and a SAN that matches the URI template, a TCP 443 firewall rule, and Set- DnsServerEncryptionProtocol -EnableDoh $true -UriTemplate ….
  • Microsoft describes DoH and DNSSEC as complementary.
• TechCommunity Networking Blog, “DoH is now generally available on Windows DNS Server”. GA is for “client-to-server DNS traffic”. The public preview was announced Feb 9, 2026, and Zero Trust DNS for Windows 11 on Nov 18, 2025.

A12. Windows DNS client

• “DNS queries and lookups” (Learn) covers caching from the HOSTS file and TTL.
• It recommends configuring every client with more than one DNS server for fault tolerance.
• The DoH, NRPT and DNSSEC client behaviours are covered in A10 and A11.

A13. LLMNR / NetBIOS / mDNS status (as of 2026)

• “Aligning on mDNS: ramping down NetBIOS name resolution and LLMNR” (TechCommunity Networking Blog, Apr 22, 2022).
  • Says both protocols “are rarely used today” and needlessly expand attack surface.
  • NetBIOS name resolution was off by default on cellular interfaces and in “learning mode” (fallback only) in Insider builds.
  • “The default LLMNR behavior has not been changed in Windows yet.”
  • The stated goal is mDNS as the only multicast name-resolution protocol on by default.
• Status in 2026.
  • No Microsoft source found in this pass states that LLMNR is disabled by default in shipping Windows.
  • Microsoft’s policy documentation says LLMNR remains enabled unless the Turn off multicast name resolution policy is enabled.
  • Secondary summaries report that Windows Server 2025 DC Locator does not permit NetBIOS-based DC discovery by default, and that WINS is deprecated. Treat both as reported but not re-verified here.

A14. DnsAdmins, CVEs and advisories

• CVE-2021-40469 (MSRC, Oct 12, 2021): “Windows DNS Server Remote Code Execution Vulnerability”.
  • CVSS 3.1 base score 7.2 with PR:H (high privileges required). MSRC says it is exploitable only if the server is configured as a DNS server.
  • Third-party analysis (0patch) links it to the long-known DnsAdmins → ServerLevelPluginDll DLL-loading path. MSRC itself does not describe the mechanism.
  • Practical implication: membership of DnsAdmins should be treated as privileged.
• CVE-2020-1350 “SIGRed” (MSRC, July 14, 2020; CVSS 10, wormable).
  • KB4569509 workaround: set HKLM\SYSTEM\CurrentControlSet\ Services\DNS\Parameters\TcpReceivePacketSize (DWORD) to 0xFF00, then restart the DNS service.
  • Side effect: TCP responses over 65,280 bytes are dropped.
  • Microsoft advises removing the workaround after patching.
  • CISA issued Emergency Directive 20-03 for it.
• 2023–2026 Windows DNS Server CVEs. These could not be enumerated from MSRC in this pass. Use the MSRC Security Update Guide, filtered on “Windows DNS Server”.

A15. Security baselines (Security Compliance Toolkit)

• Not re-verified in this pass. The Microsoft security baselines in the Security Compliance Toolkit configure DNS Client settings such as Turn off multicast name resolution. Check the current Windows Server 2025 and Windows 11 baseline spreadsheets for exact DNS- related values.

A16. AD namespace guidance

• “Selecting the Forest Root Domain” (Learn):
  • Use a registered DNS suffix with a new prefix (e.g., corp.contoso.com).
  • “Do not use single-label DNS names.”
  • Microsoft does “not recommend using unregistered suffixes, such as .local”.
  • Prefix: Internet-standard characters only, 15 characters or fewer so it matches the NetBIOS name.
• “Naming conventions in Active Directory…” (support):
  • Lists single-label domain problems: they can’t be registered, need extra configuration, and members don’t dynamically update single-label zones by default.
  • Advises against using public TLDs or .local internally.
• “Disjoint Namespace” (Learn):
  • Disjoint namespaces are supported. DCs still register SRV records in the zone that matches the AD domain.
  • They are unsupported if the disjoint suffix matches an AD domain name in this or another forest (this breaks Kerberos name-suffix routing), or if the same suffix is used in another forest.
  • Test applications before deploying.

3. Section B: Government and standards guidance

B1. NIST

SP 800-81r3, Secure Domain Name System (DNS) Deployment Guide

• Authors: S. Rose (NIST), C. Liu and R. Gibson (Infoblox).
• URL: csrc.nist.gov/pubs/sp/800/81/r3/final (DOI 10.6028/NIST.SP.800-81r3).
• Dates: final March 2026 (released March 19, 2026). The initial public draft (April 10, 2025) is withdrawn. A NIST errata planning note is dated 07/10/2026.
• Status and access: supersedes SP 800-81-2. Free; US government work.
• Executive-summary recommendations:
  • Employ protective DNS “wherever technically feasible”. It blocks malicious traffic, filters by policy, supplies query/response data for DFIR, and integrates with zero trust.
  • “Encrypt internal and external DNS traffic wherever feasible.”
  • Deploy DNSSEC.
  • Deploy dedicated DNS servers.
  • Follow the technical guidance.
• Body topics:
  • Restricting zone transfers.
  • Lame delegations and zone drift.
  • Securing dynamic updates and NOTIFY.
  • Dangling CNAMEs and look-alike domains.
  • TTL recommendations.
  • DNSSEC key parameters and RRSIG validity periods.
  • NSEC3 and compact denial-of-existence as an alternative.
  • Algorithm migration and signing internal zones.
  • Authoritative time sources.
  • Encrypted DNS and blocking non-approved public DoH/encrypted resolvers (for example via MDM).
  • QNAME minimisation and exfiltration detection.
  • DNSSEC validation and trust-anchor maintenance.
  • Stub resolver threats.
• Terminology note: “protective DNS” in this document means the general service, not CISA’s programme.
• Minor anomaly: the PDF’s citation line reads “Rose S, Liu C, Nodurft R”, while the title page lists Ross Gibson.

SP 800-81-2 (Sept 2013). Superseded/legacy; earlier SP 800-81 (2006) is withdrawn.

SP 800-53 Rev 5. Verbatim wording comes from mirrors of the NIST catalogue; the NIST PDF §3.18 is the formal source.

• SC-20, Secure Name/Address Resolution Service (Authoritative Source):
• (a) Provide “additional data origin authentication and integrity verification artifacts” with authoritative responses to external queries.
• (b) Indicate child-zone security status and enable chain-of-trust verification.
• SC-20 is in the Low, Moderate and High baselines.
• SC-20(2) extends this to internal queries and is in no baseline.
• SC-21, Recursive or Caching Resolver: “Request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.” In other words, DNSSEC validation, either on the client or over authenticated channels to validating resolvers. In the Low, Moderate and High baselines.
• SC-22, Architecture and Provisioning: “Ensure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.” The discussion recommends at least two authoritative servers on geographically separated subnets. In the Low, Moderate and High baselines.

SP 800-207 and SP 1800/NCCoE. Not re-verified in this pass. NIST lists a “High Assurance Domains project” as supplemental material to 800-81r3.

B2. CISA / OMB / NSA

• CISA Encrypted DNS Implementation Guidance (v1.0, document dated April 2024, published May 16, 2024; free; FCEB audience).
  • Implements OMB M-22-09, which requires encrypted DNS “where technically supported”.
  • Reminds agencies they must use CISA Protective DNS for all egress resolution under M-22-09 and 6 U.S.C. § 663 note.
  • Covers DoH, DoT and DoQ, tunnelling to Protective DNS, endpoint configuration, and blocking applications that silently enable encrypted DNS.
• CISA Protective DNS. Available only to federal agencies, per the above.
• Not re-verified in this pass:
  • Emergency Directive 19-01 (January 2019, DNS infrastructure tampering).
  • OMB M-21-31 (August 2021, event logging including DNS).
  • NSA “Adopting Encrypted DNS in Enterprise Environments” (January 2021).
  • NSA/CISA “Selecting a Protective DNS Service” (March 2021).

B3. DISA (DoD)

• Microsoft Windows Server DNS STIG, Version 2.
  • V2R4: 81 rules (5 CAT I, 76 CAT II, 0 CAT III), released Q1 2026 per mirrors. A third-party viewer lists V2R5 dated 2026-06-03 with the same counts.
  • Download is free via DoD Cyber Exchange. The public version needs no CAC.
  • The Windows 2012 DNS STIG (V2R7) is sunset.
• Representative requirements (severity per rule not confirmed here):
  • Restrict recursion to known clients, and prohibit recursion on authoritative servers without forwarders.
  • Forward only to internal non-AD-integrated servers or DoD Enterprise Recursive Services.
  • Allow zone transfers only to specified secondaries, authenticated by TSIG (AD replication suffices for AD-integrated zones).
  • Enable DNSSEC with FIPS-compatible algorithms.
  • NSEC3 for all internal zones, with the salt changed on each full re-sign.
  • RRSIG validity between 2 days and 1 week.
  • Distribute trust anchors with automatic update.
  • Use NRPT to require DNSSEC validation.
  • Internal/external role separation, and geographically dispersed servers on different segments.
  • Disable WINS lookups.
  • Enable the DNS log.
  • Refuse version queries.
  • Restrict dynamic updates to known clients and protect them with transaction signing.
  • Validate zone records annually.
  • Use DNS Notify.
• BIND 9.x STIG, Infoblox STIG and DNS SRG. Not re-verified in this pass.

B4. CIS

• CIS Controls v8.1 (CC BY-NC-ND 4.0; free).
  • Safeguard 9.2 “Use DNS Filtering Services”: “on all end-user devices, including remote and on-premises assets, to block access to known malicious domains.” IG1–IG3. The v8 wording said “all enterprise assets”.
  • Safeguard 8.6 “Collect DNS Query Audit Logs”: “on enterprise assets, where appropriate and supported.” IG2–IG3.
• CIS Benchmarks are a separate product under CC BY-NC-SA 4.0. Their DNS content (e.g., the Windows DNS Client settings) was not re-verified.

B11. ICANN / SSAC

• SAC113 (18 Sept 2020) recommended reserving one private-use TLD that is never delegated.
• Board Resolution 2024.07.29.06 (29 July 2024) reserves .INTERNAL permanently from delegation in the root zone “to provide for its use in private-use applications”.
  • The reservation is held in IANA’s reserved-domain registry, not the IETF special- use registry.
• The IETF draft (draft-davies-internal-tld) documents this. It is an Internet-Draft, not an RFC.
• Name-collision and KSK-rollover guidance. Not re-verified.

B12. IETF (IETF Trust terms; all free)

• Core: RFC 1034/1035. RFC 9499 (DNS terminology, BCP 219).
• DNSSEC:
  • RFC 4033–4035 (core) and RFC 6840 (clarifications).
  • RFC 9364 (BCP 237, Feb 2023), the umbrella BCP for DNSSEC.
  • RFC 9904 (Nov 2025) obsoletes RFC 8624 and moves algorithm requirement levels into the IANA DNSSEC registries.
  • RFC 9905 (Nov 2025) updates RFC 4034/5155: RSASHA1 and RSASHA1-NSEC3- SHA1 are MUST NOT for signing (validation still MUST be implemented), and SHA-1 DS digests are MUST NOT for delegation.
  • RFC 9906 (Nov 2025) deprecates ECC-GOST.
• Encrypted transports: DoT RFC 7858, DoH RFC 8484, DoQ RFC 9250.
• Updates and transfers: RFC 2136, RFC 3007 (secure dynamic update) and RFC 8945 (TSIG).
• Special-use names:
  • RFC 6761 (special-use domain names).
  • RFC 8375 (home.arpa).
  • RFC 9476 (.alt).
• Resilience and transport:
  • RFC 5452 (forgery resilience: ID and port randomisation).
  • RFC 8806 (local root).
  • RFC 7766 (DNS over TCP).
  • RFC 9210 (TCP as a requirement, BCP 235).
  • RFC 8767 (serve-stale).
• Privacy and caching: RFC 9156 (QNAME minimisation). RFC 8198 (aggressive use of DNSSEC-validated cache).
• RRL. No standards-track IETF RRL specification was identified; RRL is an implementation practice.
• Titles and numbers above other than RFC 9904/9905/9906 were not individually re- fetched in this pass.

4. Topic crosswalk

“NV” = not verified in this pass; “—” = not addressed in sources reviewed.

5. Where authorities agree, differ, or conflict

1. Encrypted DNS.
   • NIST says to encrypt internal and external traffic wherever feasible. OMB M-22- 09 and CISA require encryption where technically supported, using any of DoH, DoT or DoQ.
   • The common thread is control and visibility. Every authority opposes endpoints or browsers bypassing the enterprise resolver with self-selected DoH. NIST and CISA both recommend blocking non-approved encrypted resolvers.
2. Root hints versus forwarding to protective DNS.
   • Microsoft’s default falls back to root hints when forwarders fail (UseRootHint $true).
   • The two conflict directly. Microsoft’s dnscmd /isslave 1 setting reconciles them: per the Microsoft Learn dnscmd reference, the server then “terminates the search and sends a failure message to the resolver” if the forwarder doesn’t respond (the default is 0).
3. DNSSEC algorithms and NSEC3.
   • RFC 9905 makes RSA/SHA-1 signing MUST NOT, yet Windows still offers RSA/SHA-1 algorithms and generates SHA-1 DS records by default (SHA-1 plus SHA-256).
   • DISA requires FIPS-compatible algorithms and NSEC3 for all internal zones. Microsoft’s wizard calls NSEC3 “recommended”.
   • NIST 800-81r3 adds compact denial-of-existence as an NSEC3 alternative. RFC 9276 (not fetched here) separately constrains NSEC3 iterations and salt, which may conflict with DISA’s salt-rotation rule.
4. Logging scope.
   • CIS 8.6 applies only “where appropriate and supported” and starts at IG2.
   • DISA focuses on server/audit logs and change attribution.
   • Microsoft Learn (“Enable DNS Logging and Diagnostics”) notes that a server receiving 100,000 QPS “can experience a performance degradation of 5%” with analytic logs enabled, with no apparent impact at 50,000 QPS and lower, and recommends debug logging only temporarily.
5. Internal/external separation. NIST SC-22 and DISA require role separation. Microsoft’s split-brain DNS policies offer a single-server alternative, which these frameworks do not endorse.
6. Microsoft’s internal inconsistency. The DoH client page still says the DNS Server role does not support DoH, which the June 2026 GA contradicts.

6. Caveats and items not verified

• Not re-verified against publisher pages in this pass:
  • NSA’s two CSIs, the NSA/CISA PDNS paper, CISA ED 19-01, the CISA DNS resources page, and OMB M-21-31.
  • DISA’s BIND, Infoblox and DNS SRG documents.
  • The CIS Benchmark DNS content.
  • ICANN name-collision and KSK guidance.
  • NIST SP 800-207 and the NCCoE projects.
  • Microsoft security baselines.
  • 2023–2026 Windows DNS CVEs.
  • Most RFC titles other than 9904, 9905 and 9906.
• DISA STIG version. The current release (V2R4 versus V2R5) comes from third-party mirrors (stigviewer, cyber.trackr.live), which disagree on dates. Confirm on DoD Cyber Exchange.
• NIST SP 800-53 wording comes from consistent third-party mirrors, not the NIST catalogue page itself.
• Corrections to the preliminary list:
  • RFC 9904 obsoletes RFC 8624.
  • The CISA PDF is internally dated April 2024 even though it was published in May 2024.