Blocking unwanted DNS traffic

You can be perfectly configured end network equipment, complete order in clusters, may be empty trunk and not loaded network core equipment, but if your DNS does not work well, your customers will be unhappy.

A simple conclusion follows from this - your recursive DNS servers must always be available and able to service client requests.
')


All articles on setting up a productive DNS server begin like this: “let's measure the various parameters of various recursive DNS servers and choose the best one of them, and we will be happy”. I can say in advance, happiness will come in this way, but not for long.

The next step is to increase the capacity of the server itself. This method of happiness is also achieved, but with a stable growth of the subscriber base, it quickly ends.

You ask what kind of solution to the problem exists, or rather, what to do in this situation?

The answer is simple - it is necessary to limit the number of recursive requests of certain types from each of our clients. Much to my regret, none of the existing DNS servers has any means of limiting the number of queries of a certain type for each of the recursive clients . We will assign this task to a packet filter, in the examples below, iptables is used.

In most cases, a flurry of DNS queries of various types comes from registered clients, a huge number of MX queries sent to search for ip addresses of mail servers, type A requests for exotic domains like kljhajlhfqweqwe.com or ioweurtisdvfso.org.

According to our rough estimates, 3% of client machines generated more than 90% of all DNS queries.

A simple customer call often does not solve the problem, because the client may not be at home, the client does not have the qualifications, or the client simply does not want to be treated (for me, and so everything works). Also, often when a client port is disconnected, providers leave traffic to the DNS server open so that the client can log into his personal account by his name and see the reason for the blocking, but since the client computer “hits” the DNS server, in order to solve this problem look for another way out.

So we need to solve two simple problems.
1. To determine all valid types of DNS queries that we will process.
2. Find reasonable intervals of each type of requests from each client.

Let's analyze what types of requests can come from our customers and what we can do with them.

The A (address record) or address record associates a host name with an IP address. The most "most useful" type of requests. The values ​​of 100 requests in 10 seconds are quite acceptable even for those customers who surf “well, very quickly” :)

The AAAA (IPv6 address record) record associates a host name with an IPv6 address. As long as IPv6 is not widely distributed, you can leave this type of queries to our DNS server, limiting it to two queries in 10 seconds from each of the clients to empty requests like AAAA localhost. did not affect the operation of the DNS server.

CNAME (canonical name record) or canonical name record. The request type is useful, the lock should be soft so that requests of this type are blocked as little as possible. As well as for requests of type A, 100 requests in 10 seconds is an acceptable value.

The MX (mail exchange) record or mail exchanger indicates the mail exchange server (s) for this domain. For home customers, intensive requests for these types of records clearly indicate that the client’s computer is infected with a virus that sends spam. 5 requests in 60 seconds is enough for the work of diagnostic tools.

The NS (name server) entry points to the DNS server for this domain. Directly, users of home Internet services do not generate such requests, in most cases such requests are formed manually through diagnostic utilities such as nslookup in order to debug the health of their domains, etc. 10 requests of this type in 60 seconds is an acceptable value.

A PTR (pointer) record or pointer record associates the host’s IP with its canonical name. With respect to users of home Internet services, requests of this type come often enough during the work of torrent or p2p clients, to resolve the names of the hosts from which you download and to which you distribute. For example, 50 requests in 10 seconds is an acceptable value, which in most cases is enough for any user.

The SOA (Start of Authority) record or the zone's initial record indicates on which server the reference information about this domain is stored, contains the contact information of the person responsible for this zone, timings (time parameters) of caching zone information and DNS servers interaction. This type of requests can be used by home Internet users only for debugging purposes; we allow each client to make 5 requests in 60 seconds.

An SRV (server selection) entry points to servers for services. This type of requests can be used by home Internet users only for debugging purposes; we allow each client to make 5 requests in 60 seconds.

A complete list of DNS record types can be found here .

In order to understand by what signatures we classify one or another DNS request, we need to “catch” tcpdump by one type of packet, look into the body of the request in the Type field and make sure that:

MX type request contains type - 00 0F in the type field
request type AAAA contains in the field type - 00 1C
Type A request contains in the type field - 00 01
PTR type request contains in the type field - 00 0C
request of type CNAME contains in the type field - 00 05
request of type NS contains in the field type - 00 02
the type request SOA contains in the type field - 00 06
SRV type request contains in the type field - 00 21

Note also that in a DNS query, after the Type field, the Class field goes; it is always 00 01 for the DNS query. Add this field to all signatures to reduce the number of false positives.

So, in order to block DNS requests of type MX, we need to add iptables rules on DNS servers:
-A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j DROP

since we need to close these requests not completely but simply limit their number per unit of time so that these requests do not “send” the server to us just add the recent module to the rules.

For example, a rule that restricts the receipt of DNS MX type requests in 5 requests in 60 seconds will look like this:
-A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --set --name MXFLOOD --rsource

-A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --update --seconds 60 --hitcount 5 --rttl --name MXFLOOD -j DROP

-A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j ACCEPT


Similarly, other types of DNS queries are limited.

Since there are a lot of DNS types and we have resolved all the types of DNS queries we need, it would be nice to ban all other requests so that they are not processed by your DNS server.

-A INPUT -p udp --dport 53 -j DROP


These simple rules allowed us to reduce the number of simultaneous recursive DNS queries to our DNS servers by more than 20 times (from 10,000 to 400), without complaints about the work of the DNS by our users.