DNS Amplification and DDoS Attacks

In October 2016, an attacker sent roughly 620 Gbps of traffic at Dyn's DNS infrastructure using Mirai-infected IoT devices. DNS amplification was part of the toolkit. The result: Twitter, Reddit, Spotify, and most of the US East Coast internet went down for hours. We'll do a full post-mortem in Lesson 08. But the core mechanic — using DNS servers as unwitting weapons — is what we're covering here.

How the Attack Works

DNS amplification exploits two properties of the UDP protocol and DNS server behavior:

UDP source IPs are not verified. A client can send a UDP packet with a forged source IP.
DNS responses are much larger than queries. Sometimes dramatically larger.

The attack flow:

Attacker → DNS server: "Who is example.com?" (spoofed source: victim IP, ~40 bytes)
DNS server → Victim: [large DNS response, 1000-4000 bytes]

The DNS server receives a small query from what appears to be the victim's IP, and sends a large response to the victim. The victim's network gets flooded. The DNS server did nothing wrong — it answered a legitimate query. It just got used as a weapon.

The amplification factor is response_size / query_size. With an ANY query against a large zone:

Query: ~40 bytes
Response: up to 3000-4000 bytes
Amplification factor: 70-100x

A botnet generating 10 Gbps of spoofed query traffic can deliver 700+ Gbps to a target.

Why ANY Records Were Gold for Attackers

The DNS ANY query asks for all records of all types for a name. For a busy domain, this returns a massive payload: A, AAAA, MX, TXT, SOA, NS records all at once.

After years of abuse, RFC 8482 (January 2019) updated the ANY behavior specification: resolvers are now permitted to return a "minimal response" to ANY queries rather than everything. Most modern resolvers and authoritative servers implement this now.

Attackers adapted. DNSKEY queries (used in DNSSEC), HTTPS records, and DNSKEY + DS combinations now offer comparable amplification factors against DNSSEC-signed zones.

How Attackers Find Open Resolvers

An open resolver is a DNS resolver that answers queries from any IP. You need one for public resolvers like 8.8.8.8 or 1.1.1.1 — they're designed to be open. The problem is the tens of millions of misconfigured recursive resolvers that are accidentally open.

Finding them is trivial:

# Shodan search — run in a browser, no tools required
port:53 "recursion: enabled"

Shodan indexes hundreds of millions of internet-facing services. A search for open DNS resolvers returns a ready-made list of amplification targets. The Open Resolver Project (openresolverproject.org) at its peak in 2013 found 28 million open resolvers. By 2024 that number has dropped significantly due to ISP-level filtering, but millions remain.

Attackers don't even need Shodan. They maintain their own lists. After initial scanning, a list of 1 million working open resolvers takes minutes to build with masscan or zmap.

Mitigations

BCP38: Fix the Root Cause

RFC 2827 (BCP38), published in 2000, describes ingress filtering: routers should drop packets with source IPs that couldn't legitimately originate from that network. If your customer is on subnet 192.0.2.0/24, their router should not be forwarding packets with source IPs from 8.8.8.8.

If every ISP implemented BCP38, IP spoofing would be largely impossible, and amplification attacks would stop working. ISPs have not universally implemented it. Some are negligent. Some have technical reasons (asymmetric routing). The MANRS (Mutually Agreed Norms for Routing Security) initiative tracks adoption — as of 2024, compliance is still far from universal.

You cannot fix BCP38 non-compliance yourself. What you can do is not contribute to the problem, and use other mitigations on your own resolvers.

Don't Run an Open Resolver

If you run a resolver, restrict it to known clients:

# BIND — named.conf
acl "internal" {
    10.0.0.0/8;
    192.168.0.0/16;
    172.16.0.0/12;
};

options {
    allow-recursion { internal; };
    allow-query-cache { internal; };
};

# Unbound — unbound.conf
server:
    access-control: 0.0.0.0/0 refuse
    access-control: 10.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow

Verify with:

dig @your-resolver-ip google.com
# Should return REFUSED from external IPs

Response Rate Limiting (RRL)

RRL limits the rate at which a nameserver sends identical or near-identical responses. Even if you're an authoritative server (not a recursive resolver), you can be used for amplification if attackers send queries for your zone with spoofed sources.

BIND RRL configuration:

options {
    rate-limit {
        responses-per-second 5;
        window 5;
        slip 2;  # 1 in 2 excess responses sends a truncated reply (TC=1), forcing TCP
    };
};

The slip parameter is important. If you just drop excess responses, it looks like packet loss to legitimate clients. Slip lets you send a truncated response instead, which causes real clients to retry over TCP (which can't be spoofed). Attackers' spoofed queries can't use TCP — they drop out. Legitimate clients reconnect successfully.

Anycast Distribution

Large DNS operators (Cloudflare, Akamai, NS1) use anycast: the same IP address is announced from dozens or hundreds of PoPs globally. When an amplification attack targets 1.1.1.1, that traffic gets distributed across Cloudflare's entire network rather than hitting a single datacenter.

This doesn't stop the attack, but it dilutes it. 1 Tbps of attack traffic spread across 285 PoPs is 3.5 Gbps per PoP — manageable. 1 Tbps hitting a single datacenter is not.

If you're running DNS for a high-value target, consider hosted authoritative DNS with anycast distribution (Route53, Cloudflare, NS1) rather than running your own nameservers.

What Large Operators Actually Do

Cloudflare's approach (publicly documented): anycast + DDoS scrubbing centers + BGP blackhole routing for the most severe attacks. When a major amplification flood hits, they can null-route the targeted IP at the BGP level — redirecting attack traffic to a black hole before it enters their network. The IP goes dark temporarily, which hurts, but it protects the surrounding infrastructure.

Akamai uses a similar model with their Prolexic DDoS scrubbing service: traffic is rerouted through scrubbing centers that filter attack traffic and forward clean traffic.

At your scale: hosted DNS with built-in DDoS protection is the practical answer. If you must run your own nameservers, anycast + RRL + monitoring gets you most of the way there.

Detecting That You're Being Used

If you're an open resolver being abused for amplification, you may see:

Sudden spike in outbound UDP traffic
High query rates for large record types (ANY, DNSKEY) from a single source
Your upstream provider sending abuse complaints

# Check query rate by type (tcpdump on DNS port)
tcpdump -i eth0 -n port 53 | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# BIND query log analysis
grep "query:" /var/log/named/query.log | awk '{print $8}' | sort | uniq -c | sort -rn | head -20

Key Takeaways

DNS amplification works by spoofing the victim's IP and letting DNS servers do the heavy lifting. Factors up to 70-100x are achievable.
ANY queries were the classic vector. Modern attacks use DNSKEY and HTTPS records.
Open resolvers are the weapon. Don't run one. Verify yours isn't open.
BCP38 (ingress filtering) is the industry-level fix that isn't universally deployed.
RRL on your authoritative servers limits abuse even when you're not a resolver.
For high-value DNS, anycast distribution + hosted DDoS-protected DNS beats self-hosted every time.

Up Next

Lesson 03 covers cache poisoning — specifically the Kaminsky attack from 2008, which is one of the most elegant exploits in DNS history. Understanding it changes how you think about resolver security.