DNS Security Best Practices: A Complete Hardening Checklist

Domain Name System (DNS) infrastructure is often the most trusted component in an enterprise network, yet it remains one of the least monitored. When sysadmins set up domain records, they usually move on to firewalls, endpoint security, or identity management. Attackers know this gap exists and take full advantage of it.

If an adversary gains control of your domain name resolution, they can silently reroute web traffic, intercept corporate emails, and generate valid Transport Layer Security (TLS) certificates in your name. They accomplish all of this without breaching a single server inside your internal network.

Implementing robust DNS security is not optional for modern infrastructure. This guide provides a complete set of DNS security best practices to help you avoid common issues and mistakes.

What Is DNS Security?

DNS security is the system of technical controls, cryptographic protocols, and administrative policies designed to protect the integrity, availability, and confidentiality of domain name resolution services.

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

1. The Registrar and Account Layer: This includes administrative protections at your domain registrar that prevent unauthorized domain transfers and credential theft.
2. The Authoritative Nameserver Layer: These are infrastructure controls that ensure your official zone files remain available, unmodified, and resilient against Distributed Denial of Service DDoS attacks.
3. The Resolution and Transport Layer: This layer involves protocols that protect DNS queries in transit between end-user clients, recursive resolvers, and authoritative servers.
4. The Resource Record and Identity Layer: Cryptographic records published within your zone file, such as Domain Name System Security Extensions and email authentication records, that validate the authenticity of your domain data.

Why DNS Is a Target: The Attack Surface

Because DNS operates as trusted background plumbing, legacy configurations allow threat actors to execute various attacks.

DNS Hijacking and Registrar Compromise

In a domain hijacking attack, an adversary gains access to your domain registrar account or abuses weak registrar procedures to modify your nameserver delegations. Once an attacker changes your NS records to point to their rogue servers, they control all incoming traffic for your domain.

Recent campaigns have targeted domain registrars using credential stuffing and targeted social engineering. When attackers successfully execute DNS hijacking, they can instantly issue valid certificates for your root domain using automated Certificate Authority (CA) validation protocols.

DNS Spoofing and Cache Poisoning

Traditional DNS queries travel over unencrypted UDP on port 53. Because standard queries lack built-in transaction authentication, an attacker on the network path can forge response packets and send them back to a recursive resolver before the legitimate authoritative server responds.

This technique, known as DNS spoofing, forces recursive servers to accept fake IP addresses for targeted hostnames. When a resolver stores these forged responses in its local memory, DNS cache poisoning occurs. Every user relying on that resolver gets directed to malicious sites until the cached entry expires. Understanding these vectors is very important when you analyze common types of DNS attacks.

DNS Amplification and DDoS

Authoritative nameservers are prime targets for volume-based DDoS attacks. Attackers frequently exploit open recursive resolvers to launch a DNS amplification attack.

By sending small spoofed requests (such as ANY or TXT queries) with the victim’s forged source IP address to vulnerable resolvers, the resolvers return massive response payloads to the victim. This flood of traffic saturates network bandwidth and causes widespread service outages.

Dangling Records and Subdomain Takeover

As organizations migrate services between cloud providers, systems engineers often tear down cloud resources like Amazon S3 buckets, GitHub Pages, or Azure App Services without deleting the corresponding CNAME records in their DNS zone.
This oversight creates a dangling DNS record. An external attacker can claim the abandoned bucket or app instance on the cloud provider’s platform, instantly gaining control of your subdomain. Subdomain takeovers allow attackers to host phishing forms, execute cross-site scripting (XSS), and steal session cookies.

Email Spoofing Through Weak DNS Records

Email delivery relies heavily on DNS. If your organization fails to publish properly configured authentication records, cybercriminals can send outbound emails forged to look like they originated from your domain. This exposes your business partners, customers, and employees to direct phishing campaigns.

DNS Security Best Practices: The Hardening Checklist

Use this step-by-step checklist to systematically harden your domain infrastructure against interception and misuse.

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:

None
dig AXFR yourdomain.com @ns1.yourdomain.com

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 is a DNS TXT-style record that explicitly specifies which Certificate Authorities are authorized to issue public TLS certificates for your domain name.

If an attacker attempts to request an unauthorized certificate for your domain from an automated CA, the CA must check your public CAA record before issuance. If the CA is not listed, issuance is blocked.

To restrict certificate issuance to specific providers, add a CAA record to your root domain:

None
yourdomain.com. IN CAA 0 issue “letsencrypt.org”
yourdomain.com. IN CAA 0 issue “digicert.com”
yourdomain.com. IN CAA 0 iodef “mailto:[email protected]”

The iodef parameter instructs compliant CAs to send real-time notification emails to your security team if someone attempts to request an unauthorized certificate.

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 plaintext DNS queries on UDP port 53 expose client browsing habits to local eavesdroppers, rogue Wi-Fi operators, and transit ISPs. Encrypting the query path protects end-user privacy and prevents local network manipulation.

Modern enterprise networks support three primary encrypted transport standards:

• DNS over TLS (DoT) – Runs over dedicated TCP port 853. DoT is widely used for securing transport between internal endpoints, local recursive resolvers, and upstream servers.
• DNS over HTTPS (DoH) – Encapsulates DNS queries inside HTTPS traffic on port 443, making query traffic indistinguishable from regular web traffic.
• DNS over QUIC (DoQ) – Uses QUIC transport for reduced latency and improved performance on unstable network connections.

When deploying encrypted DNS inside enterprise environments, configure local client endpoints via Mobile Device Management (MDM) tools to use your designated internal encrypted resolvers. Block unauthorized outbound DoT (port 853) and public DoH endpoints at your network firewall to prevent applications from bypassing local security logging.

10. Harden Local Resolver and Nameserver Software

If your organization maintains self-hosted recursive resolvers or internal BIND, Unbound, or PowerDNS instances, follow strict server hardening practices:

• Restrict recursive resolution to authorized internal IP ranges. Open resolvers on the public internet are rapidly leveraged in DDoS amplification attacks.
• Implement QNAME minimization and configure resolvers to send only the minimal required domain labels to upstream authoritative servers (RFC 7816). This prevents authoritative root servers from seeing full target hostnames.
• Place authoritative primary servers behind hidden IP addresses that are not listed in public NS record sets. Public secondary servers pull zone updates from the hidden primary.

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 protocols are DNS records. Without enforcing SPF, DKIM, and DMARC, an attacker can spoof your domain identity in phishing emails even if your registrar and nameservers are completely hardened.

DNS Monitoring: The Practice Most Teams Skip

Security teams often discover DNS tampering only after customer support reports site outages or broken mail flow. Passive configurations leave massive Blind spots.

Effective DNS monitoring requires three active controls:

1. Automated Zone File Integrity Monitoring: Set up automated pollers that track your authoritative zone files 24/7. Your team should receive instant alerts if critical records (such as NS, MX, A, or root TXT records) change unexpectedly.
2. Alerting on MX and NS Modifications: Changing an MX record allows an attacker to route incoming mail through their servers to harvest sensitive password-reset tokens. Alerts on MX and NS record changes should trigger immediate priority incident workflows.
3. DNS Query Log Analysis: Integrate Protective DNS (PDNS) logs into your Security Information and Event Management (SIEM) platform. Correlating DNS query logs with DHCP lease histories allows analysts to trace malicious domain lookups directly back to compromised internal devices.

Email Authentication as a DNS Control

A common mistake in DNS security is isolating web traffic controls from mail controls. SPF, DKIM, and DMARC rely entirely on DNS TXT records to publish public keys and sender policies.

• SPF: Publishes an allowlist of IP addresses and mail servers authorized to send outbound mail on behalf of your domain.
• DKIM: Attaches cryptographic signatures to outbound email headers. Receivers fetch the corresponding public key from your domain’s DNS to verify the message wasn’t altered in transit.
• DMARC: Ties SPF and DKIM together. DMARC instructs receiving mail servers how to handle emails that fail authentication.

Setting your policy to p=reject instructs receiving mail servers to drop unauthenticated messages automatically. Understanding your active DMARC policy protects your brand reputation across global receiving networks.

You can verify your current email authentication posture instantly using an online DMARC record checker.

While DMARC stops domain impersonation in email, keep in mind that DMARC cannot protect against cache poisoning or subdomain takeovers. A complete defensive strategy requires hardening both network DNS resolution and email DNS records.

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

If your security team cannot implement all twelve checklist items this quarter, focus on high-impact wins first. Execute these five tasks in order:

1. Enable clientTransferProhibited and Registry Locks on all primary domains. Require FIDO2 hardware keys for all registrar account users to eliminate account takeover risks.
2. Restrict AXFR zone transfers by auditing authoritative nameservers to block unrestricted zone transfers immediately.
3. Inventory all published CNAME records, compare them against active cloud resources, and delete any orphaned entries.
4. Configure automated MX and NS alerts by setting up continuous monitoring on root zone records so your team gets alerted instantly to unauthorized modifications.
5. Audit active mail sources, resolve alignment gaps, and update your DMARC policy to drop spoofed messages.

Frequently Asked Questions

What is DNS security in simple terms?

DNS security encompasses the technical protocols, access controls, and administrative practices used to protect the domain name resolution system. It ensures that when users type your domain name into a browser, they connect to your real servers rather than a malicious site created by an attacker.

Does DNSSEC encrypt DNS traffic?

No, DNSSEC does not encrypt DNS queries or responses. Standard DNSSEC queries travel in plaintext. DNSSEC uses digital signatures to verify that the DNS data you receive is authentic and has not been altered in transit. To encrypt DNS traffic queries, you must deploy DNS over HTTPS (DoH), DNS over TLS (DoT), or DNS over QUIC (DoQ).

What is the difference between DNSSEC and DNS over HTTPS (DoH)?

DNSSEC authenticates data integrity at the zone level, proving that a response came from the true domain owner without modification. DoH encrypts the transport path between an end-user device and the recursive resolver.

Is DNS hijacking the same as DNS spoofing?

No. DNS hijacking involves compromising administrative access at the domain registrar or nameserver host to change your official DNS settings. DNS spoofing (or cache poisoning) tricks a recursive resolver into storing fake IP addresses in its cache without altering your official registrar settings.

How do I know if my domain DNS has been compromised?

Common indicators include unexpected website redirection, sudden drop-offs in email delivery, unauthorized TLS certificates issued for your domain, or unexpected changes to your NS, A, or MX records during routine audits.

Do SPF, DKIM, and DMARC count as DNS security?

Yes. SPF, DKIM, and DMARC records are published directly within your domain’s public DNS zone. Because receiving mail servers query DNS to validate message sender authenticity, accurate email authentication records are a vital component of domain DNS hardening.

Conclusion

DNS security is not a single product you purchase and install. It is a multi-layered practice spanning domain registrar administration, authoritative nameserver hardening, query transport encryption, and record integrity checks.

Leaving any layer unmonitored creates opportunities for threat actors to hijack traffic, execute man-in-the-middle attacks, or spoof corporate communications.

Start hardening your domain infrastructure today by conducting a complete inventory of your active zone files. Use a free DNS record lookup to audit published records, and test your domain with a DMARC record checker to ensure your brand remains protected.

• About
• Latest Posts

Milena Baghdasaryan

Content Specialist at PowerDMARC

Milena is a skilled writer and content creator with 7+ years of experience in crafting engaging content on IT, cybersecurity, virtual events, and more. She has a proven track record of delivering high-quality work for international magazines and is a graduate of prestigious institutions such as New York University Abu Dhabi, UWC China, and the College of Europe.

Latest posts by Milena Baghdasaryan (see all)

• DNS Security Best Practices: A Complete Hardening Checklist - September 7, 2026
• Dynamic SPF vs Auto SPF vs Hosted SPF: Which One Actually Fixes Your SPF Record? - August 25, 2026
• Reply vs Reply All: Etiquette and Security Risks - August 14, 2026