And Here They Come Again: DNS Reflection Attacks

Published: 2022-08-10. Last Updated: 2022-08-10 14:32:25 UTC
by Johannes Ullrich (Version: 1)

I know I have written about this same attack before [see here]. But well, it just doesn't stop. There has been a continuous stream of these requests to our sensors ever since. Some of the currently preferred queries used:

ANY? peacecorps.gov. (the irony... but look at the record. It is asking for amplification. It seems like they built it to max out EDNS0)
ANY? sl.

Current targets appear to be a couple of networks in Brazil. I am not aware of any particular valuable sites being hosted by them.

But the systems they are hitting with these persistent attacks are not even acting as DNS servers anymore (and haven't been open reflectors for years). All they do with their queries is pollute the internet without effect, like throwing a candy wrapper in a stream with the candy still in it.

Either way. Let's use this to review a quick checklist on proper DNS server configuration:

1. Have Distinct Authoritative and Recursive Name Server

Authoritative name servers will answer queries from anybody for specific zones. Keep them in the cloud and forget about the details. Recursive servers will answer any query from a particular constituency. Keep them inside your network, make them forward queries to a resolver of your choice, and monitor them closely.

Having an internal recursive resolver and tightly restricting outbound DNS traffic can be an invaluable detection and response resource (e.g., Pi-Hole for home use). You may gain a bit of speed by forwarding queries to a resolver like '8.8.8.8' or similar instead of resolving it recursively. It also makes your firewall configuration easier.

2. Diversity of Your Authoritative Name Servers

I mentioned putting them into the cloud. I meant to say: At least two clouds. And come up with a secure way to manage them. Let me know what tricks you have to make this work for you.

3. Use DNSSEC at your own risk

I do not say, "do not use it." But if you do: Make sure you halfway understand how it works and what it does. I use DNSSEC on some of my domains, and due to me not understanding it well, I had some outages (for example, for dshield.org) in the past.

4. Monitor Your Domains

Someone intentionally or not making unauthorized changes to your domain/zone can cause some interesting issues. If you like "interesting,": go for it. If you want to keep your job, get paid, and not work too much overtime: Put some monitoring in place to alert you about changes. The monitoring system can do simple periodic zone transfers and look for changes. Do not just rely on the serial number.

5. Do not overload DNS with other crap

Sometimes, people abuse DNS as a database. It is not a database and never was built to be used as one. If you insist: Use a distinct domain and infrastructure. Oh. It can be pretty, fast, and reliable. Until it is not.

6. DNS is not "set it and forget it."

DNS is pretty low maintenance in most configurations. But remember to keep things up to date and do a thorough configuration review from time to time. DNS is one of those services suffering from the death of thousand cuts: You tend to make lots of little "inconsequential" changes that pile up to something that just no longer works.