NIST updates its DNS security guidance for the first time in over a decade
DNS infrastructure underpins nearly every network connection an organization makes, yet security configurations for it have gone largely unrevised at the federal guidance level for more than twelve years. NIST published SP 800-81r3, the Secure Domain Name System Deployment Guide, superseding a version that dates to 2013.
The document covers three main areas: using DNS as an active security control, securing the DNS protocol itself, and protecting the servers and infrastructure that run DNS services. It is directed at two groups: cybersecurity executives and decision-makers, and the operational networking and security teams who configure and maintain DNS environments.
DNS as a security enforcement point
The updated guidance places significant emphasis on protective DNS, a term the document uses to describe DNS services enhanced with security capabilities that can analyze queries and responses and take action against threats. Protective DNS can block connections to malicious domains, filter traffic by category, and generate query logs that support digital forensics and incident response.
The document describes two general deployment models: cloud-based protective DNS services and on-premises deployments using DNS firewalls or Response Policy Zones (RPZs). A hybrid approach combining both is recommended where feasible, on the basis that a cloud outage with on-premises fallback still preserves protection.
Cricket Liu, EVP Engineering, Chief DNS Architect and Senior Fellow at Infoblox, which co-authored the publication, offered Help Net Security additional detail on RPZ deployment practice. “When deploying Response Policy Zones, one of the most common protective DNS mechanisms, we advise organizations to create a local RPZ to override RPZs that they might get from other organizations,” he said. “Organizations would typically use the local RPZ to whitelist their internal namespace, and then can add individual domain names to the whitelist that might be erroneously blocked.”
The guidance recommends that protective DNS logs be integrated with SIEM or log analysis platforms, and that DNS query data be correlated with DHCP lease histories to map IP addresses to specific assets during incident response.
Encrypted DNS changes the role of the DNS server
The publication dedicates substantial attention to encrypted DNS, covering three protocols: DNS over TLS (DoT), which runs on TCP port 853; DNS over HTTPS (DoH), which runs on TCP and UDP port 443; and DNS over QUIC (DoQ), which runs on UDP port 853. All three encrypt communication between stub resolvers and recursive DNS servers and optionally support server authentication.
The U.S. government requires Federal Civilian Executive Branch agencies to use encrypted DNS when communicating with agency endpoints, wherever technically supported. The guidance notes that organizations may need to configure browsers and other applications that implement their own encrypted DNS so that local resolvers used for control and logging are not bypassed.
Liu pointed to a structural consequence of encrypted DNS deployment that the guidance reinforces. “The DNS server itself becomes critical when encrypted DNS is deployed,” he said. “The DNS server becomes the detection and enforcement point. Additionally, organizations can retrieve and store Passive DNS data collected from its DNS servers, which allows them to detect threats, log responses, and more.”
The publication advises organizations to block unauthorized DoT traffic using firewall rules on TCP port 853, and to use RPZs combined with firewall rules to restrict unauthorized DoH traffic, which is more difficult to block given its use of port 443. Mobile device management tools are recommended for enforcing approved DNS configurations on endpoints.
DNSSEC guidance updated for current algorithms
The publication updates DNSSEC signing recommendations to reflect current cryptographic standards. It presents a table of supported algorithms drawn from RFC 8624 and NIST SP 800-57, covering RSA with SHA-256, ECDSA P-256 and P-384, and the Edwards-curve algorithms Ed25519 and Ed448. The document notes a preference for ECDSA and Edwards-curve algorithms over RSA, on the basis that smaller key and signature sizes help keep DNS response sizes within limits that avoid requiring TCP.
DNSSEC signing keys are categorized as signature keys with a recommended maximum lifetime of one to three years. The document recommends keeping RRSIG validity periods short, on the order of five to seven days, to limit the window during which a compromised key can be used to forge responses. Hardware security modules are recommended for storing private keys, particularly key-signing keys, where practical.
The guidance recommends NSEC over NSEC3 for authenticated denial of existence, noting that NSEC3’s computational overhead is generally not justified by the protection it provides against zone walking. Organizations required by policy to use NSEC3 are directed to RFC 9276 for parameter settings that reduce denial-of-service risk.
Post-quantum cryptographic algorithms are not yet specified for DNSSEC use. The document notes that administrators should plan to migrate once specifications and tooling are available.
Authoritative server hygiene and zone management
The guidance describes several threat categories specific to authoritative DNS services. Dangling CNAME records, in which a CNAME points to a domain no longer registered or controlled by the organization, can allow threat actors to take over resolution for that name. Lame delegations, where a subdomain is delegated to name servers that are no longer authoritative for it, create a similar exposure and can enable domain hijacking through a hosting provider.
The document recommends active monitoring of domain registrations to detect look-alike or typosquat domains. It also recommends that organizations maintain retired domain delegations in a parked state for a period of time to prevent re-registration by attackers.
TTL values are recommended in the range of 1,800 seconds (30 minutes) to 86,400 seconds (one day) for most DNS data. A TTL of zero is explicitly prohibited, and values below 30 seconds are discouraged for DNSSEC-signed records.
What the NIST DNS security guide covers on infrastructure architecture and availability
The publication repeats a recommendation from earlier versions that authoritative and recursive functions be separated on internet-accessible servers. An internet-facing name server configured for both functions is described as a security risk.
NIST recommends deploying at least two authoritative name servers on different network segments, and dispersing them geographically across different physical sites. A hidden primary authoritative server, one that does not appear in the zone’s NS record set, is recommended to reduce the primary server’s exposure to direct attack.
DNS servers should run on dedicated infrastructure, separate from other services, to reduce the attack surface and ensure adequate resources for logging, encrypted DNS, and protective DNS functions. Where full separation is not practical, combining DNS with closely related core services such as DHCP is described as an acceptable alternative.
Webinar: The True State of Security 2026