How can a recursive query become a DDoS attack? It doesn't take much. Mike Mullins explains how an attacker can take advantage of a DNS server using recursion to perpetrate a DDoS attack, and he tells you how to prevent your organization's DNS servers from taking part.
Is your public DNS server just waiting to participate in a distributed denial-of-service (DDoS) attack? If it's using recursion, then the answer is yes. DDoS and DNS attacks aren't new, but they're on the rise.
Using authoritative name service, DNS servers primarily advertise to the world the various records associated with the domain they serve. Because users prefer common names and networks prefer numbers, DNS servers handle the translation between what a user types in a browser—such as techrepublic.com—and the actual IP address the network understands.
The task of answering a query recursively is completely different. According to a US-CERT report, between 75 and 80 percent of all DNS servers can handle recursive requests.
Recursive DNS provide answers to queries for records by asking other DNS servers and providing that response to the client that made the request. Here's an example:
- A user enters www.techrepublic.com into a Web browser.
- The computer contacts its local DNS server to determine the IP address of www.techrepublic.com.
- The DNS server looks up www.techrepublic.com in its local tables (i.e., its cache) but does not find it listed.
- The DNS server sends a query to a root server for the IP address of www.techrepublic.com.
- The root server replies with a referral to the top-level domain (TLD) servers for www.techrepublic.com.
- The DNS server then contacts the TLD server to determine the IP address of www.techrepublic.com.
- The TLD server replies with a referral to the name server for www.techrepublic.com.
- The DNS server contacts the name server for www.techrepublic.com to determine the IP address.
- The name server checks a zone file that defines a CNAME record, which shows www.techrepublic.com is an alias of http://www.techrepublic.com. DNS returns both the CNAME and the A record for http://www.techrepublic.com
- The DNS server sends this response to the original client: http://www.techrepublic.com = 18.104.22.168 (with CNAME record www.techrepublic.com=http://www.techrepublic.com).
How can a recursive query become a DDoS attack? For the attack to work, the attacker needs to be in control of one DNS record.
He or she then populates the TXT field of that record with information. (The maximum size of the TXT field is approximately 4,200 bytes.) And then the fun begins. Here's how:
- The attacker programs bots to continuously execute requests for this record against recursive DNS.
- The bots spoof the source IP address of these requests, replacing it with the DDoS target.
- The recursive servers take the record from the attacker-controlled zone, and send it along to the IP address they think the request came from.
Multiply this by the number of bots participating in the attack, and you've got a DDoS attack. If your DNS server is a target of this attack, your network will grind to a halt because none of its clients can resolve an IP address.
What's the solution? It's quite simple: Run two different DNS servers. Let the internal server handle all requests from your network (even recursive for your clients only).
On the external DNS server, disable recursion. With recursion disabled, the external DNS server won't send queries on behalf of other name servers or clients, which stops attackers from bouncing DoS attacks off your DNS server by querying for external zones.
Open DNS recursion isn't the problem—it's a symptom of the problem. IP address spoofing is the real problem, and this spoofing provides a ready venue for DDoS, spam, and other headaches.
In my opinion, IP address verification is the answer, and the tools already exist to solve that problem. I know the Internet Engineering Task Force (IETF) is looking at the issue, but it needs to stop investigating and take action.
Miss a column?
Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.
Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.
Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.