NIST Just Rewrote the DNS Security Playbook After 12 Years. Here's What Changed.

On March 21, 2026, NIST published SP 800-81 Revision 3, the first major update to their DNS security guidance since 2013. That is 12 years between revisions for one of the most foundational layers of internet infrastructure.

The shift in tone is significant. The 2013 version treated DNS as plumbing: configure DNSSEC, set up TSIG for zone transfers, move on. Revision 3 treats DNS as an active security enforcement layer, one that should be blocking threats, feeding your SIEM, and getting audited just like your firewall rules.

Here are the six most important changes and what you should do about each one.

1. Protective DNS Is Now a Formal Recommendation

Protective DNS (PDNS) has existed as a concept for years, but NIST has now formally endorsed it as a recommended security control for enterprises.

PDNS works by inspecting DNS queries in real time and blocking resolution of domains associated with malware, phishing, command-and-control infrastructure, and data exfiltration. It stops threats before a TCP connection is ever established.

Think of it as a firewall that operates at the DNS layer. Your endpoint tries to resolve malware-c2-server.xyz, and the PDNS resolver returns a block page or NXDOMAIN instead of the real IP.

What to do:

• If you are not using a PDNS provider, evaluate options like Cloudflare Gateway, Cisco Umbrella, or the CISA Protective DNS service
• If you already use one, verify that block lists are current and that bypass is not possible via hardcoded DNS servers in application configs
• Log blocked queries. Every blocked resolution is a signal worth investigating

2. Encrypted DNS Creates Blind Spots You Need to Close

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt DNS queries between clients and resolvers. This is good for user privacy. It is a problem for enterprise security visibility.

When a browser or application resolves DNS through an external DoH provider (Cloudflare's 1.1.1.1, Google's 8.8.8.8), your on-network DNS monitoring never sees those queries. Your Protective DNS filters get bypassed entirely. Your SIEM has no DNS telemetry for that traffic.

NIST's guidance is direct: enterprises should operate their own DoH/DoT resolvers internally and block outbound encrypted DNS to external providers.

What to do:

• Deploy internal DoH/DoT resolvers so clients get encryption without bypassing your DNS controls
• Block outbound traffic to known public DoH/DoT endpoints at the firewall level
• Audit browser configurations. Firefox, Chrome, and Edge all support DoH and may enable it by default
• Update your network monitoring to account for encrypted DNS traffic patterns

3. DNSSEC Is Not Optional Anymore

DNSSEC adoption has stalled. Roughly 40% of .com domains have it enabled, and validation failures are still common enough that some resolvers soft-fail rather than hard-fail on bad signatures.

NIST's updated guidance strengthens the DNSSEC recommendation considerably. The new revision calls for:

• Full DNSSEC signing on all authoritative zones you control
• Validation enabled on all recursive resolvers
• Automated key rotation (no more manual KSK rollovers)
• Monitoring for signature expiration and validation failures

The argument against DNSSEC has always been operational complexity. NIST acknowledges this and specifically recommends automation to reduce the maintenance burden. If you are managing DNSSEC manually, you are doing it the 2013 way.

What to do:

• Enable DNSSEC signing on all domains you control. Most registrars and DNS providers now support one-click DNSSEC
• Enable DNSSEC validation on your recursive resolvers
• Automate key rotation. Tools like Cloudflare, Route 53, and Google Cloud DNS handle this natively
• Monitor for DNSSEC validation failures in your resolver logs

4. Dangling DNS Records Are Now a Named Threat

Subdomain takeover via dangling DNS records has been a well-known attack vector for years, but this is the first time NIST has formally addressed it in their DNS security guidance.

A dangling record is any DNS record that points to a resource you no longer control:

• A CNAME pointing to a deprovisioned Azure or AWS endpoint
• An A record pointing to a released IP address
• A CNAME pointing to a deleted GitHub Pages site or S3 bucket

An attacker claims the orphaned resource, and your DNS record now serves their content on your domain. This is not theoretical. Subdomain takeover attacks happen regularly and are trivial to execute once a dangling record is found.

What to do:

• Audit all DNS records for your domains. Compare every CNAME, A, and AAAA record against your current infrastructure inventory
• Remove records that point to decommissioned resources immediately
• Build a process for DNS record cleanup into your infrastructure decommissioning workflow
• Monitor for new dangling records continuously. Infrastructure changes happen fast, and a quarterly audit is not enough

5. DNS Logs Need to Feed Your SIEM

The 2013 guidance mentioned DNS logging. The 2026 revision goes much further, positioning DNS query logs as a first-class security telemetry source that should be integrated with your SIEM and incident response workflows.

DNS logs reveal patterns that other telemetry sources miss:

• Spikes in NXDOMAIN responses (often indicates malware probing)
• Queries to newly registered domains (common indicator of phishing infrastructure)
• Unusual query volumes from specific hosts (potential data exfiltration via DNS tunnelling)
• Resolution attempts for known-bad domains that PDNS blocked

If your DNS logs are sitting in a file on your resolver and nobody looks at them, you are missing one of the most valuable signals in your security stack.

What to do:

• Forward DNS query logs to your SIEM (Splunk, Elastic, Sentinel, etc.)
• Build detection rules for common DNS-based indicators: high NXDOMAIN rates, DGA-pattern domains, DNS tunnelling signatures
• Correlate DNS data with endpoint and network flow data for richer investigation context
• Retain DNS logs for at least 90 days to support incident investigation timelines

6. Zero Trust Architectures Need DNS Controls

NIST explicitly connects DNS security to Zero Trust architecture in the new revision. In a Zero Trust model, every network transaction is verified, and DNS is no exception.

The guidance recommends:

• DNS query validation as part of micro-segmentation policy enforcement
• Per-client DNS policies based on identity and device posture
• DNS as a policy enforcement point, not just a resolution service

This aligns DNS with the broader Zero Trust principles in NIST SP 800-207. If you are implementing Zero Trust and your DNS layer is wide open, you have a gap.

What to do:

• Include DNS controls in your Zero Trust architecture planning
• Evaluate DNS solutions that support per-client or per-group policies
• Ensure DNS queries from segmented networks only reach approved resolvers
• Treat DNS as a policy enforcement point alongside your firewall, proxy, and identity provider

Practical Checklist

Here is a condensed checklist you can use to assess your current DNS security posture against the new NIST guidance:

How StackShield Helps

StackShield already monitors several of the areas NIST highlights in this revision. Every scan checks your DNS configuration for:

• DNSSEC validation: Verifies that your domain has DNSSEC properly configured and that signatures are valid
• Dangling CNAME detection: Identifies DNS records pointing to resources that return errors or are unclaimed
• DNS security headers: Checks for CAA records and proper DNS-based email authentication (SPF, DKIM, DMARC)
• SSL/TLS certificate monitoring: Catches expiring certificates that could indicate abandoned subdomains

If you are not sure where your DNS security stands, run a free scan and get a baseline in under 60 seconds.

Further Reading

• NIST SP 800-81r3: Secure Domain Name System (DNS) Deployment Guide
• NIST SP 800-207: Zero Trust Architecture
• CISA Protective DNS Service
• OWASP DNS Security Cheat Sheet