How DNS Amplification Attacks Work: A Step-by-Step Breakdown
Attackers exploit public resolvers to turn tiny queries into massive floods, amplifying traffic by orders of magnitude through protocol quirks.
DNS amplification attacks spoof your IP address in requests to open resolvers. These servers send large responses to you, overwhelming your connection. Defenses require blocking spoofed packets at the source and filtering large UDP responses at the edge.
The Anatomy of Protocol Asymmetry
Domain Name System (DNS) operates on a request-response model using the User Datagram Protocol (UDP). UDP is connectionless, meaning it sends packets without verifying the recipient is ready to receive them. This design allows for high speed but lacks inherent integrity checks. Attackers exploit the size difference between a standard query and a potentially large response. A query asking for all records in a zone can be small, while the answer containing those records is significantly larger. This ratio creates the amplification effect.
Stage 1: Reconnaissance and Target Selection
The attacker begins by identifying a target with a relatively small internet bandwidth capacity. They also locate open recursive DNS resolvers that accept queries from any source on the internet. These resolvers are often misconfigured or part of public services. The attacker needs a list of these IP addresses to use as reflectors. They verify that the resolvers are reachable and that they respond to queries with large amounts of data. This phase is silent and leaves little trace on the target’s network.
Stage 2: Source Address Spoofing
The attacker crafts DNS query packets. Crucially, they alter the source IP address field in the IP header. Instead of using their own address, they insert the victim’s IP address. This technique is known as IP source address spoofing. The attacker does not expect a reply; they intend for the victim to receive it. Standard UDP packets do not verify the sender’s identity, allowing this forgery to succeed at the packet level. The packet looks legitimate to intermediate routers and the target resolver.
Stage 3: Query Flood to Resolvers
The attacker sends these spoofed queries to the list of open resolvers. Because the attacker controls the sending rate, they can generate thousands or millions of queries per second. The queries are small, often just a few dozen bytes. The attacker uses many compromised machines or cloud instances to generate this volume, masking their origin. The resolvers receive these requests and process them normally. They assume the request is legitimate because it comes from a valid IP format and uses standard DNS syntax.
Stage 4: Resolver Processing and Amplification
Each resolver receives the spoofed query and looks up the requested domain. If the query asks for a zone transfer or all records (ANY record, though deprecated, or similar large queries), the resolver compiles a large response. This response can be hundreds or thousands of times larger than the original query. The resolver then packages this data into UDP packets. It sets the destination IP address to the source IP found in the query header. In this case, that is the victim’s address. The resolver sends this large payload back into the internet.
Stage 5: Traffic Reflection and Congestion
The large response packets travel across the internet toward the victim. Because the packets appear to originate from legitimate DNS servers, they pass through many firewalls and intrusion detection systems. These security tools often allow outbound DNS traffic by default. The victim receives a massive influx of UDP packets. Their network interface becomes saturated. The bandwidth is consumed by these unwanted packets, leaving no capacity for legitimate traffic. This results in a denial of service. Legitimate users cannot access the victim’s services.
Stage 6: Sustained Attack and Mitigation Failure
The attacker continues to send spoofed queries to maintain the flood. If the victim’s bandwidth is smaller than the aggregate output of the resolvers, the attack succeeds. Simple rate limiting may fail because the traffic looks like legitimate DNS responses. The victim cannot easily block the source IPs because they are distributed across many legitimate DNS servers. Blocking all DNS traffic would break normal operations. The attacker can shift to new resolvers if some are blocked. The attack persists until the source of spoofed packets is identified or the resolvers are closed.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Reconnaissance | Attacker finds open resolvers and targets. | Close open resolvers; use non-standard ports. |
| Spoofing | Attacker fakes victim IP in packet header. | Implement BCSP (Bogon Filtering) and uRPF. |
| Query Flood | Attacker sends small queries to resolvers. | Rate limit outbound DNS queries at ISP edge. |
| Amplification | Resolver sends large response to victim. | Block ANY records; limit response size. |
| Reflection | Large packets flood victim’s bandwidth. | Filter large UDP responses; upstream scrubbing. |
| Saturation | Victim’s connection is overwhelmed. | Increase bandwidth; use CDN or cloud protection. |
The Hidden Cost of Open Infrastructure
The flaw relied upon here is not a bug in DNS software, but a design feature of the internet’s trust model. The internet assumes that IP headers are generally truthful. This assumption breaks down when attackers have botnets to send spoofed packets. The cost of fixing this is shared. Network operators must implement source address validation. This is often called uRPF (Unicast Reverse Path Forwarding). It checks if the source IP of a packet is reachable via the interface it arrived on. If not, the packet is dropped. This stops spoofing at the edge.
Integrating Network Controls
You must align DNS security with broader network hygiene. Firewalls must be configured to restrict outbound DNS to known resolvers. This limits the ability of compromised internal hosts to be used in other attacks. Security culture plays a role here. Administrators must understand that open resolvers are a liability. They should be configured to only serve local networks. Public DNS services should implement response rate limiting. This slows down the amplification effect.
The Limits of Application-Layer Defenses
Application-layer filters often miss DNS amplification attacks. The traffic is volumetric and occurs at the network layer. By the time a packet reaches a web server, the connection may already be saturated. Therefore, mitigation must happen at the network edge. Internet service providers can filter spoofed traffic before it enters their backbone. Organizations can use cloud-based protection services that absorb the traffic. These services filter the noise and forward only legitimate requests. This shifts the burden of bandwidth consumption away from the victim.
Long-Term Protocol Evolution
The DNS community has worked to reduce amplification risks. The ANY query type, which requested all records, has been deprecated. Newer query types limit the amount of data returned. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the content but do not inherently solve amplification. In fact, they can make analysis harder. The core issue remains the spoofing of IP addresses. Until source validation is universal, amplification attacks will remain a threat. You must assume that spoofed traffic will always exist.
Key takeaways
- The attack relies on the asymmetry between small DNS queries and large DNS responses.
- IP source address validation is the primary control to prevent spoofing at the network edge.
- Open recursive resolvers act as amplification sources if they respond to unsolicited queries.
Frequently asked questions
Can I stop DNS amplification attacks with a strong password?
No, passwords protect access to accounts, not network bandwidth. This attack exploits protocol mechanics, not authentication failures.
Do firewalls prevent DNS amplification attacks?
Standard firewalls may not stop them if configured to allow DNS responses. You need specific rules to block spoofed packets or limit large UDP responses.
Is DNS amplification the same as a DDoS attack?
It is a type of DDoS attack. It specifically uses reflection and amplification to multiply the attack traffic volume.
How do I know if I am under a DNS amplification attack?
Look for a sudden, massive increase in inbound UDP traffic on port 53 from many different source IPs, particularly known DNS servers. BOTTOM LINE: DNS amplification exploits the size difference between queries and responses via IP spoofing. Implement source address validation and restrict open resolvers to reduce risk.
How this guide was produced: written by the Threat Times editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
