DNS Attacks Explained

Types of DNS Attacks #

NXDOMAIN Attack Variants #

NXDOMAIN responses indicate domains that do not exist. Attackers exploit this behavior by generating massive amounts of random queries.

• Random NXDOMAIN flood
• Phantom subdomain attacks
• NXRRSET queries
• NXNSAttack delegation abuse

DNS DDoS Attack Variants #

• DNS query floods
• Reflection attacks
• Amplification attacks
• Protocol abuse

Recursive Resolution Exhaustion Attacks #

Not all DNS attacks rely on traffic volume. Some attacks attempt to exhaust resolver resources by forcing excessive recursive resolution work. During years of operating large recursive DNS infrastructures, operators may occasionally observe domains that trigger unusually deep resolution chains before eventually returning SERVFAIL. While isolated cases may simply be misconfigurations, repeated patterns can indicate intentionally crafted resolver exhaustion scenarios.

These situations typically involve domains delegated to nameservers located in other domains, which are in turn delegated again, sometimes across multiple levels:

domain1.tld   →   ns.domain2.tld
domain2.tld   →   ns.domain3.tld
domain3.tld   →   ns.domain4.tld
domain4.tld   →   ns.domain5.tld
domain5.tld   →   unreachable or broken

Before a resolver can answer the original query, it must resolve the IP addresses of each nameserver in the chain. Each step may require additional A and AAAA lookups, glue validation, DNSSEC checks and timeout handling. If failures occur deep in the chain, the resolver may only return SERVFAIL after performing significant work.

Why this technique increases resolver workload

This technique increases the computational cost of answering a single query by forcing resolvers to perform multiple dependent lookups instead of a single resolution step.

• Multiple NS lookups
• Additional A and AAAA resolution
• Timeout and retry handling
• DNSSEC validation work (if enabled)
• Cache miss amplification
• Increased resolver latency

This creates a form of resolution workload amplification where a single query may trigger dozens of internal resolver operations.

Operational indicators of suspicious delegation chains

Based on operational observations across large DNS environments, suspicious patterns may include:

• Delegation chains spanning multiple domains
• Nameservers inside recently registered domains
• Repeated resolution failures at the end of chains
• Unreachable authoritative servers
• Frequent SERVFAIL responses associated with specific domains
• Abnormal recursion depth usage

While DNS misconfigurations are common on the Internet, repeated occurrences of these patterns combined with high query volumes may indicate intentional abuse.

Mitigation strategies

Resolvers can reduce the impact of recursive exhaustion techniques through defensive configuration and monitoring:

• Limiting maximum recursion depth
• Limiting upstream fetch attempts
• Reducing resolver timeout windows
• Monitoring SERVFAIL anomaly patterns
• Blocking abusive domains using RPZ
• Tracking resolver latency anomalies

These protections help ensure resolver stability even when processing malicious or pathological DNS delegation structures.

DNS Tunneling #

DNS tunneling is a technique used by malware and post-exploitation tools to communicate with command-and-control (C2) infrastructure or exfiltrate data using DNS queries. Because DNS is almost always allowed through firewalls, attackers abuse it as a covert communication channel.

Instead of normal domain lookups, tunneling malware encodes data inside DNS queries, typically inside long subdomain labels:

encoded-data.attacker-domain.com

The authoritative server controlled by the attacker decodes the data and may respond with additional encoded instructions using DNS responses such as TXT records.

How DNS tunneling works

A typical DNS tunneling workflow involves:

• Malware encoding data into DNS query labels
• Queries sent to attacker-controlled domains
• Authoritative server decoding the payload
• Commands returned via TXT or NULL records
• Repeated queries forming a covert communication channel

Popular tunneling tools include iodine, dnscat2 and frameworks commonly used in incident response testing.

Operational indicators of DNS tunneling

DNS operators often detect tunneling activity through abnormal query characteristics rather than signature matching. Common indicators include:

• Very long domain names
• High entropy subdomain strings
• Large volumes of NXDOMAIN responses
• Unusual TXT query frequency
• Repeated queries to a single domain
• Unusually consistent query intervals
• Base32 or Base64-looking labels

In large recursive resolver environments, DNS tunneling often becomes visible as statistical anomalies before it is identified as malware activity.

DNS Tunneling Mitigation #

Because tunneling relies on domain resolution, Protective DNS provides an effective control point to detect and block these communications before connections are established.

Common mitigation techniques include:

• RPZ filtering of known command-and-control domains
• Domain entropy analysis to detect encoded payloads
• Monitoring excessive TXT queries
• Detection of abnormal query lengths
• Behavioral anomaly detection
• Blocking newly registered suspicious domains

In operational DNS environments, combining threat intelligence feeds with statistical anomaly detection is often the most effective way to detect tunneling activity early.

Example of suspicious DNS tunneling traffic

DNS tunneling activity often becomes visible when inspecting unusual DNS responses. For example, a TXT query to a suspicious domain may return encoded data instead of normal text records:

$ dig TXT data.attacker-domain.com

;; ANSWER SECTION:
data.attacker-domain.com. 60 IN TXT
"U29tZSBtYWx3YXJlIGNvbW1hbmQgYW5kIGNvbnRyb2wgZGF0YQ=="

This response contains what appears to be Base64 encoded data rather than legitimate TXT information such as SPF, DKIM or domain verification records. Decoding this value reveals structured data rather than human-readable configuration text:

$ echo U29tZSBtYWx3YXJlIGNvbW1hbmQgYW5kIGNvbnRyb2wgZGF0YQ== | base64 -d

Some malware command and control data

While not all encoded TXT records are malicious, repeated queries returning encoded payloads combined with abnormal query patterns may indicate DNS tunneling activity.

Other practical indicators operators monitor

• Labels close to the DNS 63 character limit
• Domains approaching the 253 character FQDN limit
• Large numbers of unique subdomains under one zone
• TXT responses containing encoded or binary-looking data
• NXDOMAIN bursts followed by successful TXT responses
• Unusual query type distributions from a single client

These indicators are commonly used in Protective DNS environments to identify compromised hosts attempting covert communication.

Legitimate TXT records such as SPF typically contain structured policy text (for example v=spf1 include:spf.example.com -all), making encoded blobs easy to distinguish during investigation.

NXNSAttack (Delegation Explosion Attack) #

NXNSAttack is a DNS protocol abuse technique disclosed in 2020 that targets recursive resolvers by forcing them to perform excessive upstream queries through malicious delegation responses. Unlike traditional DNS floods that rely on traffic volume, NXNSAttack increases resolver workload by abusing how resolvers process NS referrals.

Instead of returning a small set of legitimate authoritative nameservers, an attacker-controlled zone returns a large number of NS records pointing to domains that require additional resolution:

victim-domain.tld   NS   ns1.attack-domain.tld
victim-domain.tld   NS   ns2.attack-domain.tld
victim-domain.tld   NS   ns3.attack-domain.tld
victim-domain.tld   NS   ns4.attack-domain.tld
...

Because the resolver must resolve the IP address of each nameserver before continuing resolution, this forces the resolver to generate many additional A and AAAA queries.

Why NXNSAttack has a very high impact

NXNSAttack is particularly effective because it creates a workload amplification effect inside the resolver. A single query may cause dozens or even hundreds of additional upstream resolution attempts.

• Resolver must resolve every delegated NS hostname
• Each NS requires A and AAAA lookups
• Missing glue records force additional recursion
• Timeouts trigger retry logic
• Cache misses increase query volume
• DNSSEC validation increases cost further

This can transform a relatively small query stream into a large volume of recursive activity, consuming CPU, memory and network resources.

Why NXNSAttack is dangerous for large resolvers

Large ISP resolvers are particularly vulnerable because they process very high query volumes. Even a small percentage of NXNSAttack queries can significantly increase resolver workload.

In practice, operators may observe:

• Sudden spikes in outbound resolver queries
• Increased cache miss ratios
• Resolver latency increases
• Higher SERVFAIL rates
• Increased recursion depth usage

Because the attack exploits normal DNS protocol behavior, it can be difficult to distinguish from legitimate traffic without behavioral analysis.

Mitigation strategies

Modern DNS resolvers now include protections against NXNSAttack-style delegation abuse. Common mitigation techniques include:

• Limiting the number of NS records processed per query
• Limiting concurrent upstream fetches
• Applying resolver fetch quotas
• Improving glue record validation
• Monitoring abnormal delegation patterns
• Blocking abusive domains using RPZ

Current versions of BIND, Unbound and PowerDNS include protections that significantly reduce the effectiveness of NXNSAttack when properly configured.

Practical example of an NXNSAttack scenario

A normal DNS resolution typically requires resolving only a small number of authoritative nameservers. For example:

example.com   NS   ns1.example.com
example.com   NS   ns2.example.com

The resolver only needs to resolve two nameserver addresses before obtaining an answer.

In an NXNSAttack scenario, an attacker-controlled domain may instead return a large number of delegated nameservers pointing to external domains:

malicious-domain.tld   NS   ns1.attacker-zone.tld
malicious-domain.tld   NS   ns2.attacker-zone.tld
malicious-domain.tld   NS   ns3.attacker-zone.tld
malicious-domain.tld   NS   ns4.attacker-zone.tld
malicious-domain.tld   NS   ns5.attacker-zone.tld
malicious-domain.tld   NS   ns6.attacker-zone.tld
...

If these nameservers do not include glue records, the resolver must resolve each hostname separately:

ns1.attacker-zone.tld   → requires A lookup
ns1.attacker-zone.tld   → requires AAAA lookup

ns2.attacker-zone.tld   → requires A lookup
ns2.attacker-zone.tld   → requires AAAA lookup

ns3.attacker-zone.tld   → requires A lookup
ns3.attacker-zone.tld   → requires AAAA lookup

...

This means that a single original query may trigger dozens of additional recursive queries before resolution can continue. If some of these nameservers are unreachable or intentionally slow, timeout handling and retry logic further increase resolver workload.

In practice, operators may observe that a small number of NXNSAttack domains can generate disproportionate upstream query traffic compared to normal domains.

Why DNS attacks matter for ISPs #

ISPs operate large recursive DNS infrastructures that are constant attack targets. Infected customer devices frequently generate malicious DNS traffic which can:

• Increase resolver load
• Degrade browsing performance
• Increase abuse complaints
• Damage IP reputation
• Increase operational costs

Operational Best Practices for DNS Operators #

DNS operators can significantly reduce the impact of attacks by combining protocol hardening, monitoring and operational discipline. The following practices are commonly implemented in large ISP and enterprise DNS environments:

Resolver protection best practices

• Enable query rate limiting
• Use aggressive DNSSEC negative caching (RFC8198)
• Tune recursive timeouts
• Monitor NXDOMAIN spikes
• Use RPZ threat feeds
• Separate resolver clusters per tenant

Authoritative DNS protection

• Use Anycast deployment
• Deploy multiple providers
• Use response rate limiting (RRL)
• Minimize ANY responses
• Use DNS cookies
• Monitor zone query anomalies

Infrastructure protection

• Deploy DNS over TCP fallback controls
• Maintain excess capacity margins
• Use traffic engineering
• Implement network ACL filtering
• Maintain upstream diversity
• Use dedicated management networks

Monitoring and detection

• Track query entropy patterns
• Monitor cache miss ratios
• Detect botnet query behavior
• Track resolver latency increases
• Alert on abnormal TXT usage
• Detect sudden delegation spikes

Protective DNS operational benefits

Operators deploying Protective DNS commonly observe:

• Reduced malware infections
• Lower abuse complaints
• Fewer IP blacklist incidents
• Improved customer experience
• Reduced support tickets
• Lower incident response costs

Common mistakes DNS operators should avoid

• Running outdated resolver software
• Allowing unrestricted recursion
• Missing DNSSEC validation
• Lack of threat intelligence feeds
• No abuse monitoring
• No query anomaly baselines

Real World Impact of DNS Attacks #

DNS attacks do not only affect infrastructure availability. They often translate into operational and financial impact.

• Customer connectivity degradation
• ISP reputation damage
• Increased incident response workload
• Customer churn risk
• Regulatory exposure in critical sectors
• Security incident escalation

Organizations deploying Protective DNS frequently observe measurable reductions in incident volume after blocking malware domains at the DNS layer.

Related DNS Security Topics #

• What is DNSSEC
• What is RPZ
• What is a DNS resolver
• What is DNS Anycast
• DNS Security Guide