NIST SP 800-81r3: what the new DNS security guide changes
By CaptainDNS
Published on March 21, 2026
- NIST published SP 800-81r3 on March 19, 2026, the first update to the DNS security guide in 13 years
- Five major additions: Protective DNS, encrypted DNS (DoT/DoH/DoQ), Zero Trust, OT/IoT, and forensic logging
- Mandatory for U.S. federal agencies (Biden Executive Order), reference document for NIS2 compliance in Europe
- Stronger DNSSEC with QNAME minimization, Compact Denial-of-Existence, and migration to ECDSA
- Direct impact on email security: SPF, DKIM, and DMARC all rely on DNS integrity
- 6-step action plan to achieve compliance
On March 19, 2026, the National Institute of Standards and Technology published revision 3 of Special Publication 800-81, the federal reference guide for DNS security. The last update was in 2013: thirteen years during which the DNS landscape was transformed. Cloud explosion, Zero Trust architectures, industrialized ransomware, encrypted DNS (DoT, DoH, DoQ), massive IoT deployment. The 2013 document covered none of these topics.
The urgency of this revision is reflected in the numbers. According to IDC and Infoblox reports, 92% of malware uses DNS as a communication channel with its command-and-control (C2) servers. Between 88% and 90% of organizations have experienced at least one attack targeting their DNS infrastructure. The average cost per incident exceeds $1.1 million. In 2024, Infoblox's "Sitting Ducks" research revealed over 800,000 domains vulnerable to hijacking, with 70,000 already compromised. That same year, the KeyTrap vulnerability (CVE-2023-50387), a DNSSEC flaw that had remained dormant for 24 years, demonstrated that the foundations themselves needed reinforcement.
SP 800-81r3 spans 52 pages and completely restructures the doctrine around DNS operational roles (resolver, authoritative server, zone administrator) rather than SP 800-53 control families. The authors: Scott Rose (NIST), Cricket Liu and Ross Gibson (Infoblox). Beyond the U.S. federal scope, this guide is becoming an international reference. ENISA already cites it as an implementation document for the European NIS2 directive.
Does your domain meet the NIST recommendations?
13 years behind: why this revision was urgent
SP 800-81-2, published in September 2013, reflected a DNS landscape that was still largely unencrypted. DNSSEC existed but was still in its infancy. The concept of encrypted DNS had no RFC yet. Zero Trust was just an academic idea. Industrial IoT did not exist at today's scale.
Since 2013, the landscape has fundamentally changed. In 2016, RFC 7858 standardized DNS over TLS (DoT). In 2018, RFC 8484 introduced DNS over HTTPS (DoH). In 2022, RFC 9250 added DNS over QUIC (DoQ). In 2020, NIST itself published SP 800-207, the Zero Trust Architecture reference, without ever updating the DNS guide to incorporate that doctrine.
The evolution of attacks made the obsolescence untenable. The "Sitting Ducks" attack, documented by Infoblox in 2024, exploits orphaned DNS delegations to hijack domains without compromising the registrar. Out of the 800,000 domains identified as vulnerable, 70,000 had already been hijacked by cybercriminal groups (Vacant Viper, Horrid Hawk, Vextrio). That same year, the KeyTrap vulnerability (CVE-2023-50387) showed that a single specially crafted DNS packet could paralyze a DNSSEC resolver for several hours, a flaw present in the protocol since 1999.
On the DNSSEC adoption front, the numbers are stagnant. Roughly 35% of global domains are signed. In the United States, only 37% of .gov domains have full DNSSEC validation. SP 800-81-2 already recommended DNSSEC, but without providing sufficient operational guidance to achieve widespread deployment.
Another structural change: revision 3 abandons the alignment with SP 800-53 control families (AC, SC, AU) and organizes the document around DNS operational roles instead. This choice reflects feedback from infrastructure teams: a zone administrator does not think in terms of NIST controls, but in terms of daily tasks (zone signing, key rotation, resolver configuration).
The 5 pillars of NIST SP 800-81r3
Protective DNS: DNS as a defensive weapon
Protective DNS (PDNS) is the most significant addition in SP 800-81r3. The concept: transform the DNS resolver into an active filtering point, fed by threat intelligence feeds, to block resolutions to malicious domains in real time.
The mechanism relies on integrating Response Policy Zones (RPZ), blocklists maintained by security teams, and threat intelligence databases. When a workstation or server attempts to resolve a domain identified as malicious (phishing, C2, exfiltration), the PDNS resolver intercepts the query and returns a block response or redirects to a warning page.
SP 800-81r3 makes Protective DNS a formal recommendation, not just a best practice. This change in status has direct consequences for federal agencies, which will need to justify any DNS infrastructure lacking PDNS capabilities.
The stakes are considerable: if 92% of malware communicates with its command infrastructure via DNS, PDNS cuts that channel before the malware can even operate. The CISA Protective DNS program is already deployed across several agencies. Public resolvers like Quad9 (9.9.9.9) natively integrate PDNS capabilities. Commercial solutions (Infoblox BloxOne Threat Defense, Cisco Umbrella, Akamai Enterprise Threat Protector) add behavioral analysis and machine learning layers.
SP 800-81r3 does not prescribe a specific implementation. It requires that an organization's DNS resolvers have reputation-based domain filtering capabilities, with regular updates to threat intelligence sources.
Encrypted DNS enters the standard
SP 800-81r3 officially recommends using encrypted DNS protocols for traffic between the stub resolver (client) and the recursive resolver. This is a turning point from revision 2, which did not cover the topic at all.
The January 2025 Executive Order on strengthening cybersecurity accelerated the formalization. It requires federal agencies to deploy encrypted DNS within 180 days. SP 800-81r3 provides the technical framework for this mandate.
Three protocols are covered. DNS over TLS (DoT), defined by RFC 7858, uses dedicated port 853 and a TCP/TLS channel. It is the most mature protocol on the infrastructure side. DNS over HTTPS (DoH), defined by RFC 8484, runs on port 443, mixed with regular HTTPS traffic. It is widely deployed in browsers (Firefox, Chrome, Edge). DNS over QUIC (DoQ), defined by RFC 9250, combines the benefits of TLS with QUIC transport: no head-of-line blocking, 0-RTT resumption, and better mobility handling.
SP 800-81r3 also addresses the tension between encryption and network visibility. Encrypted DNS prevents DNS traffic inspection by traditional network equipment (firewalls, IDS/IPS). The document recommends combining encrypted DNS with Protective DNS: encryption protects query confidentiality on the network, while the PDNS resolver retains the visibility needed for filtering.
DNSSEC strengthened, not replaced
SP 800-81r3 confirms that DNSSEC remains the foundation of DNS integrity. Encrypted DNS protects transport confidentiality, but only DNSSEC guarantees the authenticity and integrity of responses. The two technologies are complementary, not interchangeable. Encrypting a lie does not make it true: without DNSSEC, a resolver cannot distinguish an authentic response from a forged one, even over an encrypted channel.
Revision 3 introduces three DNSSEC enhancements. The first is QNAME minimization (RFC 9156): instead of sending the full domain name to every authoritative server in the resolution chain, the resolver sends only the portion needed to progress. This reduces information leakage to intermediate servers.
The second is Compact Denial-of-Existence, an alternative to NSEC3 for proving that a domain does not exist. NSEC3 uses hashes to prevent zone enumeration, but remains costly in computation and bandwidth. Compact Denial-of-Existence simplifies the mechanism while preserving protection against enumeration.
The third is algorithmic migration. SP 800-81r3 recommends transitioning to ECDSA P-256 (algorithm 13) for new zones and encourages the gradual deprecation of RSA. ECDSA signatures are shorter (64 bytes versus 256 for RSA-2048), which reduces DNS response size and mitigates amplification risks.
The lessons from KeyTrap are incorporated. The document stresses the importance of regular resolver updates and monitoring security advisories related to DNSSEC. For a detailed understanding of how DNSSEC validation works, see our guide to the DNSSEC chain of trust.
Zero Trust: DNS as an enforcement point
SP 800-207 (Zero Trust Architecture), published in 2020, defines the principles of "never trust, always verify." SP 800-81r3 integrates DNS into this architecture by positioning the resolver as a Policy Enforcement Point (PEP).
In a Zero Trust architecture, every access request is evaluated based on context: user identity, device posture, network location, time of day. DNS is involved at the very first stage of network communication. Before a device establishes a TCP or TLS connection, it resolves a domain name. The resolver therefore becomes the first point where an access policy can be enforced.
SP 800-81r3 details how to segment DNS resolvers by trust zones. Internal network devices use a PDNS resolver with strict policies. Guest or BYOD devices go through a separate resolver with additional restrictions. Critical systems (OT, SCADA) have dedicated resolvers, isolated from the corporate network.
DNS signals are also leveraged to feed SIEM and SOAR systems. A spike in resolutions to newly registered domains (NRDs), unusual DNS queries (tunneling, exfiltration via TXT records), or a sudden change in resolution patterns can trigger automated alerts.
OT/IoT: securing DNS at the network edge
For the first time, an SP 800-81 document dedicates a section to operational technology (OT) environments and the Internet of Things. SP 800-81r3 is unambiguous: industrial equipment and connected devices are DNS blind spots in most organizations.
The constraints are real. Many IoT devices use minimal stub resolvers, incapable of validating DNSSEC or negotiating a TLS connection. Industrial controllers (SCADA, PLCs) operate on segmented networks with limited bandwidth and infrequent software updates. Some equipment only supports plaintext DNS over UDP port 53.
SP 800-81r3 recommends a layered approach. Since the devices themselves cannot encrypt or validate, security shifts to the infrastructure: dedicated PDNS resolvers for OT/IoT segments, DNS gateways that perform DNSSEC validation on behalf of clients, and centralized logging of DNS traffic from these segments to detect anomalous behavior. The document emphasizes isolation: an OT resolver must never be shared with the corporate network.
This pillar acknowledges a reality that previous guides ignored: in a world where a compromised temperature sensor can become the entry point for industrial ransomware, DNS is often the only observable signal.
DNS logging and forensics
This is the first time a NIST document in the SP 800-81 series details DNS logging requirements. Revision 2 briefly mentioned the topic. Revision 3 makes it a full pillar.
SP 800-81r3 specifies what must be logged at the resolver level: every query and every response, along with associated metadata. At a minimum: timestamp, source IP address, QNAME (queried domain name), QTYPE (query type: A, AAAA, MX, TXT), RCODE (response code: NOERROR, NXDOMAIN, SERVFAIL), and DNSSEC indicators (AD flag, validation status).
The document recommends direct integration of DNS logs into a SIEM. The forensic use cases are explicit: tracing attack chains through DNS resolutions (ransomware always resolves the C2 domain before downloading its payload), detecting data exfiltration via DNS subdomains (DNS tunneling encodes data in queries), and identifying staging domains used before an attack.
Log retention is addressed without prescribing a fixed duration. SP 800-81r3 recommends aligning retention with the organization's policy and applicable regulatory requirements (FISMA, NIS2, PCI DSS).
Passive DNS (pDNS) is also covered. It involves collecting observed DNS responses to build a resolution history. This history helps detect suspicious changes (a legitimate domain suddenly pointing to an IP at a bulletproof hoster) and correlate indicators of compromise. To set up continuous monitoring of your DNS records, see our guide to building resilient DNS monitoring.
What changed from revision 2
The table below summarizes the differences between SP 800-81-2 (2013) and SP 800-81r3 (2026).
| Topic | SP 800-81-2 (2013) | SP 800-81r3 (2026) |
|---|---|---|
| Encrypted DNS | Not covered | DoT, DoH, DoQ recommended |
| Protective DNS | Not covered | Formal recommendation |
| Zero Trust | Predates the concept | SP 800-207 integration |
| DNSSEC | Basic guidance | QNAME min., Compact DoE, algo migration |
| OT/IoT | Not covered | Dedicated section |
| Logging | Briefly mentioned | Detailed requirements, SIEM |
| Structure | Aligned with SP 800-53 | By operational roles |
| Authors | NIST alone | NIST + Infoblox |
Three points deserve attention. The co-authorship with Infoblox is unprecedented for an SP 800-81: it reflects NIST's intent to ground the document in operational reality rather than theory. The OT/IoT section acknowledges that industrial environments have specific constraints (embedded resolvers, limited bandwidth, inability to deploy DNSSEC on certain equipment). The restructuring by operational roles makes the document easier to navigate for infrastructure teams, who can focus on the sections relevant to their specific responsibilities.
Regulatory impact: who is affected?
U.S. federal agencies
For federal agencies, SP 800-81r3 is directly applicable under the Federal Information Security Modernization Act (FISMA). Each agency must align its DNS posture with the document's recommendations during its next assessment cycle.
The January 2025 Executive Order reinforces this obligation. It mandates the deployment of encrypted DNS within 180 days for all executive branch agencies. SP 800-81r3 provides the reference technical framework to satisfy this requirement.
The impact extends to cloud providers through FedRAMP. Any cloud service provider seeking FedRAMP authorization will need to demonstrate that its DNS infrastructure complies with SP 800-81r3 recommendations. This applies to AWS GovCloud, Azure Government, Google Cloud for Government, and all SaaS providers handling federal data.
The supply chain is also targeted. Federal agency contractors and subcontractors will need to align their DNS posture to retain their government contracts. SP 800-81r3 will become an evaluation criterion in federal procurement processes.
NIS2 directive
The NIS2 directive, in force since October 2024, requires essential and important entities to implement network security measures proportionate to their risks. DNS is explicitly covered by the directive's scope.
ENISA (the European Union Agency for Cybersecurity) cites SP 800-81 as a reference implementation document in its technical guides. The publication of SP 800-81r3 updates this reference. Organizations subject to NIS2 can rely on SP 800-81r3 to document their DNS posture before national authorities.
The sectors covered by NIS2 are broad: energy, transport, healthcare, water, digital infrastructure, financial services, public administration, space, food, chemicals, and research. Any organization in these sectors with more than 50 employees or more than 10 million euros in annual revenue potentially falls within scope.
NIS2 penalties are steep: up to 10 million euros or 2% of global annual revenue for essential entities, 7 million euros or 1.4% for important entities.
Private organizations
Companies outside the federal or NIS2 perimeter are not directly subject to SP 800-81r3. But the document is becoming a de facto standard through several indirect mechanisms.
Cyber insurers are increasingly incorporating DNS posture into their underwriting questionnaires. An organization unable to demonstrate PDNS capabilities, DNSSEC deployment, or DNS logging may be denied coverage or face higher premiums.
Supply chain pressure is also at play. If your clients are federal agencies or NIS2 entities, they will demand that their suppliers maintain a DNS posture aligned with SP 800-81r3. This requirement cascades down through the entire subcontracting chain.
Email security depends on DNS
SPF, DKIM, and DMARC are DNS records. A resolver validating a sender's IP address against an SPF record relies on the integrity of the DNS response. If an attacker poisons the resolver's cache and substitutes a forged SPF record, the entire email authentication chain collapses.
DNSSEC protects against this scenario. By signing MX, SPF (TXT), DKIM (TXT), and DMARC (TXT) records, DNSSEC ensures that the resolver validates authentic data. Without DNSSEC, an attacker capable of cache poisoning can spoof a domain's email identity, bypass DMARC policies, and send fraudulent emails on behalf of the target organization.
SP 800-81r3 highlights this dependency. It recommends treating email security and DNS security as inseparable. Deploying DMARC with a p=reject policy without enabling DNSSEC is like locking the front door while leaving the window open.
DANE (DNS-based Authentication of Named Entities) goes further. Through TLSA records protected by DNSSEC, DANE authenticates the TLS certificate of the destination mail server. This eliminates the dependency on third-party certificate authorities and ensures end-to-end encryption of SMTP transport.
MTA-STS provides an alternative when DNSSEC is not yet deployed on the domain. It uses HTTPS to publish a secure transport policy. SP 800-81r3 recommends both approaches, with a preference for DANE when DNSSEC is available.
Check now that your email authentication records are properly configured with our DMARC Checker.
Action plan: 6 steps to compliance
1. Audit your existing DNS infrastructure. Start with a complete inventory of your DNS zones, authoritative servers, and resolvers. Identify unsigned zones, resolvers without DNSSEC validation capability, and unencrypted DNS traffic. CaptainDNS can automate this verification.
2. Deploy DNSSEC on all zones. Sign every zone with DNSSEC, favoring the ECDSA P-256 algorithm (algorithm 13). Verify that DS records are correctly propagated to the TLD. Plan regular key rotation (ZSK every 3 months, KSK every 12 to 24 months). See our step-by-step guide to enabling DNSSEC for a deployment without service interruption.
3. Enable encrypted DNS. Deploy DoT on your internal resolvers to protect workstation traffic. For remote workers, configure DoH so that DNS queries travel over port 443, compatible with most public networks. Test DoQ if your resolver supports it, particularly for high-latency environments.
4. Implement Protective DNS. Evaluate PDNS solutions suited to your size: Quad9 as a filtering public resolver, RPZ on an internal resolver (BIND, Unbound, PowerDNS Recursor), or a commercial solution for larger organizations. Configure threat intelligence feeds and define a blocking policy (NXDOMAIN, redirect to an information page, or logging-only in observation mode).
5. Centralize DNS logs. Configure logging on every resolver and authoritative server. Export logs to your SIEM (Splunk, Elastic, Microsoft Sentinel) with the minimum fields recommended by SP 800-81r3: timestamp, source IP, QNAME, QTYPE, RCODE, and DNSSEC indicators. Define correlation rules to detect DNS tunneling, resolutions to NRDs, and SERVFAIL error spikes.
6. Secure the email chain. Validate that your SPF, DKIM, and DMARC records are correctly published and protected by DNSSEC. Deploy DANE (TLSA) on your mail servers if your DNS provider supports DNSSEC. Configure MTA-STS as a complementary measure. Enable TLS-RPT to receive reports on TLS negotiation failures.
FAQ
What is NIST SP 800-81r3?
NIST SP 800-81r3 is the third revision of the U.S. federal guide "Secure Domain Name System (DNS) Deployment Guide." Published on March 19, 2026 by the National Institute of Standards and Technology, it replaces revision 2 from 2013. The document covers all aspects of DNS security: DNSSEC, encrypted DNS (DoT, DoH, DoQ), Protective DNS, Zero Trust integration, logging, and OT/IoT environments.
Is SP 800-81r3 mandatory?
It is mandatory for U.S. federal agencies under FISMA and the January 2025 Executive Order on cybersecurity. For European organizations, it serves as an implementation reference within the NIS2 directive framework. For private companies, it is a de facto standard, increasingly required by cyber insurers and clients subject to regulatory obligations.
What is Protective DNS?
Protective DNS (PDNS) is a DNS resolver enriched with threat intelligence-based filtering capabilities. It blocks resolutions to domains identified as malicious (phishing, malware command and control, data exfiltration) in real time. The mechanism relies on Response Policy Zones (RPZ) and continuously updated threat intelligence feeds.
What is the difference between DoT, DoH, and DoQ?
DNS over TLS (DoT) uses a dedicated TCP/TLS channel on port 853. DNS over HTTPS (DoH) encapsulates DNS queries in HTTPS traffic on port 443. DNS over QUIC (DoQ) uses the QUIC protocol directly, combining TLS encryption with transport that avoids head-of-line blocking. DoT is the most mature on the infrastructure side, DoH the most widely deployed in browsers, and DoQ the most performant in variable-latency environments.
Is DNSSEC still recommended in 2026?
Yes. SP 800-81r3 reaffirms DNSSEC as the only technology that guarantees the authenticity and integrity of DNS responses. Encrypted DNS (DoT, DoH, DoQ) protects transport confidentiality but does not verify that the response actually comes from the legitimate authoritative server. The two technologies are complementary. SP 800-81r3 adds recommendations on QNAME minimization, Compact Denial-of-Existence, and migration to the ECDSA P-256 algorithm.
What is the link between DNS and email security?
SPF, DKIM, and DMARC are DNS records. Email validation relies on the recipient server querying these records. Without DNSSEC, an attacker can poison the DNS cache and substitute forged records, bypassing the entire email authentication chain. SP 800-81r3 recommends treating DNS security and email security as inseparable.
How long does it take to comply?
The timeline depends on existing maturity. An organization that already has DNSSEC and a centralized resolver can comply in 3 to 6 months. An organization starting from scratch should plan for 6 to 12 months for a full deployment covering DNSSEC, encrypted DNS, Protective DNS, and logging. The January 2025 Executive Order mandates a 180-day deadline for encrypted DNS in federal agencies.
Does SP 800-81r3 apply to SMBs?
SP 800-81r3 targets U.S. federal agencies, but its recommendations are relevant to any organization. European SMBs subject to NIS2 (more than 50 employees or 10 million euros in revenue in covered sectors) must document their DNS posture. SMBs outside the regulatory perimeter still benefit from a structured framework to prioritize their DNS security investments.
Glossary
- NIST: National Institute of Standards and Technology. U.S. federal agency that publishes the reference security standards and guidelines for the federal government.
- SP 800-81: Special Publication 800-81, the NIST guide for secure DNS deployment. Revision 3 (r3) is the version published on March 19, 2026.
- DNSSEC: Domain Name System Security Extensions. A set of extensions that add cryptographic signatures to DNS responses to guarantee their authenticity and integrity.
- DoT (DNS over TLS): DNS encryption protocol defined by RFC 7858. Uses a dedicated TLS channel on TCP port 853 between the client and the resolver.
- DoH (DNS over HTTPS): DNS encryption protocol defined by RFC 8484. Encapsulates DNS queries in HTTPS traffic on port 443.
- DoQ (DNS over QUIC): DNS encryption protocol defined by RFC 9250. Uses QUIC transport to combine encryption and performance (no head-of-line blocking, 0-RTT resumption).
- Protective DNS (PDNS): DNS resolver enriched with real-time filtering capabilities. Blocks resolutions to malicious domains using threat intelligence feeds.
- RPZ (Response Policy Zone): DNS mechanism that allows defining custom response policies. Used by PDNS resolvers to block or redirect queries to malicious domains.
- QNAME minimization: Technique (RFC 9156) that reduces the amount of information sent to intermediate authoritative servers during resolution. Only the portion of the name needed to progress in the resolution is sent.
- Zero Trust: Security model based on the principle of "never trust, always verify." NIST SP 800-207 defines the reference architecture.
- NIS2: European directive (2022/2555) on network and information security. In force since October 2024, it imposes cybersecurity obligations on essential and important entities.
- FISMA: Federal Information Security Modernization Act. U.S. law requiring federal agencies to implement security programs compliant with NIST standards.
