The Update
NIST published a revised edition of Special Publication 800-81 — Secure Domain Name System (DNS) Deployment Guide — this week. SP 800-81-3 is the most comprehensive revision of NIST’s DNS security guidance since the previous edition and arrives amid renewed practitioner focus on DNS as both an attack surface and a detection capability.
DNS is foundational infrastructure that underpins virtually every network operation — name resolution for internal and external services, email authentication, certificate validation, and increasingly, security tooling that relies on DNS telemetry for threat detection. Yet in many organisations, DNS security configuration is treated as a one-time setup task rather than a subject of ongoing security assessment.
What Changed in SP 800-81-3
The updated publication expands guidance across several areas that have evolved materially since the previous version:
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT): The widespread deployment of encrypted DNS resolvers introduces both security benefits (protection of DNS queries from network-level interception) and security risks (circumvention of enterprise DNS monitoring and filtering). SP 800-81-3 provides guidance on enterprise DoH/DoT deployment policy, including when to allow, restrict, or intercept encrypted DNS traffic in corporate environments.
DNSSEC deployment: The guidance updates DNSSEC implementation recommendations to reflect current operational realities — including key rollover procedures, algorithm selection (favoring ECDSA P-256 and Ed25519 over older RSA key types), and delegation chain validation. DNSSEC adoption remains low in many enterprise environments despite its role in protecting against cache poisoning.
DNS as a detection capability: SP 800-81-3 expands the section on using DNS telemetry for threat detection — covering DNS-based command-and-control identification, domain generation algorithm (DGA) detection patterns, and integration of DNS logs into SIEM and threat intelligence workflows.
Cache poisoning resilience: The guidance addresses newer cache poisoning variants that exploit implementation weaknesses in resolver behaviour, including guidance on port randomisation, 0x20 encoding, and QNAME minimisation.
Resolver redundancy and resilience: Updated architecture guidance covers multi-provider DNS resilience, anycast deployment considerations, and protection against DNS infrastructure denial-of-service.
Why This Matters for Security Assessments
SP 800-81-3 provides a concrete framework for assessing current DNS security posture against updated standards. Security teams should use the revision as a checklist for identifying gaps in current deployment:
DNSSEC validation: Is your recursive resolver validating DNSSEC signatures? Many enterprise resolvers are configured to forward queries without performing DNSSEC validation, leaving the organisation vulnerable to attacks that inject forged DNS responses.
Internal DNS security: Are internal DNS zones properly segmented from external zones? Do internal DNS servers support zone transfer only to authorised secondary servers? Are internal DNS resolution paths protected from manipulation?
DoH/DoT policy: Has your organisation made an explicit decision about encrypted DNS in enterprise environments? Many organisations have no defined policy, leaving individual endpoint DNS behaviour uncontrolled.
DNS logging and monitoring: Is DNS query and response telemetry collected, retained, and monitored? DNS-based C2, data exfiltration via DNS tunnelling, and DGA-generated domains are all detectable through DNS telemetry analysis.
Recursive resolver exposure: Are recursive resolvers accessible from the internet? Open resolvers are a classic DDoS amplification risk and should be restricted to internal clients only.
Recommended Actions
- Download and review SP 800-81-3 against your current DNS architecture — use the document’s control checklists as a gap assessment framework
- Enable DNSSEC validation on all recursive resolvers if not already configured — most enterprise DNS products (Windows DNS, BIND, Unbound) support this
- Define an enterprise DoH/DoT policy: decide whether endpoints should use encrypted DNS, which resolvers are authorised, and how to maintain DNS visibility for security monitoring
- Enable DNS query logging if not already implemented — route logs to your SIEM and establish baselines for DGA detection and DNS tunnelling identification
- Audit zone transfer configurations — restrict AXFR/IXFR zone transfers to authorised secondary servers and verify no zones are accessible to unauthenticated external requesters
- Include DNS infrastructure in your next penetration test scope — DNS is frequently excluded from assessments despite being a high-value target for persistence and lateral movement