Back to research

Security

DDoS Attack Detection and Mitigation

Quantifying DNS amplification impact and resilience in local infrastructure

From crafted packets to CPU graphs, see how reflection attacks ripple through your DNS stack.

Abstract

Recreated DNS reflection and amplification attacks in a controlled LAN to measure amplification factors, target-side latency and server resource usage. Custom Scapy scripts spoofed victims while varying query types (A, MX, NS, ANY) at 10k–50k packets/s. The study documents latency spikes above 100 ms for ANY requests, CPU saturation during amplified attacks and evaluates mitigation strategies.

About

A BIND9 resolver is configured on Ubuntu machines acting as reflector and victim. Scapy scripts generate spoofed DNS queries at controlled packet rates, while Wireshark, dig, ping and psutil capture network and resource metrics. Amplification factors are computed by comparing request/response sizes for A, MX, NS and ANY records. Latency samples reveal that higher amplification correlates with poorer responsiveness, especially for ANY (>100 ms). When traffic is increased to 50k pps the server cannot respond to all queries, leading to partial reflections and CPU usage soaring from 4% to ~25%. The investigation concludes with mitigation recommendations (rate limiting, response size reduction, ingress filters).

Key results

1.46
AF A
4.14
AF MX
4.46
AF NS
7.30
AF ANY
≈44 ms @10k pps
MX Mean Query Time
≈96 ms @10k pps
NS Mean Query Time
>100 ms @10k pps
ANY Mean Query Time
Mean 174 ms, peaks 400 ms
Amplified Attack (50k pps)
>30% (baseline ~4%)
Server CPU Peak
≤48 ms (minimal)
Ping Latency Impact

Key findings

  • Measured amplification factors were 1.46× (A), 4.14× (MX), 4.46× (NS) and 7.30× (ANY), with ANY producing the strongest reflection.
  • At 10k packets/s the mean dig latency climbed to ~44 ms for MX, ~96 ms for NS and >100 ms for ANY compared with the pre-attack baseline.
  • Raising the flood to 50k packets/s pushed mean query time to 174 ms (peaks 400 ms) and DNS server CPU usage from ~4% to 24.5% (peaks >30%).
  • ICMP ping latency stayed ≤48 ms during all attacks, indicating congestion was confined to DNS processing rather than general networking.

Challenges

  • LAN experiments cannot fully reproduce the bandwidth of real-world botnets, limiting external validity.
  • CPU and RAM measurements rely on software sensors with sampling delays, introducing small inaccuracies.
  • Mitigation strategies were theorised but not validated in the same environment due to time constraints.

Methodology

  1. 01Configure BIND9 resolver and victim hosts on Ubuntu
  2. 02Generate spoofed DNS queries via Scapy with adjustable packet rates
  3. 03Capture request/response traffic and latency using Wireshark, dig and ping
  4. 04Profile server CPU and RAM with psutil while varying record types (A, MX, NS, ANY)
  5. 05Compute amplification factors by comparing response and request payload sizes