How DNS Retries and Misconfigurations Create Massive DDoS Amplification

TLDR: Researchers have identified a new class of DDoS amplification attacks called TsuKing that exploit the recursive resolution process of DNS. By chaining multiple layers of DNS resolvers and forcing them to retry failed queries, an attacker can amplify a single packet into thousands of responses without needing to spoof source IP addresses. This research exposes critical flaws in how major DNS software like BIND9 and Unbound handle retries and negative caching, providing a blueprint for massive traffic amplification.

Most of the industry still views DNS amplification through the lens of simple, spoofed UDP queries. We have spent years telling clients to implement BCP 38 to stop IP spoofing, assuming that if you stop the spoofing, you stop the amplification. The research presented at Black Hat 2023 on the TsuKing technique proves that assumption is dangerously outdated. By moving the amplification logic from the attacker’s packet generation to the recursive resolution infrastructure itself, attackers can now generate massive traffic volumes using legitimate, non-spoofed queries.

The Mechanics of TsuKing

The core of the TsuKing attack is the abuse of the recursive resolution process. When a DNS resolver receives a query it cannot answer, it acts as a client to other servers, following referrals until it finds an authoritative answer. The researchers identified that this process is not just a simple lookup; it is a complex, multi-layered infrastructure that often involves forwarders, load balancers, and multiple egress points.

The attack relies on three primary variants: DNS-Retry, DNS-Chain, and DNS-Loop.

The DNS-Retry variant is the most straightforward. Many DNS implementations, including BIND9, Unbound, and Knot, are configured to be aggressive when a query fails. If a resolver encounters a packet loss or a server failure, it doesn't just give up. It retries the query multiple times. The researchers found that some resolvers will retry a single failed query over 100,000 times. By sending a single query that is guaranteed to fail, an attacker forces the resolver to flood the target with thousands of retry attempts.

Chaining and Looping for Maximum Impact

While DNS-Retry is effective, the DNS-Chain and DNS-Loop variants are where the amplification factor truly explodes. In a DNS-Chain attack, the attacker coordinates multiple layers of DNS resolvers. The attacker sends a query to the first layer, which is configured to forward it to the second, and so on. Because these resolvers do not share negative caches, each layer treats the forwarded query as a new, failed request, triggering its own set of retries. This creates a multiplicative effect where the amplification factor grows exponentially with each added layer.

The DNS-Loop variant takes this further by creating a circular dependency. The attacker configures a set of resolvers to point back to each other in a loop. Once the loop is triggered by a single query, the resolvers continue to pass the request around, generating a sustained stream of traffic for hours. The researchers demonstrated that a single query could sustain a loop for 24 hours, effectively turning the global DNS infrastructure into a distributed traffic generator.

Real-World Applicability for Pentesters

For those of us on the offensive side, this research changes how we approach network stress testing and infrastructure assessment. During a red team engagement, you are no longer limited by your own bandwidth. If you identify a target organization that hosts its own recursive resolvers or uses a misconfigured internal DNS forwarder, you have a potential amplification vector.

Testing for this is relatively simple. You need to identify if the target resolver honors the RD (Recursion Desired) bit and how it handles negative responses. If you can force a resolver to perform a recursive lookup for a domain you control, you can observe its retry behavior. If the resolver sends multiple queries for a domain that returns a SERVFAIL or NXDOMAIN, you have confirmed the vulnerability.

The impact is significant. Because the traffic originates from legitimate, often high-reputation DNS resolvers, traditional rate-limiting based on IP reputation is largely ineffective. You are essentially weaponizing the target's own infrastructure against itself.

Defensive Strategies for Operators

Defending against TsuKing requires a shift in how we configure DNS software. The primary mitigation is to strictly adhere to RFC 2308, which governs negative caching. If your resolvers are not caching negative results, they are vulnerable to being used as amplifiers.

Operators must also audit their retry logic. While retries are necessary for reliability, they should be capped at a reasonable threshold. There is no legitimate reason for a resolver to retry a query 100,000 times. Furthermore, ensuring that your resolvers honor the RD bit and do not perform unnecessary recursion for external clients is a baseline requirement. If you are running a public-facing resolver, you should be using Response Rate Limiting (RRL) to prevent your infrastructure from being abused.

The era of simple DNS amplification is over. We are now dealing with a more sophisticated threat that exploits the very protocols designed to make the internet resilient. If you are managing DNS infrastructure, it is time to check your retry configurations before someone else does it for you.