What DNS amplification actually
looks like on the wire

Back to Blog

Quick Refresher: How DNS Amplification Works

DNS amplification is a reflection attack. The attacker sends a small DNS query to an open resolver, but spoofs the source IP to be your server's IP. The resolver processes the query and sends the (much larger) response to you. The attacker never sends traffic directly to your server. All the traffic comes from legitimate DNS resolvers.

The amplification factor is what makes this devastating. A 60-byte DNS query requesting an ANY record for a domain with large DNS records can generate a 3,000-4,000 byte response. That's a 50x to 70x amplification factor. An attacker with 100 Mbps of outbound bandwidth can generate 5-7 Gbps of attack traffic directed at your server.

The mechanics in three steps:

1. Attacker sends a DNS query to an open resolver. The query's source IP is spoofed to be your server's IP. The query requests a record type that generates a large response (ANY, TXT with large records, or DNSSEC-signed zones).
2. The resolver processes the query and generates a response. It doesn't verify whether the source IP actually sent the query. It just sends the response to the address in the source field.
3. Your server receives the response. It never asked for this DNS data. But the resolver doesn't know that, and UDP has no handshake to verify. Multiply this by thousands of resolvers, and your inbound pipe fills up with unwanted DNS responses.

Watching It Happen with NetHawk

Theory is useful. Seeing it happen is better. Let's walk through what a DNS amplification attack actually looks like when you're watching it in real time.

Start NetHawk on the target server:

sudo nethawk -i eth0

Under normal conditions, the dashboard shows something like this:

Bandwidth:  45 Mbps          PPS: 12,400
Protocol:   TCP 94%  UDP 4%  ICMP 2%
Severity:   NORMAL

Top Ports:  443 (68%)  80 (22%)  22 (3%)  53 (1%)
Top IPs:    (normal distribution, no single IP dominant)

Now the attack begins. Within seconds, the dashboard shifts dramatically:

Bandwidth:  2.8 Gbps  (peak: 3.1 Gbps)    PPS: 890,000
Protocol:   TCP 3%  UDP 96%  ICMP 1%
Severity:   CRITICAL
Attack:     DNS Amplification

Top Ports:  53 (94%)  443 (3%)  80 (2%)
Top IPs:    8.8.8.8 (2.1%)  1.1.1.1 (1.8%)  208.67.222.222 (1.4%)  ...

Every number on that dashboard is telling you the same story. Let's break down each signal.

Signal 1: Protocol Distribution Flips

The single most obvious indicator is the protocol breakdown. Normal web server traffic is almost entirely TCP. HTTP, HTTPS, SSH, database connections: all TCP. A server that was running 94% TCP suddenly showing 96% UDP is a red flag you can spot in under a second.

DNS responses are UDP. When thousands of resolvers simultaneously start sending you large UDP DNS responses, the protocol ratio inverts almost instantly. This signal alone tells you something is very wrong, even before you look at anything else.

Signal 2: Port 53 Dominates Destination Ports

The reflected DNS responses arrive with source port 53. Your server's destination port will be random (the spoofed query used a random source port, which becomes the destination port in the response), but NetHawk's top port analysis shows port 53 dominating the source side of the traffic.

Under normal operation, port 53 barely registers on most servers. It might account for 1-2% from your server's own outbound DNS lookups coming back. Seeing it at 90%+ is a textbook amplification signature.

Signal 3: Source IPs are Legitimate DNS Resolvers

This is the part that confuses people the first time they see it. The top source IPs during a DNS amplification attack aren't sketchy botnet nodes. They're Google's public DNS (8.8.8.8), Cloudflare (1.1.1.1), OpenDNS (208.67.222.222), and thousands of other legitimate resolvers around the world.

You can't just block these IPs. They're real DNS servers that your own applications might depend on. Blocking 8.8.8.8 could break your server's outbound DNS resolution. This is exactly why reflection attacks are so effective: the traffic comes from legitimate sources, making simple IP-based filtering impractical.

Signal 4: Packet Sizes are Unusually Large

Normal DNS responses for A/AAAA records are small, typically 50-100 bytes. Amplification queries specifically request record types that generate large responses. During an amplification attack, the average packet size jumps significantly. You'll see average sizes of 1,000-4,000 bytes, far above normal DNS traffic.

NetHawk's JSON output captures average packet size, making this easy to spot programmatically:

sudo nethawk -json | jq '{avg_pkt_size, severity, pps}'

{
  "avg_pkt_size": 3214,
  "severity": "CRITICAL",
  "pps": 890000
}

An average packet size above 1,000 bytes combined with UDP-dominant traffic from port 53 is as clear a fingerprint as you'll find.

Signal 5: The Sparkline Tells the Story

NetHawk displays a 60-second sparkline of traffic history. During a DNS amplification attack, the pattern is distinctive: a sharp vertical spike that sustains at a plateau. Unlike legitimate traffic surges that ramp up gradually over minutes or hours, amplification attacks go from baseline to full volume in seconds. The sparkline shows a flat line, then a wall.

This pattern exists because the attacker launches queries to thousands of resolvers simultaneously. All those resolvers respond within a few hundred milliseconds. The traffic arrives as a near-instantaneous flood, not a gradual increase.

Why DNS Amplification Still Works in 2026

You'd think that after years of awareness, open resolvers would be locked down and this attack vector would be dead. It's not, for several reasons.

First, there are still millions of open resolvers on the internet. Many are misconfigured recursive resolvers on small ISPs, embedded devices, and forgotten servers. The Open Resolver Project and similar initiatives have reduced the number, but the long tail is enormous.

Second, source IP spoofing is still possible on many networks. BCP38 (network ingress filtering) would prevent spoofed packets from leaving a network, but adoption remains incomplete. Attackers only need to find hosting providers or compromised networks that don't filter spoofed traffic.

Third, DNSSEC actually makes the amplification factor worse. DNSSEC-signed responses include cryptographic signatures that add significant size to the response. A DNSSEC-signed ANY response for a well-configured domain can easily exceed 4,000 bytes. The security mechanism that authenticates DNS responses also makes them better amplification weapons.

What to Do When You See This

Once you've confirmed DNS amplification with NetHawk, you have several response options depending on your infrastructure:

• Rate limit UDP port 53 inbound. If your server is not a DNS server, you can safely drop most inbound UDP traffic from port 53 above a reasonable threshold. A simple iptables rule handles this for small attacks.
• Ask your upstream to filter. If the attack exceeds your link capacity, no amount of local filtering helps because the packets are already filling your pipe. Your hosting provider or upstream transit provider can apply filters closer to the network edge.
• Deploy FlowSpec rules. If your router supports BGP FlowSpec, surgical filtering rules can drop amplification traffic at the network edge without affecting legitimate traffic.

For a single incident on a single server, manual investigation with NetHawk and manual iptables rules might be all you need. But if this is a recurring problem, or if you have multiple servers to protect, manual response doesn't scale.

From Observation to Automated Response

NetHawk is a diagnostic tool. It shows you what's happening on one server, right now. It's perfect for confirming an attack and understanding the vector. But it doesn't stop the attack, it doesn't alert your team, and it doesn't work across multiple servers simultaneously.

Flowtriq takes the same packet-level analysis that NetHawk provides and adds the layers you need for production protection:

• Continuous monitoring. The Flowtriq agent runs 24/7 on every server, not just when someone SSH's in to investigate. It catches the attack in the first seconds, whether anyone is watching or not.
• Per-node baselines. Instead of a fixed PPS threshold, Flowtriq learns what normal traffic looks like for each server individually. A game server that normally handles 200K PPS has a different "suspicious" threshold than a marketing site at 5K PPS. Dynamic baselines mean fewer false positives and faster detection of real anomalies.
• Automated mitigation. When a DNS amplification attack is detected, Flowtriq can deploy firewall rules or FlowSpec rules automatically in seconds. The attack is classified, the mitigation is applied, and an alert goes to your team. No manual intervention required.
• Full PCAP capture. Flowtriq captures packet data during incidents for post-attack forensics. You get the full evidence trail, not just "there was a DNS amp attack at 3 PM."

Start with NetHawk to understand what's hitting your servers. Move to Flowtriq when you need that understanding to happen automatically and at scale.

Back to Blog

Related Articles