A DNS amplification attack turns ordinary DNS infrastructure into a source of unwanted traffic aimed at a victim. The attacker sends relatively small queries with a forged source address, and misconfigured or exposed DNS servers send larger responses to that address. When the process is repeated through many servers, the victim receives a flood it never requested.

This attack combines two ideas: reflection hides the true source by directing replies elsewhere, while amplification makes the returned traffic larger than the traffic sent by the attacker. Understanding both parts helps DNS operators avoid becoming reflectors and helps organizations prepare defenses for large inbound floods.

How DNS reflection and amplification fit together

Reflection redirects the reply

Many traditional DNS exchanges use UDP. Because UDP does not establish a connection before data is sent, networks that permit source-address spoofing can allow a packet to claim that it came from the victim’s IP address. A DNS server then sends its answer to the forged address rather than to the attacker.

Amplification increases the traffic volume

A DNS response can be larger than its query. The exact difference depends on the question, the available records, protocol options, and the server’s response. Attackers seek situations where small requests trigger significantly larger replies, multiplying the traffic that reaches the victim.

The underlying resolver role is explained in What is the role of the Recursive DNS server?. A recursive resolver should normally serve an intended group of clients. When it accepts recursive queries from arbitrary Internet addresses, it can become an open resolver and a useful reflector for abuse.

Why DNS is attractive for reflection attacks

• DNS is widely deployed. Authoritative and recursive servers are essential parts of Internet infrastructure.
• UDP supports efficient queries. That efficiency also means the server can respond without a connection handshake.
• Some resolvers are exposed unnecessarily. Incorrect access controls may allow anyone on the Internet to request recursion.
• Responses vary in size. Some legitimate DNS answers contain multiple records, signatures, or other data and are much larger than the request.
• Source spoofing still exists. Networks that do not filter packets with implausible source addresses enable reflection.

Large DNS responses are not inherently malicious. DNSSEC signatures, IPv6 records, mail records, and other legitimate data can all increase response size. The security problem is the combination of spoofed traffic, exposed services, and repeated requests designed to create a flood.

Signs that a resolver may be abused

Operators should look for behavior that differs from the server’s normal client and query profile. Possible indicators include:

• a sudden increase in queries from many unrelated or unexpected addresses;
• repeated requests for the same names or record types;
• an unusual ratio of outbound response bytes to inbound query bytes;
• high UDP response volume without a matching increase in legitimate users;
• queries arriving on interfaces or from networks that should not use recursion;
• bandwidth, CPU, or packet-rate alerts on DNS systems and edge devices.

These signals require context. A public authoritative server naturally receives queries from many networks, while a corporate recursive resolver should have a much narrower client population. Baselines and role-specific alerting are more useful than one universal threshold.

How recursive DNS operators can reduce abuse

Disable open recursion

Recursive service should be limited to authorized clients through access-control lists, network boundaries, and firewall policy. If a server is intended only for an internal network, it should not answer recursive requests from the public Internet.

Separate recursive and authoritative roles

Running recursion and public authoritative service on separate systems makes access policy clearer and reduces the chance that a necessary public-facing server accidentally provides recursion to everyone.

Keep DNS software and policy current

Apply supported software updates, remove unnecessary features, review listening interfaces, and test the service externally. Configuration drift can expose recursion even if the original deployment was secure.

Monitor response volume and client eligibility

Track packets, bytes, response sizes, query types, source networks, and rejected requests. Alerts should highlight traffic from outside approved client ranges and sudden changes in the response-to-query ratio.

How authoritative DNS operators can help

Public authoritative servers must answer Internet queries, so they cannot use the same client allowlist as private resolvers. They can still reduce abuse and improve resilience:

• Use response rate limiting where appropriate. Carefully configured RRL can reduce repeated similar responses without blocking normal traffic.
• Serve minimal necessary data. Avoid unnecessary additional records and remove obsolete zone content while preserving standards-compliant answers.
• Distribute capacity. Anycast, multiple locations, and independent authoritative providers can prevent one site from becoming the only bottleneck.
• Monitor answer correctness as well as availability. A reachable server returning inconsistent data is still unhealthy.
• Prepare upstream mitigation. Large floods may need filtering or scrubbing before they reach the authoritative network.

A Managed DNS service may provide distributed capacity, monitoring, and mitigation features, but organizations should verify the actual architecture and incident process rather than relying only on a product label.

Source-address validation is essential

Reflection depends on forged source addresses. Network operators can reduce this capability by filtering traffic whose claimed source should not be reachable through the interface where it arrived. This practice is often described as ingress or egress filtering, depending on where the check occurs.

DNS administrators cannot solve global source spoofing alone. Internet service providers, hosting networks, cloud platforms, and enterprise edge operators all contribute by validating source addresses close to where traffic enters their networks.

Protecting an organization that is the target

A victim cannot directly reconfigure the third-party reflectors sending the traffic. Defensive preparation should therefore focus on absorbing, distributing, or filtering the flood before it overwhelms the destination:

• coordinate DDoS procedures and escalation contacts with network providers;
• use upstream scrubbing or managed protection sized for realistic attack volumes;
• distribute public services across independent locations and networks;
• monitor packet rate and bandwidth, not only application CPU and request logs;
• maintain tested incident runbooks for routing, filtering, communication, and recovery;
• preserve evidence and timestamps for provider coordination and later analysis.

The historical examples in 4 DDoS attacks in recent history show why mitigation capacity and coordination must exist before an incident starts.

Controls that address different problems

Several useful DNS controls are sometimes confused with amplification defenses:

• DNSSEC authenticates DNS data but does not prevent a server from receiving spoofed queries. Its larger signed responses also make careful server policy important.
• Short TTL values change cache duration; they do not stop reflected traffic.
• DNS caching improves efficiency for clients but does not secure an open resolver exposed to arbitrary users.
• Blocking all UDP DNS can break legitimate service and force different failure modes. Defenses should be role-aware and standards-compatible.

A practical defensive checklist

1. Inventory every DNS server and identify whether it is recursive, authoritative, or both.
2. Test from outside approved networks to confirm that private recursion is not publicly available.
3. Restrict recursive clients and separate public authoritative service where possible.
4. Enable suitable rate controls, logging, and traffic baselines.
5. Ask connectivity providers how they implement source-address validation.
6. Confirm DDoS escalation paths, mitigation capacity, and monitoring coverage.
7. Retest after software, firewall, network, or DNS configuration changes.

Conclusion

DNS amplification attacks succeed when forged queries can reach servers that return larger replies to the victim. No single control solves the entire problem. Restricting recursion, validating source addresses, minimizing unnecessary responses, applying rate controls, distributing authoritative capacity, and preparing upstream mitigation each remove a different part of the attack path.

For an overview of this and other threats, see 5 DNS attacks that could affect you. Detailed guidance for preventing recursive nameservers from becoming reflectors is provided in RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks.