Do You Know If Your DNS Server Can Be Used For DDoS Attacks?
So you have an Internet-facing DNS server. Maybe you decided to set one up at home for fun, or your company has one that works with other services. Either way, you probably have a group of people in mind who should be using it. But are you sure that they’re the only ones who would be interested in it?
You may have heard about the dangers of open mail relay servers: attackers can use improperly configured SMTP servers to send spam or phishing email to victims, so it’s the responsibility of the people running them to make sure they can’t be used for evil. Similarly, improperly configured DNS servers can be used to launch attacks, so checking how yours is set up is an important part of being a good Samaritan on the Internet.
If you’re not familiar with DNS, the simplest analogy is that it’s akin to an elaborate phone book using domain names and IP addresses instead of people and phone numbers. Queries to authoritative DNS servers will return the IP address (or other information) of a hostname only if the server has that information on hand. Recursive DNS servers reach out to other servers to answer questions or resolve queries about a hostname if they do not have an answer but know where to find it. If you’re interested in a more comprehensive explanation, DigitalOcean has a great deep-dive into the fundamentals of DNS.
A DNS resolver is considered fully “open” if it resolves any type of query from any source IP. This gives an attacker the greatest number of options. They may even use the DNS server to snoop on the type of websites you’ve been visiting with a technique known as DNS cache snooping. In this blog post, we’ll be looking at how DNS resolver can be used in Distributed Denial of Service (DDoS) attacks via amplification.
To perform DDoS attacks via amplification, attackers will use very small DNS requests to return answers that are many times larger (amplified). The initial request is forged so that it appears to be coming from the victim’s IP address, and in turn, the DNS server sends the amplified response to the victim. With enough spoofed requests coming from enough open DNS resolvers, the recipient’s resources may be exhausted and unable to accept normal traffic.
Let’s take a look at a few examples of DNS requests using the dig command. Dig is included by default on most distributions of Linux and Mac OS X. Windows users can access dig by performing a “Tools Only” installation of the latest version of BIND.
The command
dig +qr @8.8.8.8google.com
will give us a good idea of how big a typical DNS query is. @8.8.8.8 tells dig to query Google’s DNS resolver at 8.8.8.8, google.com is the hostname to query, and adding the +qr flag returns the query size in the command output. The answer size is returned by default.
This request is fairly small and balanced. The request is 51 bytes, and the response is only a bit larger at 55 bytes. An attacker would not be interested in making this type of query because it only has an amplification factor of a little over 1.0.
Now let’s do another query with the same resolver and host, but this time specify that any resource record type should be returned, with the command:
dig +qr @8.8.8.8google.com any
This query has an amplification factor of about 13, which is much more appealing to an attacker. It allows them to minimize the amount of resources expended while inflicting more damage on a target.
If a DNS server is set up to resolve queries, an attacker may use it to make requests to their own servers specifically set up for this purpose, triggering responses up to 80 times larger than the original request. For this reason, recursive DNS servers pose the greatest risk.
Even if the server is non-recursive, it may be possible to generate large DNS responses under normal circumstances, and in these situations mitigating attacks can be trickier. Response rate limiting and IP whitelisting are usually the most effective ways to mitigate DNS amplification attacks on a non-recursive DNS server.
So what can you do to mitigate the risk of your server being used in an attack?
- Check the settings on your DNS server and restrict the allowed query types wherever you can. Queries for ANY resource record types, especially, should be disabled if possible. To see if your server will respond to an ANY request, use the following command:
dig +qr @8.8.8.8 whitehouse.gov. ANYReplace 8.8.8.8 with the IP addresses of your name servers one at a time, and replace whitehouse.gov. with your domain. If you get back any answers, your DNS server does respond to ANY requests.
- Disable support for recursive resolution if it is not needed. Older versions of common DNS servers enable recursion by default, so double-check that this feature is not enabled unintentionally. To test this, place a query to your nameservers for a domain for which they aren’t authoritative:
dig +recurse @8.8.8.8 www.yahoo.com. ALike before, run it multiple times, each time replacing 8.8.8.8 with one of your nameservers. This time though, keep “www.yahoo.com. A” as-is: you want to ask a question your nameservers wouldn’t normally answer. If you get back any answers, that nameserver will respond to recursive requests. If you don’t get any answers, it doesn’t.
- Implement rate limiting on the number of queries accepted per minute. This is especially important if recursion is required or if the server returns large authoritative responses.
- Only allow queries from trusted hosts. To test, try running this command from an address outside your network (again, replacing 8.8.8.8 with each of your nameservers in turn):
dig @8.8.8.8 www.mycompany.com. AIf this succeeds, you may need to limit the networks to which you’ll answer queries.
You should always know what kinds of things are running on your network and what they’re capable of. Checking your DNS server configurations is a great way to make the Internet just a little bit safer overall.
(Special thanks to Bill Stearns for providing additional configuration checks!)
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
