DNS Security: Best Practices & Hardening Checklist

DNS security is the set of controls that keep your domain’s DNS accurate, available, and under your control, so attackers cannot redirect your traffic, impersonate your domain, or take it offline.

Below, we explain why DNS security is foundational to modern infrastructure, clear up the confusion between broad DNS security and DNSSEC, provide an actionable 12-step hardening checklist, and lay out a prioritized plan showing what to fix first.

What Is DNS Security?

DNS operates behind every web request, API call, and email delivery, yet it was created without built-in authentication or cryptographic verification. DNS security encompasses the policies, configurations, protocols, and monitoring practices required to protect domain names and nameserver infrastructure from unauthorized tampering, eavesdropping, and operational disruption.

Rather than relying on a single tool, effective DNS security requires defense across four distinct operational layers:

1. Registrar Layer: Controls that secure your domain registration, domain ownership records, and administrative access credentials to prevent unauthorized account takeovers.
2. Authoritative Nameserver Layer: Safeguards applied to the authoritative servers hosting your public zone files, ensuring resilient uptime, redundancy, and controlled zone transfers.
3. Resolution and Transport Layer: Measures applied to recursive resolvers and query traffic, protecting lookup requests from on-path eavesdropping, alteration, and local cache manipulation.
4. Record and Identity Layer: Cryptographic records and security policies published within your zone, including DNSSEC signatures, CA authorization policies, and email authentication standards.

Most security breaches begin with a preventable weakness in one of these layers. Understanding how these layers interact helps security teams eliminate latent DNS vulnerabilities before adversaries find and exploit them. Organizations following formal compliance programs can also reference the NIST DNS security guidelines for federal baseline requirements.

Why Is DNS Security Important?

Because the core Domain Name System protocol transmits queries in plaintext without cryptographic origin validation, raw DNS traffic inherently trusts incoming responses. Organizations often invest heavily in firewalls, web application firewalls (WAFs), and endpoint detection agents while leaving their DNS zones largely unmonitored.

When attackers manipulate DNS, they bypass perimeter defenses entirely. Compromising a DNS zone allows an adversary to route corporate web traffic to malicious replicas, issue valid TLS certificates for your brand, or intercept confidential email communications without ever touching your physical network servers.

Without comprehensive DNS security, organizations face severe threat vectors:

• DNS hijacking and registrar compromise: Attackers compromise registrar credentials or exploit social engineering to redirect authoritative nameservers to rogue hosts.
• DNS spoofing and cache poisoning: Attackers inject fraudulent resource records into vulnerable recursive resolvers, redirecting users to credential-harvesting destinations.
• DNS amplification and DDoS: Open recursive resolvers are abused to bounce high-volume responses against a victim target, saturating bandwidth and taking entire services down.
• Dangling records and subdomain takeover: Orphaned DNS records pointing to deactivated cloud resources or hosting buckets are claimed by external actors to host malicious content under your brand.
• Email spoofing through weak DNS records: Missing or misconfigured SPF, DKIM, and DMARC policies allow scammers to deliver spear phishing emails claiming to be from your corporate domain.

For a complete breakdown of attack methodologies, explore our guide to the 10 types of DNS attacks, and test your domain using our free DNSSEC checker.

DNS Security vs. DNSSEC

A frequent misconception among IT teams is treating DNS Security and DNSSEC as interchangeable terms. They are not.

DNSSEC (Domain Name System Security Extensions) is a specific technical control within a broader security framework. DNSSEC uses public key cryptography to digitally sign DNS records within a zone file. When a validating resolver checks a signed domain, it verifies the signature against a chain of trust leading up to the root zone, ensuring the received answer was not altered in transit.

Broad DNS security represents the entire management lifecycle and defense architecture. While DNSSEC provides record authenticity and integrity, it does not solve every threat:

• DNSSEC does not encrypt query traffic or provide confidentiality against eavesdroppers.
• DNSSEC does not stop attackers who take over your registrar account and alter your public delegation records.
• DNSSEC does not mitigate volumetric DDoS attacks or stop open resolvers from participating in amplification storms.
• DNSSEC does not detect dangling CNAME records pointing to decommissioned third-party cloud assets.

DNSSEC is a mandatory component of a hardened infrastructure, but it must function alongside registrar locks, transport encryption, strict email controls, and continuous zone monitoring. Learn more about how cryptographic validation works in our guide to DNSSEC.

DNS Security Best Practices: The Hardening Checklist 

Securing your domain requires structured, reproducible operational habits. The following checklist covers 12 essential controls organized by infrastructure layer and implementation complexity.

1. Lock Your Domain at the Registrar Level

Unauthenticated transfer requests are a top vulnerability for critical domain assets. Apply clientTransferProhibited and clientUpdateProhibited status codes to your domains.

For high-value corporate domains, request a Registry Lock from your registrar. Registry locking requires offline verification, such as telephone confirmation with designated personnel, before any changes to nameserver delegations or WHOIS administrative contacts can occur.

2. Enforce MFA and Role-Based Access at Your Registrar

Ensure that administrative accounts at your domain registrar and DNS hosting provider do not rely solely on passwords. Enforce hardware-based Multi-Factor Authentication (MFA) using FIDO2 / WebAuthn security keys.

Keep registrar login credentials out of shared team inboxes. Implement strict Role-Based Access Control (RBAC) so that standard IT staff have read-only access, reserving domain management permissions for designated domain administrators.

3. Restrict Zone Transfers (AXFR)

Authoritative DNS servers use full zone transfers (AXFR) to replicate DNS data between primary and secondary servers. If your nameserver permits unrestricted AXFR requests from any IP address, attackers can download your entire zone file. This exposes internal hostname structures, staging servers, and hidden network infrastructure.

Configure your primary nameservers to permit AXFR transfers only to the explicit IP addresses of your authorized secondary nameservers. You can verify your configuration from a terminal prompt:

dig AXFR yourdomain.com @ns1.yourdomain.com

If the server returns your complete list of DNS records instead of a Transfer Failed or REFUSED error, your zone transfer settings are open and need immediate restriction.

4. Deploy Redundant Authoritative Nameservers Across Diverse Networks

Relying on a single DNS provider or a single physical data centre introduces a single point of failure. If your provider suffers a DDoS attack or network outage, your entire online presence goes dark.

Deploy at least two authoritative nameservers hosted across separate Autonomous System Numbers (ASNs) and geographically dispersed networks. Utilizing a dual-provider authoritative DNS model ensures that if one provider experiences an infrastructure failure, your secondary provider continues resolving queries seamlessly.

5. Implement DNSSEC with Modern Cryptography

DNSSEC adds digital signatures to your DNS records. When a recursive resolver queries a DNSSEC-enabled zone, it validates cryptographic signatures (RRSIG records) against a chain of trust back to the root zone. This helps ensure the response was not modified in transit.

When implementing DNSSEC, follow the updated NIST SP 800-81r3 guidelines:

• Use modern Elliptic Curve cryptography such as ECDSA Curve P-256 or Ed25519 rather than legacy RSA keys. Smaller key sizes reduce packet fragmentation risk over UDP.
• Maintain signature validity windows between 5 and 7 days to restrict the exposure window of a compromised key.
• Schedule key rollovers for Zone Signing Keys (ZSK) every 1 to 3 years, and store Key Signing Keys (KSK) in secure hardware configurations where practical.

You can verify whether your domain’s cryptographic chain is intact by running your domain through a dedicated DNSSEC checker.

6. Publish a Certificate Authority Authorization (CAA) Record

A CAA record enables domain owners to specify which Certificate Authorities (CAs) are authorized to issue digital TLS certificates for their domain and subdomains.

Before issuing a certificate, public CAs must query the domain’s DNS for CAA records. If a CAA record exists, only the designated authorities (for example, Let’s Encrypt or DigiCert) are allowed to fulfill issuance requests. This stops rogue employees or compromised third-party systems from requesting unauthorized certificates through unapproved vendors.

Include an iodef tag within your CAA record pointing to an active security contact mailbox to receive immediate alerts if an unauthorized CA receives a certificate request for your domain. Validate your record syntax with our CAA checker.

7. Audit for Dangling and Orphaned Records

Regularly review your published record inventory to locate obsolete hostnames. Pay close attention to CNAME records pointing to third-party cloud hosts, subdomains mapped to decommissioned email providers, and stale A records pointing to retired IP addresses.

Before making structural updates, verify your published records using a reliable DNS record lookup tool. Reviewing various types of DNS records across all active subdomains helps prevent accidental exposure to subdomain takeover attacks.

8. Set Sane TTL Values and Track Propagation Windows

Time-To-Live (TTL) settings dictate how long recursive resolvers cache a DNS record before requesting a fresh copy from your authoritative nameserver.

• Standard Operations: Set default TTLs between 3,600 seconds (1 hour) and 86,400 seconds (24 hours). This balances server load and query latency.
• Pre-Migration or Incident Response: Lower your TTL values to 300 seconds (5 minutes) at least 24 to 48 hours prior to planned infrastructure changes.

Lowering TTLs in advance ensures rapid cache expiration across global resolvers if you need to swing traffic away from an impacted server. You can monitor how changes spread across global resolvers using a real-time DNS propagation checker.

9. Encrypt Client-to-Resolver Transport (DoH / DoT / DoQ)

Standard DNS queries travel across UDP and TCP port 53 in cleartext, exposing users to local surveillance, ISP tracking, eavesdropping, and on-path manipulation across local network hops.

Modern protocols secure the client-to-resolver transport leg using proven cryptographic frameworks:

• DNS over HTTPS (DoH): Wraps DNS requests inside standard HTTPS sessions over port 443, concealing query traffic among routine web requests.
• DNS over TLS (DoT): Directs DNS queries through a dedicated encrypted TLS tunnel over port 853, isolating DNS transactions while providing strong endpoint authentication. To understand how underlying encryption protocols protect transport streams, read our primer on the difference between SSL and TLS.
• DNS over QUIC (DoQ): Transports queries over QUIC (UDP port 853), minimizing connection establishment overhead while eliminating head-of-line blocking.

Configure internal enterprise endpoints, operating systems, and local network forwarders to route upstream resolution exclusively through secure resolvers that enforce DoH or DoT.

10. Harden Local Resolver and Nameserver Software

If your organization maintains internal recursive resolvers or manages dedicated authoritative nameserver instances using BIND, Unbound, PowerDNS, or Windows Server DNS, follow disciplined system hardening practices:

• Disable Open Recursion: Ensure recursive resolvers only process queries originating from trusted internal network ranges. Leaving resolvers open to arbitrary internet queries exposes your infrastructure to amplification attacks via open resolvers.
• Separate Roles: Never run authoritative hosting and recursive resolution on the same server software instance.
• Apply Prompt Security Updates: Subscribe to security advisory lists from your software vendors. Vulnerabilities like cache bugs, buffer flaws, and memory leaks are discovered regularly in legacy DNS packages. Track and patch unpatched DNS software continuously.
• Conceal Software Versions: Disable public version queries (such as BIND’s version.bind CHAOS TXT query) to deny reconnaissance scanners insight into your specific software build.
• Enable Response Rate Limiting (RRL): Implement RRL on authoritative servers to throttle rapid, repeated query floods targeting identical domains, curbing participation in reflection attacks.

11. Implement Response Policy Zones (RPZ)

Response Policy Zones, often referred to as DNS Firewalls, allow recursive resolver administrators to overlay custom threat intelligence feeds on top of standard name resolution.

When a client device attempts to resolve a domain known to host malware, command-and-control (C2) servers, or phishing pages, the RPZ rules interrupt the lookup. The resolver returns a NXDOMAIN response or redirects the user to an internal block page.

12. Enforce Email Authentication Protocols: SPF, DKIM, and DMARC

Email authentication operates directly through specialized TXT records published within your DNS zone. Without disciplined email records, any external sender can transmit fraudulent emails claiming to originate from your domain name.

A complete email defense posture requires three interconnected standards:

1. SPF (Sender Policy Framework): Publishes an authorized list of server IP addresses and third-party relay providers permitted to send mail for your domain. Review foundational concepts in our guide on SPF, DKIM, and DMARC.
2. DKIM (DomainKeys Identified Mail): Uses public-key cryptography to append a digital signature to outbound email headers. You publish the public key in your DNS zone, allowing recipients to verify that the message content was not tampered with during transmission.
3. DMARC (Domain-based Message Authentication, Reporting, and Conformance): Unifies SPF and DKIM under a centralized policy published at _dmarc. DMARC provides visibility into sending activity and instructs recipient mail servers how to treat unaligned emails.

Moving to an enforced DMARC policy (p=quarantine or p=reject) guarantees that recipient mail servers reject or isolate unauthorized messages using your identity. Check your current setup using our DMARC record checker, and follow our technical walkthrough to publish a DMARC record.

DNS Monitoring: The Practice Most Teams Skip

Deploying security controls is not a one-time exercise. DNS records drift over time as teams launch temporary marketing campaigns, adjust email vendors, rotate nameserver delegates, and retire legacy infrastructure. Without automated visibility, unauthorized changes or unintended misconfigurations can linger undetected for months.

A disciplined DNS monitoring routine should continually track:

• Nameserver and Delegation Changes: Immediate detection of modifications to NS records or parent zone glue records that could indicate account compromise.
• MX and SPF Drift: Visibility into newly published mail exchanges or alterations to SPF sender mechanisms.
• DNSSEC Validation Status: Automated checks confirming that key signatures, RRSIG records, and DS chains remain active without expiring.
• Zone Transfer Exploitation: Logging of repeated AXFR transfer requests attempted from external unauthorized networks.
• Registration and Certificate Expiration: Proactive tracking of domain renewal dates and public SSL/TLS certificate lifespans to prevent accidental drops.
• Look-alike Domain Activations: Monitoring for newly registered homoglyph or typo-squatted domains spinning up active MX records to impersonate your brand.

Managed DNS and DNS-Layer Filtering: Where They Fit

Modern enterprises frequently deploy managed DNS platforms and DNS-layer security filtering to simplify operations and enhance threat visibility.

Authoritative Managed DNS Providers

Enterprise managed DNS providers operate global Anycast networks that distribute your authoritative zone file across hundreds of edge locations. Anycast infrastructure provides built-in DDoS mitigation, absorbing massive volumetric attacks before they reach your core network. Managed platforms also automate DNSSEC key management and DNS record maintenance.

Recursive DNS-Layer Filtering (Protective DNS)

Protective DNS (PDNS) solutions operate at the recursive resolver layer. Instead of simply answering queries, PDNS solutions check every request against dynamic threat intelligence databases.

If an employee clicks a link leading to a newly registered phishing domain or an infected payload tries to contact a C2 server, the protective resolver blocks resolution at the network layer.

Neither managed DNS nor DNS filtering replaces domain registrar hygiene or proper record configuration. They serve as complementary layers within a broader Zero Trust security architecture.

What to Audit First: Prioritized Action Plan

Remediating a domain portfolio across all 12 checklist controls can feel daunting. Follow this prioritized schedule to address critical vulnerabilities first:

1. Day 1: Secure Account Ownership
   • Enable hardware MFA on your domain registrar portal.
   • Turn on Registrar Lock across all registered domains.
   • Remove stale, unassigned administrator logins.
2. Day 2: Protect Core Traffic Routing
   • Restrict zone transfers (AXFR) to verified secondary nameservers.
   • Scan your public zone files for dangling CNAME, A, or NS records pointing to unclaimed cloud services.
   • Close open recursion on any internet-facing corporate resolvers.
3. Week 1: Deploy Cryptographic Identity
   • Publish a CAA record designating your chosen certificate authorities.
   • Configure and sign your production zones using modern DNSSEC algorithms, ensuring DS records are confirmed at the parent registry.
4. Week 2: Enforce Email Authentication
   • Audit your active SPF mechanisms and remove unused vendors.
   • Deploy DKIM keys across all outbound mail gateways.
   • Publish a DMARC record and establish reporting to monitor authentication alignment.
5. Ongoing: Establish Continuous Monitoring
   • Track record changes, certificate expiration dates, and DNSSEC signature health automatically.

Not sure where you stand? Run our free domain analyzer to evaluate your domain’s health score.

Frequently Asked Questions

What is the most important DNS security practice?

Enforcing strong registrar access controls, including hardware-backed multi-factor authentication and registrar or registry locks, is the single most important practice. If an adversary compromises your registrar account, they can replace your authoritative nameservers entirely, rendering all downstream zone configurations and DNSSEC keys useless.

How do I tell if my DNS is hijacked?

Signs of DNS hijacking include sudden drops in legitimate website traffic, unexpected SSL/TLS certificate warning errors displayed to users, unauthorized modifications in your registrar audit logs, unexplained email delivery bounces, or external resolvers returning unfamiliar IP addresses for your domain.

Is DNS security only necessary for large enterprises?

No. Threat actors frequently target small and medium-sized organizations because their registrar portals and DNS zones are often left unmonitored. Attackers routinely hijack small business domains to run phishing campaigns, host malicious redirect chains, and impersonate corporate executives.

Does DNSSEC encrypt DNS queries?

No. DNSSEC provides data integrity and cryptographic origin authentication, proving that a received DNS record came from the rightful owner and was not altered along the way. It does not encrypt DNS queries or provide confidentiality. Encrypting query traffic requires transport protocols like DNS over HTTPS (DoH) or DNS over TLS (DoT).

What is the difference between authoritative and recursive DNS security?

Authoritative DNS security focuses on protecting your domain’s published records, nameserver hosting uptime, and zone files so the world receives accurate answers about your services. Recursive DNS security focuses on protecting client devices on your network from receiving manipulated answers, blocking malicious domains, and encrypting transport to external resolvers.

How often should an organization audit its DNS records?

Organizations should audit public zone files at least quarterly to clean up retired hostnames and remove dangling pointers. However, automated monitoring should run daily to detect unauthorized record adjustments, nameserver alterations, or expiring DNSSEC keys in real time.

Is 1.1.1.1 DNS secure?

Yes. Cloudflare’s 1.1.1.1 public DNS resolver is secure and supports modern encrypted transport protocols including DNS over HTTPS (DoH), DNS over TLS (DoT), and DNSSEC validation. It also enforces strict privacy protections, committing to wipe user query logs within 24 hours.

Is DNS security the same as a VPN?

No. A VPN (Virtual Private Network) creates an encrypted tunnel for all network traffic between your device and a remote private network, masking your IP address from destination servers. DNS security specifically protects the translation of domain names into IP addresses, ensuring that your queries are authentic, tamper-proof, and resilient against spoofing.

Final Words

Securing your Domain Name System is an indispensable component of modern cybersecurity hygiene. When left unmanaged, DNS creates an expansive attack surface that allows adversaries to bypass traditional endpoint, firewall, and web application defenses.

By systematically applying this 12-step hardening checklist, locking down your registrar account, deploying DNSSEC, and enforcing strict email authentication, your organization establishes a resilient defense against traffic hijacking, brand impersonation, and costly service disruptions.