I joined Network Solutions in 2001. At that point, registering a domain name was still a novel act for most businesses. The mental model was simple: pick a name, point it somewhere, pay the annual renewal. Security meant not letting it lapse. That was essentially the whole job.
The National Institute of Standards and Technology just published its updated Secure Domain Name System Deployment Guide, known as NIST SP 800-81r3. It is the first major revision since 2013. The timing is overdue. The threat landscape around domain infrastructure has changed significantly, and most organizations are still managing DNS with a 2001 mindset.
The Records You Add Are Fine. It Is What Protects Them That Needs Work.
Most people who manage a domain understand the basics. A records, CNAME records, MX records for email routing, TXT records for ownership verification and email authentication. That knowledge is still valid. What NIST is now asking organizations to think about is what happens to those records in transit, and what happens to the records they have forgotten about.
DNS Security Extensions, commonly called DNSSEC, adds a cryptographic signature to your zone records so that resolvers can verify an answer is genuine and has not been tampered with in transit. Without it, anyone on the path between a query and its response can theoretically forge an answer and redirect traffic. NIST's updated guidance moves the cryptographic recommendations forward, favoring ECDSA and Edwards-curve algorithms over RSA, and recommends keeping signature validity windows short, around five to seven days, to limit the damage window if a key is ever compromised.
Encrypted DNS is the second major area. Every time a device asks for the IP address of a domain, that query travels in plain text by default. DNS over HTTPS and DNS over TLS encrypt that conversation. The U.S. federal government now requires civilian agencies to use encrypted DNS wherever it is technically supported. For enterprise environments, the practical implication is also making sure that browsers and applications implementing their own encrypted DNS resolvers are not silently bypassing the organization's local resolver — the one used for logging, filtering, and incident response.
The Audit Nobody Does
The most immediately actionable part of the guidance has nothing to do with cryptography. It is about the records that already exist in your zone and have been sitting there unreviewed for years.
A dangling CNAME is a record that points to a domain or subdomain no longer registered or controlled by your organization. If that destination has expired, an attacker can register it and now resolves to a destination they control, under your domain name. Lame delegations work similarly: a subdomain delegated to a hosting provider you have since left creates the same exposure. NIST explicitly names both as attack vectors and recommends active monitoring. The fix is unglamorous — open your DNS console, go through every record, and delete anything pointing to a destination you no longer control.
There is also guidance on domains you retire. Simply letting a registration lapse is the wrong move. Old links, email configurations, partner integrations, and hardcoded references can survive for years. Once a domain lapses, anyone can register it. The guidance recommends parking retired domains rather than abandoning them, and maintaining any delegations in a controlled state for a transition period.
Protective DNS: DNS as a Security Control, Not Just a Routing Mechanism
The guidance devotes significant attention to what it calls protective DNS — DNS services that analyze queries and responses in real time and can block, filter, or flag based on threat intelligence. The concept has been in use for years under various vendor names, but this is the first time NIST has given it formal treatment in its DNS guidance. The document recommends integrating protective DNS logs with security information and event management platforms, and correlating DNS query data with Dynamic Host Configuration Protocol lease histories to map activity to specific assets during incident response.
The broader framing here matters. DNS sits at the foundation of zero trust architectures. Every connection request, every application call, every email delivery starts with a DNS query. That makes the DNS layer both a natural enforcement point for security policy and a natural signal source for detecting anomalous behavior. Organizations that treat DNS purely as plumbing are leaving a significant security visibility gap open.
When did you last audit every record in your DNS zone? Not add a record — audit the ones already there. For most organizations, the answer is never. That is the gap NIST SP 800-81r3 is asking you to close first, before any cryptographic upgrade.
