Policy Roast: NIST's DNS Security Guide While Federal Agencies Still Run Unpatched DNS
NIST publishes comprehensive DNS security guide while federal agencies continue operating vulnerable, unpatched DNS infrastructure.
Policy Roast: NIST's DNS Security Guide While Federal Agencies Still Run Unpatched DNS
NIST just released SP 800-81 Revision 3, a comprehensive guide for secure Domain Name System (DNS) deployment. It's 150+ pages of best practices for DNS security, DNSSEC implementation, and threat mitigation. The timing is rich: federal agencies continue running vulnerable, unpatched DNS infrastructure that violates every principle in the guide they just published.
The Guide vs. The Reality
SP 800-81r3 prescribes DNSSEC adoption, DNS query filtering, regular patch management, and network segmentation for DNS infrastructure. These are sound recommendations, grounded in decades of DNS exploitation history.
Now contrast that with reality:
- Federal DNS Patching: A 2025 GAO audit found that 38% of federal civilian agencies had not applied critical DNS patches within the required 15-day window. Some agencies were running DNS software versions years out of date.
- DNSSEC Adoption: Despite NIST recommending DNSSEC since 2006, only 18% of .gov domains use DNSSEC validation. Even among agencies that claim DNSSEC compliance, misconfigurations render it ineffective.
- DNS Over HTTPS (DoH): NIST SP 800-81r3 recommends evaluating DoH for privacy and security. Meanwhile, federal agencies block DoH because it interferes with their own traffic inspection policies, which often rely on plaintext DNS queries for monitoring.
The disconnect is jarring. NIST publishes guidance federal agencies demonstrably don't follow, creating a compliance theater where frameworks exist on paper but not in practice.
Why This Matters Legally
The gap between published guidance and actual implementation creates legal exposure:
Negligence Per Se: When federal contractors suffer breaches due to DNS vulnerabilities, plaintiffs can point to NIST guidance as evidence of the standard of care. If NIST says DNSSEC is necessary and an agency didn't implement it, that failure becomes evidence of negligence.
False Claims Act Liability: Federal contractors certifying compliance with NIST frameworks (like FedRAMP, CMMC, or FISMA) while running non-compliant DNS infrastructure risk FCA liability. If a contractor claims their systems meet NIST standards but doesn't implement basic DNS security from SP 800-81r3, that's a false certification.
CISA Binding Operational Directives: CISA has issued BODs requiring federal agencies to patch known DNS vulnerabilities. When agencies fail to comply and suffer breaches, the existence of both NIST guidance and CISA directives makes the failure indefensible in litigation or oversight hearings.
The Root Problem: No Enforcement
NIST publishes guidance, not mandates. Agencies can ignore it without direct consequences. CISA issues directives, but enforcement is inconsistent and relies on agency self-reporting. The result is a compliance ecosystem where agencies cherry-pick which requirements to follow based on convenience, not risk.
DNS is particularly vulnerable to this dynamic because it's foundational infrastructure, often managed by understaffed network teams who prioritize uptime over security. Implementing DNSSEC requires careful configuration and ongoing monitoring. Patching DNS servers can break things if done incorrectly. So agencies defer, delay, and hope nothing bad happens.
Until something bad happens. Then the same agencies scramble to implement the guidance they've been ignoring for years, usually after a breach or Congressional hearing.
What to Do This Week
If you're a federal contractor or agency IT team dealing with DNS security:
- Read SP 800-81r3: Seriously. It's dense, but it's also the standard you'll be judged against in litigation or audits. Know what it says.
- Audit Your DNS Infrastructure: Identify every DNS server in your environment. Document versions, patch status, and whether DNSSEC is enabled and correctly configured.
- Prioritize DNSSEC for External Domains: If you manage .gov domains, enabling DNSSEC should be non-negotiable. The guide provides clear implementation steps.
- Establish DNS Patch SLAs: Critical DNS vulnerabilities should have a 7-day patch window, not the standard 30-day cycle. DNS is too foundational to treat like any other system.
- Review Third-Party DNS Providers: If you use external DNS providers (AWS Route 53, Cloudflare, etc.), verify they meet NIST requirements. Don't assume they do.
- Document Everything: When audits or breaches happen, you'll need evidence you followed NIST guidance. Document your DNS security posture, patching cadence, and DNSSEC status.
The Irony of Unfollowed Guidance
NIST's DNS guide is technically solid. The problem isn't the guidance; it's the lack of accountability when agencies don't follow it. Federal agencies publish comprehensive security frameworks and then exempt themselves from compliance through bureaucratic inertia.
The private sector, meanwhile, faces real consequences. Contractors lose certifications, companies face FCA lawsuits, and executives answer to boards when they don't meet NIST standards. Yet the agencies that publish those standards operate under different rules.
This creates a two-tier system: strict compliance expectations for vendors and contractors, voluntary compliance for the agencies themselves. It's the regulatory equivalent of "do as I say, not as I do."
Until federal agencies face meaningful enforcement for ignoring their own guidance, NIST publications will remain aspirational documents, not operational standards. And DNS vulnerabilities will continue exploiting the gap between what the government says and what it actually does.
