NIST’s secure DNS deployment guide: best practices

Executive summary: NIST published SP 800-81r3 on 19 March 2026, its first update to the Secure DNS Deployment Guide in 13 years. The new document is shorter (50 pages, down from 120) and shifts from platform-specific configuration advice to a strategic framework for enterprise DNS security.

The guide splits DNS security into three pillars. First, treating DNS as a security architecture component by centralizing resolution to enable query logging (for forensics and threat detection) and name resolution filtering (Protective DNS). Second, securing recursive servers by providing an encrypted internal recursive service, restricting access to public DNS, using QNAME minimization, and validating DNSSEC. Third, securing authoritative servers across five areas: protecting management interfaces, minimizing information leakage, maintaining DNS hygiene (stale NS/CNAME records are a hijack risk), monitoring for look-alike domains, and deploying DNSSEC for cryptographic integrity.

On 19 March 2026, NIST released a long-awaited update to their Secure DNS Deployment Guide (SP 800-81r3). DNS security is a topic very dear to my heart and I was very interested to see what’s new. The quick answer is—everything. Surprising? No, not really, because the previous version of this document was released in 2013, which is an impressive 13 years ago. The 2013 document was a product of its time. The 2026 document is as well, but the security landscape today is vastly different than it was back then. That explains the big differences. Let’s dive in.

The biggest change is conceptual. At about 120 pages, the previous version was longer and much more low level, often focused on configuration settings and specific platform details. The new version has been slimmed down, at about 50 pages, and focuses on the overarching strategy for securing enterprise DNS.

In fact, the job of securing DNS is now split across three aspects:

• DNS as part of security architecture
• Security of organization’s recursive servers
• Security of organization’s authoritative servers

Although never envisioned as a security control, over the years DNS actually became a critical part of every organization’s security architecture, stemming from the fact that every network service consumes it. The vast majority of services have to resolve domain names to IP addresses. Many of the threats use DNS as the delivery mechanism.

Thus, if DNS usage within an organization is centralized, we get two key benefits:

• DNS query logging provides DNS resolution records that are very valuable for digital forensics and incident response, which are critical for achieving better security as well as meeting regulatory requirements. Monitoring of DNS usage patterns is also useful for detecting data exfiltration and otherwise reacting to threats in real time.
• Name resolution filtering provides a useful client firewall that serves multiple purposes. First, it ensures that company content policies are uniformly applied. Second, and more important, it protects end users from threats such as phishing and malware. The core concept used here is sometimes referred to as Protective DNS.

Once you embed DNS into your security infrastructure, the next step is to secure DNS resolution across your estate. This is where it gets messy, because you need to ensure that all devices across your organization fall into line. This requires two steps:

• Provide an official recursive service for internal use. Providing a centralized service will enable you to build on the security architecture decisions, from the previous section. For best results, this recursive service should be encrypted, in order to protect the potentially sensitive DNS traffic from malicious actors on your internal networks.
• Restrict access to public DNS services in order to ensure that only the official service is used. This step is typically carried out via a Mobile Device Management (MDM) platform, which enables you to control the key operating system and application settings. Blocking some of the DNS ports is easy: port 53 is used by plaintext DNS, and port 853 is used by DNS-over-TCP (DoT) and DNS-over-QUIC (DoQ). Blocking DNS-over-HTTPS (DoH) is far from easy, because it’s used over port 443, which is the same as the rest of the Web. Although this is not an easy task, organizations will typically rely on their vendors for a solution.

Your recursive service has the potential to leak information via the traffic that exits into the public internet. Features such as encryption of outbound DNS traffic and QNAME minimization should be used to improve privacy. DNSSEC validation should be used to ensure that the received information hasn’t been tampered with.

Your recursive servers can be attacked, just as any other part of your infrastructure. DNS cache poisoning attacks have seen a resurgence in 2025 and 2026, and remain an attack vector that should be considered as a threat.

The final step to robust DNS health is to secure your authoritative servers. We’re looking at five distinct areas of activity:

• Protect management interfaces. Your authoritative servers have to be on the public internet to be useful, but your management interfaces should be protected. Some functionality, such as zone transfers and dynamic updates, shouldn’t be exposed to the public in order to minimize your attack surface. If you outsource your DNS to a managed provider, they’ll deal with the security aspects. If you want to hang onto your primary, it’s best if it’s entirely hidden from the public and available only to the secondaries. If you do this, it’s less likely that you’ll be a victim of a DoS attack.
• Minimize information leakage. By definition, the purpose of DNS is to communicate information to the public, but DNS zones often include information that’s not strictly necessary but can be abused by unsavory characters. Review what’s in there periodically and remove the information not vital for your services. Because of services such as passive DNS monitoring and Certificate Transparency, your subdomains are more visible than you might think. Wherever possible, separate public from internal domains, and keep the latter private.
• Maintain DNS hygiene. At the very least, ensure your DNS is operational. It’s possible that you have DNS that works, but provides stale information, which is a condition that can be often abused. For example, stale NS records could be used to hijack the entire domain. Stale CNAME records can be used to hijack individual services. There are a plethora of ways in which things can break, including misconfiguration, where the data is plainly wrong, and zone drift, where the secondaries are not keeping up with the primary.
• Monitor for look-alikes. When it comes to cybercrime, it’s a common attack technique to register domain names that are similar to yours and use them to attack your employees, customers, vendors, and partners. Monitoring for infringing names and acting quickly to take them down is necessary to ensure security.
• Use DNSSEC for integrity. DNS, by itself, is not secure. Packets can be intercepted as they travel across the network, and modified. Attacks such as DNS cache poisoning can be used to inject invalid data into recursive name servers. As we’ve already seen, to encrypt the DNS traffic you need to use protocols such as DoT, DoH, and DoQ. For real integrity backed by cryptography, you need DNSSEC.

At Red Sift, our focus is on cybersecurity defense, and DNS is a major part of that. We provide continuous infrastructure discovery and monitoring in our Attack Surface Management product, which provides functionality for DNS hygiene (or DNS Posture Management, if you prefer) monitoring. Our Brand Trust offering provides comprehensive monitoring for look-alike domain names. Get in touch to see how we can help you improve your security posture.

1. Treat DNS as part of security architecture

• Maintain a DNS audit log for forensics and threat detection
• Build a protective layer with name resolution filtering

2. Secure recursive servers

• Provide an internal recursive service
• Encrypt your outbound DNS traffic
• Use QNAME minimization
• Validate DNSSEC
• Prevent access to public DNS services

3. Secure authoritative servers

• Protect management interfaces
• Hide your primary name servers
• Minimize information leakage
• Maintain DNS hygiene
• Monitor for look-alikes
• Use DNSSEC to ensure integrity