Ninety-two percent of malware uses DNS to talk to its command-and-control servers. DNS threats grew 30% year over year. One in every 174 DNS requests is malicious. And until last week, the U.S. government's authoritative guidance on securing the protocol was from 2013.
NIST published SP 800-81r3 on March 19, 2026: the first major update to its Secure Domain Name System Deployment Guide in 13 years. The 52-page document repositions DNS from quiet infrastructure utility to active security control, covering everything from encrypted DNS protocols to Zero Trust integration to OT/IoT environments.
It is simultaneously the most important DNS security document in a decade and a guide that reveals just how wide the gap has become between where DNS security needs to be and where most organizations actually are.
What the Guide Actually Says
SP 800-81r3 is organized around five pillars: Protective DNS, Encrypted DNS, DNSSEC enhancements, Zero Trust integration, and OT/IoT environments. The biggest structural change from the previous revision is organizational: NIST abandoned the abstract SP 800-53 control family mapping and restructured everything around operational roles (resolver operator, authoritative server admin, zone administrator). This reflects feedback that the people actually managing DNS infrastructure think in daily tasks, not compliance frameworks.
The headline recommendation is that DNS resolvers should function as Policy Enforcement Points in a Zero Trust architecture. Protective DNS, whether cloud-based or on-premises using Response Policy Zones, becomes the first line of defense against malicious domains, phishing, and data exfiltration. As Cricket Liu, co-author and Chief DNS Architect at Infoblox, put it: "The DNS server becomes the detection and enforcement point."
Three encrypted DNS protocols are covered: DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). U.S. federal agencies face a 180-day deployment deadline for encrypted DNS under a January 2025 Executive Order. DNSSEC guidance now favors ECDSA and Edwards-curve algorithms over RSA (64-byte signatures versus 256 bytes), recommends NSEC over NSEC3 for authenticated denial of existence, and specifies key lifetimes of one to three years with signature validity periods of five to seven days.
DNS logging, previously a brief mention, is now a full pillar. Every query and response must be logged at the resolver level with specific metadata: timestamp, source IP, QNAME, QTYPE, RCODE, and DNSSEC validation status.
The Vendor Co-Authorship Question
Here is something no one is talking about enough: this NIST publication was co-authored by two Infoblox employees (Cricket Liu and Ross Gibson) alongside NIST's Scott Rose. This is unprecedented for the SP 800-81 series.
Infoblox is a major commercial DNS security vendor. The guide recommends protective DNS, RPZs, encrypted DNS monitoring, and comprehensive DNS logging, which are core capabilities in Infoblox's product suite. CaptainDNS called the collaboration "unprecedented" but stopped there. Major CDN and security vendors like Akamai are already aligning product messaging to the new standard.
To be clear: Cricket Liu is legitimately one of the world's foremost DNS experts. His book "DNS and BIND" is in its fifth edition and is a foundational reference. The recommendations in SP 800-81r3 are technically sound. But federal standards carry regulatory weight. When a vendor co-authors the standard that their products are positioned to fulfill, that deserves more scrutiny than it has received, particularly as cyber insurers begin incorporating DNS posture into underwriting questionnaires. Non-compliance could become grounds for claim denial, and the entity that helped write the compliance benchmark sells the compliance tools.
The Adoption Gap Nobody Wants to Acknowledge
The most damning number in the DNS security landscape is not about attacks. It is about defense: only 35% of global domains have DNSSEC deployed. Among U.S. .gov domains, where federal mandates have the most direct authority, the number is only marginally better at 37%.
DNSSEC has been available for over two decades. Twenty years of standards, guidance, vendor tooling, and government mandates have produced barely one-third adoption. That is not a knowledge problem. It is an operational complexity and incentive alignment problem.
SP 800-81r3 responds to this reality by adding more complexity: QNAME minimization, Compact Denial-of-Existence, algorithm migration guidance, encrypted DNS deployment, comprehensive logging requirements. Each recommendation is individually defensible. Collectively, they represent a significant expansion of what organizations need to implement, monitor, and maintain. The guide estimates three to six months for organizations with existing DNS maturity and six to twelve months for greenfield deployments.
This is the implementation gap pattern in its purest form: organizations have enough evidence to act but are not acting, and layering more guidance on top does not change the calculus. If most organizations cannot manage DNSSEC after 20 years, adding five more layers of DNS security requirements will not close the gap. It will widen it. The organizations that are already doing DNS security well will get better. The organizations that are not will fall further behind, and those are the ones adversaries target.
This is the same pattern we see across compliance-driven security. The HIPAA Security Rule overhaul faces similar dynamics: technically sound requirements that assume implementation capacity organizations do not have.
The Encrypted DNS Visibility Paradox
The guide's encrypted DNS recommendations create a tension it acknowledges but does not resolve. DNS over HTTPS routes queries through port 443, making them indistinguishable from normal web traffic. This is excellent for privacy. It is a nightmare for security monitoring.
The guide recommends blocking unauthorized DoH resolvers and routing all encrypted DNS through enterprise-controlled endpoints. In practice, identifying DoH traffic when it shares the same port and protocol as every HTTPS connection on your network borders on impossible without deep packet inspection at scale. Applications increasingly embed their own DoH resolvers, bypassing enterprise DNS infrastructure entirely.
This is where the DNS-as-enforcement-point vision collides with implementation reality. You cannot use DNS as a security control if you cannot see the DNS traffic. The guide positions encrypted DNS as essential (and it is, especially for federal agencies) while simultaneously acknowledging that encrypted DNS undermines the visibility that makes protective DNS effective. The resolution, centralizing all DNS through enterprise-controlled encrypted resolvers, requires the kind of network architecture control that many organizations, particularly those with sprawling edge device deployments, simply do not have.
What the Guide Misses Entirely
Two significant blind spots stand out.
First, there is no discussion of AI-generated domain threats. DNSFilter's research shows that over 65% of unique threat domains are newly registered, with adversaries optimizing for rapid deployment and constant rotation. Generative AI dramatically lowers the cost of creating convincing phishing domains at scale. Domain generation algorithms powered by large language models represent a category of threat where the guide's protective DNS recommendations, which rely on threat intelligence feeds, are inherently reactive. You cannot blocklist domains that do not exist yet.
This matters because the guide positions protective DNS as the primary defensive mechanism, but protective DNS is only as good as its threat intelligence. Against an adversary that can generate thousands of unique, convincing domains per hour, reactive blocklists become a game of whack-a-mole. The guide needed a section on DNS-layer detection of algorithmically generated domains, and it does not have one.
Second, post-quantum cryptography for DNSSEC is deferred entirely. The guide advises organizations to "plan migration once specifications and tooling become available," but NIST already finalized post-quantum cryptographic standards (FIPS 203, 204, 205) in 2024. PQC algorithms will dramatically increase DNSSEC key and signature sizes, potentially breaking UDP DNS response sizes and requiring protocol-level changes. Telling organizations to wait for tooling without providing any timeline or preparation guidance leaves them unable to plan for a migration that will be significantly more disruptive than the current algorithm transitions the guide does cover.
The Real Problem: DNS Security Is an Infrastructure Problem Disguised as a Standards Problem
NIST SP 800-81r3 is a good document. The technical guidance is sound. The restructuring around operational roles rather than compliance frameworks is a welcome improvement. The explicit integration of DNS into Zero Trust architecture reflects how modern security actually works.
But the guide cannot solve the fundamental problem: DNS security requires infrastructure investment, operational maturity, and sustained attention that most organizations do not allocate to something they still perceive as "just networking." The Sitting Ducks research found 800,000 domains vulnerable to hijacking and 70,000 already compromised. The average cost of a DNS attack is $1.1 million per incident. Despite these numbers, DNS security remains an afterthought in most security programs.
The organizations that will benefit most from SP 800-81r3 are the ones that were already investing in DNS security. For the rest, this guide joins the growing stack of federal security frameworks that are technically excellent and operationally aspirational.
What Security Leaders Should Actually Do
Rather than attempting to implement all five pillars simultaneously, prioritize based on threat exposure:
-
Deploy protective DNS first. This provides the highest security return with the lowest implementation complexity. Cloud-based protective DNS services can be operational in days, not months. Start blocking known-bad domains before worrying about encrypting the queries.
-
Instrument DNS logging before encrypting DNS traffic. You need visibility into your current DNS landscape before you encrypt it. Deploy logging with the metadata fields the guide specifies, build baselines, then layer encrypted DNS on top.
-
Treat DNSSEC as a supply chain problem. If your registrar and hosting providers do not support DNSSEC signing, switching providers is faster than waiting for them to catch up. Target your most critical zones first.
-
Audit for dangling CNAMEs and lame delegations now. These are DNS-specific attack vectors the guide highlights that require no new technology to fix, just attention. An afternoon of DNS hygiene eliminates hijacking risks that have been accumulating for years.
-
Watch the insurance angle. If your cyber insurer starts asking about DNS security posture, SP 800-81r3 becomes your compliance benchmark whether you planned for it or not. Get ahead of it.
The guide's own abstract says it plainly: "An attack against the DNS infrastructure of an enterprise threatens every network operation in that enterprise." After 13 years, NIST is finally treating DNS security with the seriousness it deserves. The question is whether organizations will do the same, or whether this guide will collect the same dust as its predecessor.
