DNS is no longer just the invisible system that turns a domain name into an IP address. In 2026, DNS has become a core part of cybersecurity, brand protection, email authentication, and online trust.
That is exactly why NIST published SP 800-81 Revision 3, officially titled Secure Domain Name System (DNS) Deployment Guide, in March 2026. The updated guide explains how organizations should secure DNS infrastructure, protect DNS data, reduce misconfiguration, and use DNS as part of a broader zero trust and defense-in-depth security strategy.
For domain owners, this update matters because your DNS records control where your website loads, how your email is authenticated, how subdomains resolve, and how users reach your online services. A single weak DNS configuration can lead to phishing, domain hijacking, email spoofing, broken websites, or brand impersonation.
This guide explains what NIST SP 800-81r3 means in practical terms and what domain owners should focus on in 2026.
What Is NIST SP 800-81r3?
NIST SP 800-81r3 is the latest revision of NIST’s DNS security deployment guide. It provides recommendations for securing DNS protocols, DNS servers, authoritative DNS services, recursive DNS services, DNSSEC, encrypted DNS, and protective DNS. NIST describes DNS as an integral part of enterprise network architecture and warns that attacks against DNS infrastructure can threaten network operations.
The major shift in this revision is that DNS is treated as more than a background technical service. NIST now frames DNS as a foundational security control that can support zero trust, defense-in-depth, incident response, and policy enforcement.
In simple words: DNS is not only about “where does this domain point?” It is also about “Can this domain be trusted, monitored, protected, and verified?”
Why Domain Owners Should Care
Even if you are not running a large enterprise network, your domain depends on DNS for almost every important online function.
Your DNS controls:
- Website routing through A, AAAA, and CNAME records
- Email delivery through MX records
- Email authentication through SPF, DKIM, and DMARC records
- DNSSEC validation through DS, DNSKEY, and RRSIG records
- Subdomain behavior across hosting platforms, SaaS tools, landing pages, CDNs, and mail services
- Brand trust, because attackers often abuse DNS misconfigurations to impersonate legitimate organizations
NIST specifically warns that misconfigured or stale CNAME records and name server delegations can allow attackers to take control of external-facing domains. It also notes that attackers commonly register look-alike domains to trick users into believing they are interacting with a legitimate organization.
That means DNS security is not only an IT issue. It is also a business continuity, brand protection, email security, and customer trust issue.
The Biggest Change: DNS Is Now a Security Control
The most important message in NIST SP 800-81r3 is that DNS should be part of an organization’s active security strategy.
NIST explains that DNS can help prevent malicious communication before it starts because DNS queries usually happen before a browser, app, or device connects to a destination. This makes DNS useful for blocking dangerous domains, detecting suspicious activity, supporting digital forensics, and improving zero trust visibility.
For domain owners, this means your DNS setup should be reviewed with the same seriousness as SSL certificates, website security, email authentication, and hosting security.
A modern DNS security posture should answer these questions:
- Are our DNS records accurate and up to date?
- Is DNSSEC enabled and correctly configured?
- Are abandoned subdomains removed?
- Are old CNAME records still pointing to third-party services we no longer use?
- Are our authoritative name servers resilient?
- Are DNS changes monitored?
- Are SPF, DKIM, DMARC, and related TXT records valid?
- Are look-alike domains being monitored?
- Do we have a plan if DNS is hijacked or misconfigured?
1. Protective DNS: Blocking Threats Before Connections Begin
One of the strongest themes in NIST SP 800-81r3 is protective DNS.
Protective DNS is DNS with security capabilities added on top. It can analyze DNS queries and responses, block known malicious domains, prevent malware and phishing connections, enforce policy, and generate logs for security teams. NIST says protective DNS can be delivered by a vendor, deployed internally, or used in a hybrid model.
For domain owners, protective DNS is especially useful when managing company networks, employee devices, remote teams, or business systems. It can help stop users from reaching malicious domains before the actual web or app connection begins.
What should domain owners do?
Domain owners and website administrators should:
- Use a trusted DNS resolver with security filtering.
- Avoid allowing unmanaged devices to use random public DNS providers.
- Log malicious DNS blocks when possible.
- Review DNS queries for unusual patterns.
- Use protective DNS for office networks, remote endpoints, and sensitive systems.
- Combine DNS protection with email security, endpoint protection, and web security.
Protective DNS does not replace good website security, but it adds an early layer of defense.
2. DNSSEC: Protecting the Integrity of DNS Data
DNSSEC is one of the most important DNS security technologies discussed in NIST SP 800-81r3.
NIST explains that DNSSEC adds source authentication and integrity protection to DNS data. It helps DNS clients verify that DNS responses have not been tampered with. However, NIST also makes an important distinction: DNSSEC protects the integrity of DNS data, but it does not protect the confidentiality of DNS queries. For confidentiality, encrypted DNS protocols such as DoH, DoT, or DoQ are needed.
For domain owners, DNSSEC helps reduce the risk of DNS spoofing, cache poisoning, and unauthorized DNS response manipulation.
What should domain owners check?
A practical DNSSEC checklist includes:
- Confirm that your registrar supports DNSSEC.
- Confirm that your DNS hosting provider supports DNSSEC signing.
- Enable DNSSEC for your authoritative zone.
- Publish the correct DS record at the registrar.
- Verify DNSKEY, DS, and RRSIG records.
- Monitor DNSSEC validation after every DNS provider migration.
- Plan DNSSEC key rollovers carefully.
- Avoid misconfigured DNSSEC records because they can make a domain fail validation.
NIST also notes that DNSSEC signing and validation depend on accurate time. DNSSEC signers and validating recursive servers need reliable time sources to verify signatures correctly.
Before making DNSSEC changes, domain owners should test records carefully. HasheTools provides DNS lookup guidance for checking DNSKEY and RRSIG records, and its DS Lookup tool can help verify DS records used for DNSSEC validation.
3. Encrypted DNS: Improving DNS Privacy and Reducing Tampering
NIST SP 800-81r3 also highlights encrypted DNS protocols, including:
- DoH: DNS over HTTPS
- DoT: DNS over TLS
- DoQ: DNS over QUIC
These protocols encrypt DNS communication between clients and recursive DNS servers. NIST explains that encrypted DNS can help protect sensitive DNS information from exposure or manipulation and reduce risks such as spoofing and machine-in-the-middle attacks.
However, encrypted DNS must be managed carefully. If browsers or devices bypass approved resolvers and use their own encrypted DNS providers, organizations may lose DNS visibility, logging, and policy enforcement. NIST recommends restricting endpoints to authorized DNS services wherever possible and blocking unauthorized DNS paths where appropriate.
What this means for domain owners
For website owners, encrypted DNS is mostly relevant in two areas:
First, it affects how users and employees resolve domains. If you run a business network, you should define approved DNS resolvers instead of allowing unmanaged DNS behavior.
Second, it reinforces the idea that DNS privacy and DNS integrity are separate issues. DNSSEC proves that DNS data has not been tampered with. Encrypted DNS protects the DNS transaction from being easily observed or modified in transit. A mature DNS security strategy may need both.
4. Authoritative DNS Must Be Hardened
Your authoritative DNS is the source of truth for your domain. If attackers compromise it, they can redirect your website, intercept traffic, break email, or abuse your domain reputation.
NIST recommends a resilient authoritative DNS architecture, including multiple authoritative name servers, network and geographic diversity, and secure primary-secondary configurations. It also recommends using a hidden primary server when an organization hosts its own zone information, with only secondary servers visible publicly.
NIST also warns that zone transfers should be restricted. Zone transfers can be useful for replication, but if they are exposed or misconfigured, they may leak DNS data or create denial-of-service risks. NIST recommends access controls, secure authentication methods such as TSIG, and confidentiality protections such as TLS where appropriate.
What should domain owners do?
Domain owners should:
- Use reputable, authoritative DNS providers.
- Keep at least two authoritative name servers.
- Avoid hosting DNS on a single fragile server.
- Disable public zone transfers unless specifically required.
- Restrict zone transfers to trusted secondary servers.
- Use TSIG or equivalent controls for DNS server-to-server updates.
- Separate authoritative DNS from recursive DNS where possible.
- Protect registrar and DNS provider accounts with MFA.
- Limit who can edit DNS records.
- Keep a record of every DNS change.
Most small businesses use managed DNS providers rather than self-hosted authoritative DNS. Even then, the same principles apply: choose reliable providers, restrict access, monitor changes, and remove stale records.
5. Dangling CNAMEs and Lame Delegations Are Serious Risks
One of the most practical parts of NIST SP 800-81r3 for domain owners is its warning about stale DNS records.
A dangling CNAME happens when a subdomain points to a third-party service that is no longer active or controlled by the domain owner. If the third-party resource can be claimed by someone else, an attacker may be able to take over that subdomain.
NIST warns that CNAME records can be exploited when the target domain or IP address is no longer controlled by the rightful organization. It recommends regularly monitoring domain configurations and deleting CNAME records when they are no longer needed.
A lame delegation can also create risk. NIST explains that if a subdomain is delegated to a DNS hosting provider and that service relationship lapses, attackers may be able to hijack resolution for that subdomain.
What domain owners should audit?
Review your DNS zone for:
- Old CNAMEs pointing to unused SaaS platforms
- Landing page tools are no longer in use
- Unused staging or development subdomains
- Old CDN records
- Expired hosting platforms
- Forgotten client portals
- Abandoned helpdesk or documentation subdomains
- NS records delegating subdomains to inactive providers
- TXT records from old verification processes
- SPF includes services you no longer use
A clean DNS zone is easier to secure, easier to troubleshoot, and less attractive to attackers.
6. TTL Values Should Be Practical, Not Random
TTL, or time to live, controls how long DNS records stay cached. Very low TTL values can increase DNS query load, while very high TTL values can delay important changes.
NIST recommends that TTL values should generally be in the range of 1800 seconds to 86400 seconds, or roughly 30 minutes to 1 day, for most DNS data. It also warns that TTL values of zero should not be used, and that very low TTL values can cause problems, especially with DNSSEC-validating caches.
Practical TTL guidance for domain owners
Use lower TTLs before:
- Website migrations
- DNS provider changes
- Email provider migrations
- CDN changes
- DNSSEC key changes
- Emergency incident response
Use stable TTLs for:
- Long-term website records
- MX records
- Verification records
- Records that rarely change
A good rule is to lower TTLs before a planned change, complete the change, verify everything, and then raise TTLs back to a stable value.
7. DNS Logging and Monitoring Are Now Essential
NIST emphasizes that DNS data can support incident response, security monitoring, and zero trust decision-making. Protective DNS logs can reveal blocked domains, suspicious queries, unusual traffic patterns, and possible malware activity. NIST also recommends integrating protective DNS with the broader security ecosystem through SIEM/SOAR tools, APIs, and threat intelligence workflows.
For domain owners, this means DNS should not be a “set it and forget it” system.
You should monitor:
- DNS record changes
- Registrar account logins
- Name server changes
- DS record changes
- MX record changes
- SPF, DKIM, and DMARC changes
- New subdomains
- Suspicious CNAME targets
- Unexpected TXT records
- Failed DNSSEC validation
- Unauthorized zone transfer exposure
DNS monitoring is especially important for agencies, SaaS businesses, ecommerce sites, financial services, healthcare organizations, and any brand that depends heavily on email trust.
2026 DNS Security Checklist for Domain Owners
Use this checklist to align your domain security with the spirit of NIST SP 800-81r3.
| Area | What to Check | Why It Matters |
| DNSSEC | DS, DNSKEY, RRSIG, validation status | Helps protect DNS data integrity |
| Authoritative DNS | Name server redundancy and provider security | Reduces outage and hijacking risk |
| CNAME Records | Remove unused third-party targets | Prevents subdomain takeover |
| NS Delegations | Check delegated subdomains | Prevents lame delegation hijacking |
| TTLs | Use practical TTLs, avoid zero TTL | Improves stability and change control |
| Email DNS | SPF, DKIM, DMARC, MX records | Prevents spoofing and delivery issues |
| DNS Access | MFA, least privilege, change logs | Reduces unauthorized changes |
| Zone Transfers | Disable public AXFR | Prevents data leakage |
| Monitoring | Track DNS changes and suspicious records | Enables faster incident response |
| Look-Alike Domains | Monitor typosquats and homoglyphs | Protects brand reputation |
How HasheTools Can Help
HasheTools.com can be part of a practical DNS review workflow. Domain owners can use DNS lookup and related checks to review DNS records, inspect DNSSEC signals, verify DS records, and identify issues in email authentication records such as SPF, DKIM, and DMARC. HasheTools’ own DNS guidance notes that users can check full DNS record stacks, security-related records, and DNS propagation behavior.
A simple monthly workflow could look like this:
- Run a DNS lookup for your main domain.
- Check A, AAAA, CNAME, MX, TXT, NS, and SOA records.
- Verify SPF, DKIM, and DMARC records.
- Check DNSSEC-related records such as DS, DNSKEY, and RRSIG.
- Review old CNAMEs and subdomains.
- Confirm your name servers match your intended DNS provider.
- Document any changes made during the review.
This is not a replacement for a full security audit, but it is a strong starting point for reducing common DNS risks.
FAQs
What is NIST SP 800-81r3?
NIST SP 800-81r3 is the 2026 revision of NIST’s Secure Domain Name System Deployment Guide. It provides recommendations for securing DNS infrastructure, DNSSEC, encrypted DNS, protective DNS, authoritative DNS, and recursive DNS services.
Does NIST SP 800-81r3 apply to small domain owners?
Yes. While much of the document is written for enterprises and security teams, many recommendations are useful for any domain owner, including DNSSEC validation, removing stale DNS records, securing authoritative DNS, monitoring CNAMEs, and protecting email-related DNS records.
Is DNSSEC enough to secure a domain?
No. DNSSEC helps protect the integrity and authenticity of DNS data, but it does not encrypt DNS queries. NIST explains that DNSSEC and encrypted DNS solve different problems, so DNSSEC should be treated as one part of a broader DNS security strategy.
What is protective DNS?
Protective DNS is DNS enhanced with security features that analyze queries and responses, block malicious domains, enforce policy, and support security monitoring. NIST describes it as a way to block malware, phishing, ransomware, spyware, and other attacks at the DNS layer.
What DNS records should domain owners review in 2026?
Domain owners should regularly review A, AAAA, CNAME, MX, TXT, NS, SOA, DS, DNSKEY, and RRSIG records. They should also check SPF, DKIM, and DMARC records because these email security controls depend on DNS.
Final Thoughts
NIST SP 800-81r3 makes one thing clear: DNS security is no longer optional.
For domain owners, DNS is directly connected to website availability, email trust, brand protection, phishing prevention, and customer confidence. The new NIST guidance encourages a more mature approach: use DNSSEC for integrity, encrypted DNS for privacy, protective DNS for threat prevention, resilient authoritative DNS for availability, and regular DNS audits to prevent misconfiguration.
In 2026, the safest domains will not simply be the ones that resolve correctly. They will be the ones that are continuously verified, monitored, and protected.
