DNS Security
Posture Checklist

What to actually check, fix, and document against NIST SP 800-81r3 — the first update to the federal DNS security guide in over 12 years.

Published
March 2026
Reference
NIST SP 800-81r3
Author
Louis Sanchez
DNS security shield with network nodes and circuit paths representing DNS infrastructure protection

NIST published SP 800-81r3 on March 19, 2026, the first update to the federal DNS security guide in over 12 years. The philosophy behind it is a major shift: DNS is no longer just infrastructure to protect. It is an active security layer that should be protecting you. This checklist gives you the practical version: six areas to check against the new standard, with clear actions and a prioritization framework.

6 Areas to Check Against the New Standard

Each area includes specific items to verify, fix, or document in your environment.

1
Highest Priority

Protective DNS

Deploy a DNS resolver with threat intelligence that blocks malicious domains in real time. The single highest-impact DNS control per dollar.

2
Visibility Risk

Encrypted DNS Audit

DoT, DoH, and DoQ are all formally covered now. Browser DoH bypass is specifically called out as a risk that kills your DNS visibility.

3
Modernization

DNSSEC Crypto

The guide prefers ECDSA and Edwards-curve algorithms over RSA. Key rotation should be automated — manual management is the 2013 approach.

4
Immediate Risk

Dangling DNS Records

Subdomain takeover via dangling CNAME records is now a formally documented threat. First time NIST has addressed it explicitly.

5
Detection Gap

DNS Logs to SIEM

DNS query logs should feed your SIEM and correlate with DHCP lease history to map IPs to specific assets during incident response.

6
Validation

Architecture Review

The 2013 architectural recommendations are still valid, but worth confirming — especially after cloud migrations that quietly break clean separation.

What's Inside

Everything you need to assess your DNS security posture against the new standard.

Actionable Checklist Items

Specific questions to verify across all six areas — not abstract guidance, but concrete items you can check today.

Prioritization Framework

A ranked order for where to start based on risk reduction per dollar and per hour — so you fix the highest-impact gaps first.

New Threat Coverage

Protective DNS, subdomain takeover, and browser DoH bypass — the new threats NIST formally addressed for the first time.

NIST SP 800-81r3 Alignment

Every checklist item maps directly to the updated standard so you can document compliance and remediation plans.

Louis Sanchez - Founder of Voke Cyber and OSCP-certified penetration tester

About the Author

Louis is a penetration tester and the founder of Voke Cyber. He created this checklist to give security teams a practical way to assess their DNS posture against the new NIST standard — without wading through 100+ pages of federal guidance.

How Each Area Maps to Real-World Risk

Why these six areas matter beyond compliance.

1. Protective DNS — the highest-value control most teams skip

Protective DNS resolvers (Quad9, Cloudflare 1.1.1.1 for Families, Cisco Umbrella, NextDNS) block DNS lookups for known malicious domains in real time. CISA, the NSA, and the UK NCSC all recommend it as a baseline control. Deployment takes hours and the cost is often free for small organizations. We see this skipped most often when DNS is delegated to a managed services provider that prioritizes uptime over threat intelligence — ask your MSP what protective DNS resolver they're routing your queries through.

2. Encrypted DNS visibility — the trade-off most teams haven't made

DNS over HTTPS (DoH) and DNS over TLS (DoT) hide DNS queries from network observers — including your own SIEM. Modern browsers default to DoH, which routes around your DNS infrastructure entirely unless you configure them otherwise. The fix: enforce browser DoH bypass via Group Policy or MDM, ingest queries from your protective DNS provider's API, and document the policy decision so auditors see intentionality.

3. DNSSEC and modern crypto — automate before you sign

DNSSEC has historically failed because key rotation was manual and zone signing broke things. Modern providers (Cloudflare, Route 53, Google Cloud DNS, Azure DNS) automate signing and rotation entirely. If your registrar or DNS host doesn't support automated DNSSEC, switching providers is often easier than patching the workflow. Prefer ECDSA P-256 or Ed25519 over RSA — the smaller signatures fit in standard UDP responses and reduce TCP fallback.

4. Dangling DNS records — the audit no one runs

Subdomain takeover happens when a CNAME points to a deprovisioned cloud resource (Azure App Service, AWS S3 bucket, Heroku app, GitHub Pages site, Netlify, Webflow). An attacker registers the orphaned resource and serves content from your subdomain — phishing, malware delivery, brand damage, or full session hijacking depending on cookie scope. Run a one-time scan of every CNAME in your zones and add the audit to your offboarding runbook for any cloud service decommission. We cover the testing approach in the related External Penetration Testing service.

5. DNS logs to SIEM — the detection gap auditors love to find

DNS query logs are one of the highest-signal data sources for incident response. Beaconing, exfiltration over DNS, lateral movement, and command-and-control all leave DNS fingerprints. Yet most environments either don't capture queries or capture them and never wire them to the SIEM. Aim for 90 days of retention minimum, correlated with DHCP lease history to map source IPs to specific assets. If you don't have a SIEM, even a managed XDR with DNS visibility (Sentinel, Defender, CrowdStrike) is a step up.

6. Architecture review — does cloud migration still preserve separation?

The 2013 NIST guidance recommended split-horizon DNS, separate authoritative and recursive servers, and dedicated secondaries for resilience. After cloud migrations, those boundaries quietly collapse — managed DNS often combines roles, and "internal DNS" becomes synonymous with "VPC DNS." This is fine if intentional, but worth documenting. Many compliance frameworks expect a DNS architecture diagram; if you can't produce one in five minutes, your team should refresh the documentation.

"DNS is no longer something you protect. It is something you use to protect everything else."

Voke Cyber helps organizations understand their real attack surface, not just what a compliance checklist says. If your DNS posture has never been formally assessed, that is a conversation worth having.

Need Help With Your DNS Security Posture?

Our team can assess your DNS infrastructure against the new NIST standard and identify gaps before attackers do.