BIND – Rate Limiting Options in ISC BIND

binddomain-name-systemrate-limiting

This is a Canonical Question about rate limiting in the ISC BIND nameserver software.

Recently I've heard of BIND's rate limiting features. DNS RRL in particular seems to be becoming more commonplace.

I'm a little bit confused. Some of the documentation seems to say that these features should not be used with recursive DNS servers, but other documents very specifically address recursive DNS infrastructure. Who is right?

Best Answer

While I dearly wish that ISC would document these features better for the sake of users with an experience level below "expert", that is wishful thinking. There are two separate implementations of rate limiting within BIND as of 9.11, and they are targeted at solving two completely different problems.

DNS RRL

The first form of rate-limiting is DNS Response Rate Limiting, usually referred to as DNS RRL. You can read more about the specification here. It is implemented by multiple authoritative nameserver daemons and is not specific to ISC BIND.

DNS RRL is designed to protect authoritative DNS servers, but BIND will not stop you from activating this feature on recursive servers. Many users stumble across the related options in the BIND documentation and assume that these are intended for use with recursive DNS servers. This is not the case. Don't enable this on a recursive server.

If you're running a server that provides authoritative data and recursion, you shouldn't be doing that anyway. By running that configuration you have accepted the additional problems that come with it. We can't help you with that.

FETCHLIMIT

The ISC knowledgebase article for the BIND's fetchlimit code is titled Recursive Client Rate limiting in BIND 9.9.8 and 9.10.3, which makes things confusing. This has nothing to do with DNS RRL.

Unlike DNS RRL, the fetchlimit code is designed to address DNS attack strategies which cause a recursive server to participate in attacks against authoritative servers. Specifically, these options are designed to reduce the number of simultaneous queries that your recursive server will make to individual authoritative DNS server IPs, and/or individual DNS domains. This makes your server less attractive for use in Psuedo Random Subdomain attacks (against others), and also helps to limit the impact to your own DNS servers when they are being used in this kind of attack. (ephemeral port exhaustion, etc.)

Disclaimer

While this Q&A is provided to help clarify the frequently confused differences in the ratelimiting code provided by ISC BIND, neither of these are comprehensive solutions to abuse of a recursive DNS server. Only the latter is intended for use with a recursive DNS server, and even then it is designed to address a specific form of attack that frequently plagues operators of high volume recursive DNS environments.

If your recursive DNS environment is being used to attack others, BIND's rate limiting features are a red herring unless you have already implemented all of the other best practices. (don't run an open resolver, avoid internet facing interfaces on recursive DNS servers in general, drop traffic from unknown networks before it hits the recursive server, etc.) Rate limiting is a value add that you apply in addition to your other abuse reducing strategies. It is not a replacement for them.

Related Solutions

Postfix rate limiting

The config you have now is only going to make sure you only have a single simultaneous delivery to each destination. It's not going to actually throttle anything. I think adding this line to main.cf may accomplish what you want:

slow_destination_rate_delay=2s

That will tell the queue manager to insert the specified delay between each individual delivery to the same destination. Since you haven't modified default_destination_recipient_limit from its default, it should apply the delay to each recipient domain. So this should mandate a 2 second delay between each delivery to the domain listed in the transport map.

When I've had to do this in the past, I didn't go with the alternate transport mechanism. Since I was only concerned with delivery speed to each unique domain, I just added these lines to main.cf:

smtp_destination_concurrency_limit = 1
smtp_destination_rate_delay = 1s

So if there is mail being injected for 30 different domains, it may try to deliver a message to all 30 of them at once, but never more than one at a time to example.com and never faster than 1 per second to example.com.

Incoming rate limiting

Unless I am misunderstanding your goals, you cannot really restrict the rate at which packets come in to your network from your ISP unless you coordinate some form of QoS with your ISP to shape traffic at their routers. This typically requires a business-class connection and money. You are seeing packet drops because that is the only way to shape traffic - you drop it on the floor. So your TC rule is working as designed, but you cannot control what level of traffic gets sent to your WAN interface, as senders try to send it as fast as possible.

Now, you can sort of shape incoming TCP traffic by strategically dropping packets or messing with ACK packets to make senders think your network is more congested that it actually is. But that doesn't really help things for non-TCP traffic coming into your network.