[ratelimits] what does "same response" really mean?

Vernon Schryver vjs at rhyolite.com
Wed Jan 23 19:16:11 UTC 2013

> Does the ratelimit patch consider everything in, for example, "hp.com
> <http://hp.com>" to be the same response?  I set up a test server with
> the ratelimit patch and pointed my pc at it.  Even as a single user, I
> get throttled sometimes, loading a single web page (hp.com
> <http://hp.com> for example).
> ...

> cm.g.doubleclick.net <http://cm.g.doubleclick.net> IN A + (

> 23-Jan-2013 08:48:17.618 queries: info: client query:
> welcome.hp.com <http://welcome.hp.com> IN A +T (
> I did DNS lookups on each of these and only a few resolve to the same IP
> addresses.  For instance the last one, welcome.hp.com
> <http://welcome.hp.com>, has a different response than all but one of
> the others, so how could it be rate limited?

I didn't see that message from the mailing list reflector until private
mail called my attention to it.  My spam, mail tracker/privacy violation,
and malware defenses objected to that cm.g.doubleclick.net HTML link.
The message seems to have been sent using a mail user agent (MUA) that
is too smart by half and converts anything that looks like a host name
to a hyperlink as it makes its entirely unnecessary and wasteful MIME
HTML alternative for the message.

I never liked them, but I didn't know that those automatic MIME
alternatives are big security problem.  If you mention an evil host
name in plan text, that MUA will convert your message into a
spearphishing attack.

About the question,
the log entries (more easily read without the MUA's "improvements" in
http://lists.redbarn.org/pipermail/ratelimits/2013-January/000218.html )
are a combination of queries received and rate limiting action reports.

The last line
 23-Jan-2013 08:48:17.618 queries: info: client query: welcome.hp.com IN A +T (
reports only that bind received a request for welcome.hp.com.  None
of the log entries say the responses for any of the 3 requests for
welcome.hp.com were dropped or truncated.  There are reports of 3
dropped responses and 3 truncated ("slip"), but all for hp.com.

That 6 responses for hp.com were dropped or truncated demonstrates the
fatal problem in using RRL on recursive servers instead of only on
authoritative servers.  Many applications such browsers and SMTP servers
repeat DNS requests many times.

You might use RRL on such a recursive resolver, but only with far
higher rate limits than are required to mitigate DNS reflection DoS
attacks.   A rate limit of 5/second on an authoritative server is
generous, but 10X too low for a recursive server for 2 or 3 users
and more than 100X low for a recursive server for a non-trivial
number of end users.  A rate limit of 500/second does not mitigate
reflection attacks.

It is far better to use ACLs, firewalls, or otherwise close open
recursive servers and limit their use to local, logged, trusted users.

Last year I hoped that RRL might someday work on recursive servers.
Consideration of distributed reflection attacks and reflection attacks
on networks that don't have dozens of Gbits/sec of spare bandwidth
show I'm wrong.  Single digit RRL limits are necessary for those DoS
attacks and cause no problems except perhaps on extremely busy
authoritative servers like gTLD roots.  Single digit RRL limits are
far small for even for trivial recursive servers.

Vernon Schryver    vjs at rhyolite.com

More information about the ratelimits mailing list