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

Bob Harold rharolde at umich.edu
Thu Jan 24 15:12:07 UTC 2013

My apologies for the html mail.   The U of Michigan is using Google
mail (gmail).  I will try the "plain text" option for this email.

I checked a packet trace, and I only see one query for just "hp.com".
Also note that the source port number changes each time, except that
the "drop" and "slip" entries show the same port # as the previous
line, because it is the same query that was logged with query logging.
 (So packets that are dropped or slipped get two lines in the
named-query log file.)  Why does the "drop" or "slip" say only
"hp.com", when the query was for "welcome.hp.com" ?

Bob Harold
University of Michigan

> Date: Wed, 23 Jan 2013 19:16:11 GMT
> From: Vernon Schryver <vjs at rhyolite.com>
> To: ratelimits at lists.redbarn.org
> Subject: Re: [ratelimits] what does "same response" really mean?
> Message-ID: <201301231916.r0NJGBtn072739 at calcite.rhyolite.com>
> > 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