The Unwitting Accomplice
Imagine setting up a new Linux server, installing BIND9 or Unbound to manage your domain's DNS, and leaving the default configuration intact. You go to sleep, feeling productive. By morning, your cloud provider has suspended your account, citing "Malicious Network Activity."
You check your logs. Your server hasn't been hacked. Nobody guessed your SSH password. You don't have any malicious cron jobs running. Yet, your server was just used to blast 500 Gigabits of data per second at a rival gaming company, taking them completely offline.
You have become the victim of—and the weapon in—a DNS Amplification Attack. And it happened because you left your DNS server operating as an "Open Resolver."
What is an Open Resolver?
To understand the attack, you must understand the difference between an Authoritative DNS server and a Recursive DNS server.
- Authoritative Servers: These servers hold the actual zone files (A records, MX records) for specific domains you own. When asked, "What is the IP of mydomain.com?", they confidently answer.
- Recursive Resolvers: These servers act as middlemen (like Google 8.8.8.8 or your ISP's DNS). When asked, "What is the IP of google.com?", they go out to the internet, ask the root servers, find the answer, cache it, and return it to the user.
An Open Resolver is a Recursive DNS server that is publicly accessible to the entire internet and is willing to answer queries for any domain from any IP address.
If you are running a public DNS service like Cloudflare (1.1.1.1), being an Open Resolver is your business model. If you are a standard enterprise running a mail server or hosting a few websites, being an Open Resolver is a catastrophic configuration error.
The Mechanics of DNS Amplification
A DNS Amplification Attack is a type of Distributed Denial of Service (DDoS) attack that exploits the stateless nature of the UDP protocol. Here is the step-by-step breakdown of how attackers weaponize your open resolver:
1. IP Spoofing
The User Datagram Protocol (UDP) does not require a handshake (unlike TCP). When a packet is sent via UDP, the sender simply slaps a "From" IP address and a "To" IP address on it and throws it into the network.
An attacker crafts a malicious DNS query packet, but instead of putting their own IP address in the "From" field, they spoof (forge) the IP address of their intended victim.
2. The Query
The attacker sends this spoofed query to your misconfigured Open Resolver.
3. The Amplification Factor
The attacker doesn't just ask for a simple A record. They ask for something massive. They typically query a domain known to have massive TXT records or heavy DNSSEC cryptographic keys, and they use the ANY query type to request every record simultaneously.
The attacker's initial query packet might be tiny—perhaps 60 bytes.
Your Open Resolver does its job. It fetches the massive payload of DNSSEC keys and TXT records. The resulting response packet is huge—often over 4000 bytes. This represents an amplification factor of nearly 70x.
4. The Attack
Your server takes this massive 4000-byte response and sends it back to the "From" address. Because the attacker spoofed the "From" address, your server fires the massive payload directly at the victim.
The attacker utilizes a botnet to send thousands of these 60-byte spoofed queries to thousands of different Open Resolvers simultaneously. The victim's server suddenly receives a tidal wave of massive DNS responses they never asked for, instantly saturating their network bandwidth and taking them offline.
How to Secure Your Infrastructure
Securing your DNS infrastructure against amplification exploitation is straightforward but requires explicit configuration changes.
Rule 1: Disable Recursion for Public Interfaces
If your server is only meant to act as an Authoritative server for your own domains, you must entirely disable its ability to perform recursive queries.
In BIND9 (named.conf.options):
options {
recursion no;
additional-from-auth no;
additional-from-cache no;
};
Rule 2: Restrict Recursion to Trusted Subnets
If your server must act as a recursive resolver for internal office networks or specific VPN clients, you must use Access Control Lists (ACLs) to ensure it only answers queries from those trusted IP ranges, and drops queries from the public internet.
In BIND9 (named.conf.options):
acl "trusted" {
10.0.0.0/8;
192.168.1.0/24;
localhost;
};
options {
recursion yes;
allow-query { trusted; };
allow-recursion { trusted; };
};
Rule 3: Implement Response Rate Limiting (RRL)
Even authoritative servers can be abused in smaller-scale reflection attacks. Modern DNS software supports Response Rate Limiting (RRL), which automatically throttles identical responses sent to the same IP subnet within a short timeframe.
In BIND9 (named.conf.options):
options {
rate-limit {
responses-per-second 10;
window 5;
};
};
The Bottom Line
Operating an open recursive resolver on the modern internet is widely considered negligent. Attackers constantly scan the IPv4 space looking for port 53 vulnerabilities. By auditing your DNS daemon configurations and locking down recursion, you protect your own bandwidth and prevent your infrastructure from being drafted into the next massive DDoS botnet. Use our DNS Lookup Tool to query your own servers and ensure they return REFUSED for external domains.