Complete Guide to DNS Attacks and DNS Security (Prevention, Testing & Mitigation)

DNS attacks are techniques used to exploit weaknesses in the Domain Name System to redirect traffic, exfiltrate data, or disrupt services. Common DNS attack types include cache poisoning, amplification, tunneling, hijacking, and zone walking. Because DNS underpins virtually every connection on the internet, a compromise at this layer can be devastating and difficult to detect.

I wrote this guide because DNS security is one of the most underappreciated areas in infrastructure defense. Most engineers configure their DNS records once and never think about them again. Attackers know this. The goal here is to give you a thorough understanding of how these attacks work, how to test your own domains for weaknesses, and how to defend against each one.

What Is DNS and Why It Is a Target

The Domain Name System translates human-readable domain names like example.com into IP addresses that computers use to communicate. It is a hierarchical, distributed system where queries flow from your local resolver up through root servers, TLD servers, and finally to the authoritative nameserver for a domain.

DNS was designed in the 1980s without authentication. The original protocol trusts every response it receives, with no built-in mechanism to verify that an answer is legitimate. This fundamental design decision created an attack surface that persists to this day.

There are several reasons DNS is a high-value target:

• It is always running. DNS is one of the few services that must be reachable at all times. If DNS goes down, everything goes down.
• It is often unmonitored. Most organizations monitor HTTP traffic, application logs, and database queries. Very few actively monitor DNS query patterns.
• Port 53 is almost never blocked. Firewalls allow DNS traffic by default. Attackers know this and use it as a covert channel.
• Caching amplifies the damage. A single poisoned response can affect thousands of users for hours because resolvers cache answers.
• It is trusted implicitly. Applications, email systems, and TLS certificate validation all depend on DNS being correct. Compromise DNS, and you undermine the entire trust chain.

How Attackers Think About DNS

Before diving into specific attack types, it helps to understand the attacker mindset when it comes to DNS.

The first thing an attacker does during reconnaissance is interrogate your DNS. Running dig, nslookup, or host against a target domain reveals nameservers, mail servers, SPF records, and sometimes internal subdomains. None of this requires authentication. It is all public by design.

From there, the attacker looks for:

1. Misconfigurations — zone transfers enabled, dangling CNAME records, missing DNSSEC
2. Infrastructure weaknesses — open resolvers, outdated nameserver software, single points of failure
3. Trust relationships — which third-party services are CNAMEd, where mail is routed, what cloud providers are in use
4. Exfiltration paths — whether DNS queries are monitored, how long responses are cached, whether DoH is in use

The reconnaissance phase is often entirely passive. The attacker learns your infrastructure without triggering a single alert. That is what makes DNS attacks so effective — by the time you notice something is wrong, the groundwork was laid days or weeks earlier.

Types of DNS Attacks

DNS attacks fall into several broad categories based on what the attacker is trying to achieve:

Each of these categories contains multiple specific techniques. I will cover the most important ones in detail below.

Reconnaissance Attacks

DNS Zone Transfer Attack (AXFR)

A DNS zone transfer is a mechanism designed to replicate DNS records between authoritative nameservers. When a secondary nameserver needs to synchronize with the primary, it requests an AXFR transfer, and the primary sends the entire zone file — every record for the domain.

The problem is that many administrators forget to restrict who can request zone transfers. If an attacker can issue an AXFR query and the server responds, they receive a complete inventory of every subdomain, IP address, mail server, and internal service name in the zone.

How attackers discover this:

dig axfr example.com @ns1.example.com

If the server responds with records instead of a "Transfer failed" message, the zone is exposed.

How to defend against it:

• Restrict zone transfers to specific IP addresses in your nameserver configuration (the allow-transfer directive in BIND, for example)
• Use TSIG (Transaction Signatures) to authenticate transfer requests between your nameservers
• Audit your nameservers periodically by running the AXFR query yourself from an external IP
• Use the DNS Inspector to verify your nameserver configuration

You can test whether your domain's nameservers allow zone transfers by querying each one. If any of them respond with records, you have an exposure that needs to be fixed immediately.

DNS Zone Walking (NSEC Enumeration)

DNSSEC was designed to provide authenticated denial of existence — a way for a resolver to confirm that a record genuinely does not exist, rather than having been suppressed by an attacker. The original mechanism for this, NSEC, works by chaining records together alphabetically. Each NSEC record points to the next existing name in the zone.

The unintended consequence is that an attacker can follow these NSEC chains from one record to the next, systematically enumerating every name in the zone. This is called zone walking.

dig example.com NSEC

The response will include the next existing name in the zone. Repeat the process with that name, and you can walk the entire zone.

This works at every level — from subdomain enumeration within a single domain to walking entire TLD zones to discover every registered domain.

Mitigation:

• Use NSEC3 instead of NSEC. NSEC3 hashes domain names before chaining them, making enumeration significantly harder — but not impossible. NSEC3 hashes can be cracked offline with dictionary attacks and GPU-accelerated tools, so it is a deterrent, not a complete prevention.
• Use NSEC3 with the opt-out flag for large zones with many unsigned delegations.
• Consider whether you need DNSSEC at all for internal zones that should not be publicly enumerable.

Subdomain Enumeration

Beyond zone transfers and zone walking, attackers use brute-force dictionary attacks to discover subdomains. Tools cycle through common names like admin, staging, vpn, dev, internal, api, and thousands more, resolving each one to see if it exists.

This is not strictly a DNS vulnerability — it is just how DNS works. But it is worth understanding because it informs several other attacks (particularly subdomain takeover).

Defense: There is no way to prevent subdomain resolution. The best defenses are to minimize the number of subdomains pointing to decommissioned services, use wildcard records carefully, and monitor query logs for unusual enumeration patterns.

Interception and Redirection Attacks

DNS Cache Poisoning

DNS cache poisoning is the act of inserting a forged DNS response into a resolver's cache, causing it to return a malicious IP address for subsequent queries. The poisoned entry persists until the cached TTL expires, meaning every user of that resolver will be directed to the attacker's server.

The most famous demonstration of this was the Kaminsky attack in 2008. Dan Kaminsky showed that by flooding a resolver with forged responses for random subdomains of a target domain, an attacker could reliably inject a malicious authority record. The attack exploited the fact that DNS transaction IDs are only 16 bits, making them feasible to guess.

How it works conceptually:

1. The attacker triggers a query for random123.example.com against the target resolver
2. Before the legitimate nameserver responds, the attacker floods the resolver with forged responses containing a malicious NS record for example.com
3. If one of the forged packets matches the transaction ID and source port, the resolver accepts it
4. The resolver now has a poisoned cache entry — all queries for example.com are directed to the attacker's nameserver

How to test your resolver:

dig +dnssec example.com @your-resolver

Look for RRSIG records in the response. If your resolver validates DNSSEC, it will reject forged responses that lack valid signatures.

Mitigation checklist:

• Enable DNSSEC validation on all resolvers
• Use source port randomization (most modern resolvers do this by default)
• Deploy DNS cookies (RFC 7873) where supported
• Run resolvers behind rate limiters to slow brute-force poisoning attempts
• Monitor for unusual query patterns targeting random subdomains of your domains

For a deeper explanation of DNSSEC and how to enable it, see my article on What Is DNSSEC and Why Should You Enable It.

DNS Hijacking

DNS hijacking is the broader category of attacks where an attacker takes control of DNS resolution for a domain. Unlike cache poisoning (which targets resolvers), hijacking typically targets the authoritative side — the registrar account, the nameserver configuration, or the domain's delegation records at the TLD level.

There are several variants:

• Registrar hijacking: The attacker gains access to your domain registrar account (through credential theft, social engineering, or registrar vulnerabilities) and changes the nameservers to point to their own infrastructure.
• Rogue DNS server: The attacker compromises a resolver or configures malware on victim devices to use a malicious resolver.
• Man-in-the-middle: The attacker intercepts DNS traffic on the network and modifies responses in transit.
• BGP hijacking of DNS: The attacker announces the IP prefixes of legitimate nameservers via BGP, diverting DNS traffic to their infrastructure.

Mitigation:

• Enable registrar lock (also called domain lock or transfer lock) on all critical domains
• Use two-factor authentication on your registrar account
• Enable DNSSEC to detect response tampering
• Monitor your domain's NS records from external vantage points using the Propagation Checker
• For high-value domains, consider Registry Lock (an additional manual verification step at the registry level)

Subdomain Takeover

A subdomain takeover occurs when a DNS record (typically a CNAME) points to an external service that has been decommissioned, and the attacker claims that service.

For example, if blog.example.com has a CNAME pointing to example-blog.herokuapp.com, and you delete the Heroku app but forget to remove the DNS record, an attacker can create a new Heroku app with that hostname and serve arbitrary content on your subdomain.

This is more common than most people realize. Any cloud service that assigns custom hostnames — Heroku, GitHub Pages, AWS S3 static hosting, Azure, Shopify — is a potential target.

Detection:

dig blog.example.com CNAME

If the CNAME target returns NXDOMAIN or an error page from the provider saying "no app configured," the subdomain is vulnerable.

Prevention:

• Remove DNS records for any service you decommission
• Audit your DNS records regularly for dangling CNAMEs
• Use the DNS Inspector to review all records for a domain and identify stale entries
• Implement a process that couples service decommissioning with DNS cleanup

DDoS-Based DNS Attacks

DNS Amplification Attack

DNS amplification is a reflection-based DDoS attack. The attacker sends a small DNS query to an open resolver with the source IP spoofed to the victim's address. The resolver sends its (much larger) response to the victim. By using queries that generate large responses (like ANY or DNSSEC-signed responses), the attacker achieves an amplification factor of 50x to 70x.

The 2013 Spamhaus attack was one of the largest DNS amplification attacks in history, peaking at 300 Gbps. It was executed using open resolvers across the internet.

How attackers find open resolvers:

Open resolvers respond to recursive queries from any source IP. Attackers scan the internet for servers that respond to recursive queries on port 53.

How to test if your server is an open resolver:

dig @your-server-ip example.com A +recurse

If the server resolves the query from an external IP, it is acting as an open resolver.

Mitigation:

• Disable recursion on authoritative nameservers
• If you run a recursive resolver, restrict it to your own network ranges using ACLs
• Implement Response Rate Limiting (RRL) on your authoritative servers
• Deploy BCP38/BCP84 ingress filtering to prevent IP spoofing at the network edge
• Use anycast for your authoritative DNS to distribute attack traffic

DNS Water Torture Attack (Random Subdomain Attack)

The water torture attack targets authoritative nameservers by flooding them with queries for random, nonexistent subdomains. Each query like a8k3m2.example.com forces the authoritative server to perform a lookup and respond with NXDOMAIN. At sufficient volume, this overwhelms the server.

The attack is particularly effective because:

• Each query is unique, so caching provides no relief
• The queries appear legitimate — they are valid DNS queries for a real domain
• Rate limiting is difficult because the queries come from legitimate resolvers, not directly from the attacker

Mitigation:

• Use anycast DNS providers that can absorb volumetric attacks
• Implement aggressive NXDOMAIN rate limiting
• Deploy DNS firewalls that can detect random subdomain patterns
• Monitor for unusual spikes in NXDOMAIN response rates
• Consider using a DDoS mitigation service for your authoritative DNS

NXDOMAIN Attack

Similar to water torture but specifically designed to exhaust the resolver's cache and resources by generating massive volumes of queries for domains that do not exist. The goal is to fill the resolver's negative cache and degrade performance for legitimate queries.

Mitigation:

• Configure aggressive negative caching (but not so long that legitimate record changes are delayed)
• Use resolvers that implement NXDOMAIN rate limiting
• Monitor resolver performance metrics and set alerts for unusual NXDOMAIN ratios

Data Exfiltration via DNS

DNS Tunneling

DNS tunneling encodes arbitrary data in DNS queries and responses, using the DNS protocol as a covert communication channel. Because DNS traffic on port 53 is almost universally allowed through firewalls, attackers use it to bypass network security controls.

The attacker encodes data in subdomain labels. For example, to exfiltrate the string "secret data," the malware on the victim's machine encodes it and sends a query like:

c2VjcmV0IGRhdGE.exfil.attacker.com

The attacker's authoritative nameserver for attacker.com receives the query, decodes the subdomain, and extracts the data. Responses can carry commands back to the malware.

Tools like iodine and dnscat2 automate this process and can tunnel entire TCP connections through DNS.

Detection methods:

• Monitor for unusually long subdomain labels (legitimate subdomains rarely exceed 20-30 characters)
• Watch for high query volumes to a single domain
• Analyze query entropy — encoded data has higher entropy than normal domain names
• Look for TXT record queries with large response payloads
• Deploy DNS-layer security tools that inspect query patterns

Mitigation checklist:

• Log and analyze all DNS queries leaving your network
• Block direct DNS to external resolvers; force all traffic through your monitored resolver
• Use DNS security services that perform deep packet inspection on DNS traffic
• Alert on domains with high query volume from a single internal host
• Restrict the maximum query name length at your resolver if possible

DNS Over HTTPS (DoH) Abuse

DNS over HTTPS encrypts DNS queries inside HTTPS traffic, making them invisible to traditional network monitoring tools. While DoH was designed to protect user privacy, attackers can use it to:

• Bypass DNS-based security controls and content filters
• Tunnel malware command-and-control traffic through encrypted DNS
• Exfiltrate data through queries that are indistinguishable from normal HTTPS traffic

Mitigation:

• Implement endpoint-level DNS controls rather than relying solely on network-level monitoring
• Use TLS inspection (where legally and ethically appropriate) to inspect DoH traffic
• Block known public DoH endpoints at the firewall if your security policy requires DNS visibility
• Deploy endpoint detection and response (EDR) tools that monitor application-level DNS behavior

Infrastructure Misconfigurations

Fast Flux DNS

Fast flux is a technique used by botnets to hide malicious servers behind a constantly rotating set of IP addresses. The attacker configures extremely short TTLs (often 60-300 seconds) and continuously updates the A records for a domain to point to different compromised machines.

This makes it nearly impossible to block the infrastructure by IP address, because the addresses change faster than blocklists can be updated.

Single flux rotates the A records. Double flux additionally rotates the NS records, making even the nameservers ephemeral.

Detection:

• Monitor for domains with unusually low TTL values (under 300 seconds) combined with frequent IP changes
• Look for A records that resolve to IP addresses across many different ASNs and geographic regions
• Use threat intelligence feeds that track known fast flux domains

Phantom Domain Attack

The phantom domain attack targets recursive resolvers by configuring domains that either do not respond at all or respond extremely slowly. When a resolver queries a phantom domain, it waits for a timeout before giving up. If the attacker triggers enough queries for these phantom domains, the resolver's resources are tied up waiting for responses that never come.

This is a resource exhaustion attack on resolvers rather than authoritative servers.

Mitigation:

• Configure aggressive query timeouts on your resolvers
• Limit the number of outstanding queries per domain
• Use resolvers that implement qname minimization to reduce unnecessary upstream queries
• Monitor resolver performance for increasing latency

DNSSEC Downgrade Attack

A DNSSEC downgrade attack attempts to trick a validating resolver into accepting an unsigned response for a domain that should be signed. If successful, the attacker can serve forged responses without DNSSEC validation catching them.

This can happen when:

• The resolver does not properly validate the chain of trust
• An attacker strips DNSSEC records from responses in transit
• The resolver falls back to accepting unsigned responses when validation fails

Mitigation:

• Ensure your resolvers are configured to treat DNSSEC validation failures as hard failures, not soft warnings
• Audit your resolver configuration to confirm it properly validates the full chain of trust
• Monitor for responses that should have DNSSEC records but arrive unsigned

How to Test Your Domain

You do not need to wait for an attacker to discover weaknesses in your DNS. Here are practical tests you can run against your own domains.

Check for Open Zone Transfers

# Get your nameservers
dig NS example.com +short

# Test each one for AXFR
dig axfr example.com @ns1.example.com
dig axfr example.com @ns2.example.com

You should see "Transfer failed" or a connection refused. If you see records, lock it down immediately.

Verify DNSSEC Is Working

dig example.com A +dnssec

Look for RRSIG records in the answer section. If they are present, your domain is signed. You can verify the full chain with:

dig example.com A +sigchase +trusted-key=/etc/trusted-key.key

Or use the DNS Inspector to check your DNSSEC configuration visually.

Check for Dangling CNAMEs

# List all CNAME records
dig example.com ANY

# For each CNAME, verify the target resolves
dig blog.example.com CNAME +short
# Then check if the target is alive
curl -I https://blog.example.com

If the CNAME target returns NXDOMAIN or a provider error page, remove the DNS record or reclaim the service.

Test for Open Recursion

If you run your own nameserver, verify it does not act as an open resolver:

# From an external IP
dig @your-nameserver-ip google.com A +recurse

If it resolves, your server is an open resolver. Restrict recursive queries to your own network.

Monitor Query Patterns

Use the Propagation Checker to verify that your domain resolves consistently from nameservers around the world. Inconsistent results may indicate hijacking or misconfiguration.

DNS Security Checklist

Use this checklist to audit your DNS security posture:

Authentication and Integrity

• DNSSEC is enabled and validated for all public domains
• Registrar accounts are protected with two-factor authentication
• Domain lock (transfer lock) is enabled on all domains
• Consider Registry Lock for high-value domains

Access Control

• Zone transfers are restricted to authorized secondary nameservers only
• Recursive resolvers are not accessible from the public internet
• TSIG keys are used for zone transfer authentication
• Nameserver software is patched and up to date

Monitoring and Detection

• DNS query logs are collected and analyzed
• Alerts are configured for unusual query volumes, NXDOMAIN spikes, and high-entropy queries
• External monitoring checks NS records and resolution from multiple vantage points
• Anomaly detection is in place for DNS tunneling patterns

Infrastructure Hardening

• Response Rate Limiting (RRL) is enabled on authoritative servers
• Anycast is used for authoritative DNS to distribute load and absorb attacks
• TTLs are set appropriately (not too low, which enables fast flux; not too high, which delays legitimate changes)
• Internal DNS is separated from external DNS

Hygiene

• DNS records are audited regularly for stale entries and dangling CNAMEs
• Decommissioned services have their DNS records removed
• SPF, DKIM, and DMARC records are configured to prevent email spoofing
• Wildcard records are used sparingly and intentionally

For a detailed guide on email authentication records, see SPF, DKIM, and DMARC: The Complete Guide to Email Authentication DNS Records.

Ethical Note

Everything in this guide is written from a defensive perspective. The reconnaissance techniques described (zone transfer tests, DNSSEC verification, dangling CNAME checks) should only be run against domains you own or have explicit written authorization to test.

If you want to practice offensive DNS techniques safely:

• Build a local lab using BIND, PowerDNS, or Unbound in a virtual environment
• Use intentionally vulnerable platforms like DVWA, HackTheBox, or TryHackMe
• Participate in CTF competitions where DNS challenges are common
• Study defensive hardening first — understanding how to secure DNS makes you better at finding weaknesses

The mindset should always be: understand how attackers think so you can defend against them.

Related Tools and Articles

• DNS Inspector — Query any domain's DNS records across all record types
• DNS Propagation Checker — Verify DNS resolution from nameservers worldwide
• What Is DNSSEC and Why Should You Enable It?
• Understanding DNS Record Types
• SPF, DKIM, and DMARC: Email Authentication DNS Records
• What Is DNS TTL? — How Time to Live controls caching and propagation
• What Is NXDOMAIN? — Understand the "domain does not exist" DNS response code
• What Is SERVFAIL? — Diagnose DNS server failure responses
• What Is an Open DNS Resolver? — Why unintentional open resolvers are dangerous
• DNS Troubleshooting Tools: What the Pros Actually Use