[ratelimits] ratelimiting /24 for <tld>

[Tony Finch]

Vernon Schryver <vjs at rhyolite.com> wrote:
> > From: Tony Finch <dot at dotat.at>
>
> > Weirdly, if I hammer on a nonexistent name, I get rate-limited based
> > on the enclosing NSEC record, but if I do a random name attack on an
> > authoritative zone I get limited based on the zone apex. Is the rrl
> > code being called more than once per query?
>
> I think I don't understand first part of that question.

I have done some more investigation. It turns out that my random name
attack was generating too many names with digits at the start, and these
were being counted against the zone apex and there were enough of them to
be limited. However the alphabetic queries were not limited. If I simulate
a random name attack as below, the rate limiter is NOT triggered as it
should be. This is because each query is being counted against the
covering NSEC and there are enough different names that they almost never
collide.

$ while sleep 0.2;
  do dig +short +dnssec $(
	dd if=/dev/random bs=9 count=1 2>/dev/null |
	b64encode spong | sed '2!d'
     ).cam.ac.uk;
  done

> > Here's an example of a real false positive from earlier in the day. There
> > were 40 queries in the two seconds before the rate limiter kicked in, but
> > they were for different names.
> > ...
>
> What is the false positive in those lines?

The false positive is that the rate limiter was triggered even though all
the queries were different.

> Are the requests for verisign, twitter, and other names other than
> feedburner and google relevant?  I don't see any requests for feedburner.
> I do see several different google.com names.

That is a complete trace of all the recursive queries to my nameserver in
those few minutes. (The google.com + feeds.feedburner.com test was later
in the day and is not relevant to this trace.) All the queries are
relevant because together they trigger the rate limiter when they should
not.

> I see only one rate limiting line but it is for ocsp.thawte.com at 13:39:01
> That it is a lot more than 10 seconds after first line at 13:37:24
> and that there no preceding requests for thawte.com bothers me.

Right. It bothers me too.

I added some extra logging to query.c and client.c just before the call to
dns_rrl() to see the value of fname that was being passed in. This showed
that it was usually being called twice per recursive query - see the log
extract below. The two fnames are usually the TLD and the qname (in that
order), except when the response is not already cached.

This would explain why my recursive queries are triggering the rate
limiter for TLDs even when I am not querying for TLDs.

dns_rrl() is only being called once for authoritative responses.

08-Jul-2012 17:07:50.494 queries: info: client 127.0.0.1#33576 (api.twitter.com): query: api.twitter.com IN A + (127.0.0.1)
08-Jul-2012 17:07:50.494 rate-limit: debug 1: client 127.0.0.1#33576 (api.twitter.com): checking rate limit for com
08-Jul-2012 17:07:50.494 rate-limit: debug 1: client 127.0.0.1#33576 (api.twitter.com): checking rate limit for api.twitter.com
08-Jul-2012 17:07:50.494 queries: info: client 127.0.0.1#39955 (api.twitter.com): query: api.twitter.com IN AAAA + (127.0.0.1)
08-Jul-2012 17:07:50.494 rate-limit: debug 1: client 127.0.0.1#39955 (api.twitter.com): checking rate limit for com
08-Jul-2012 17:07:50.494 rate-limit: debug 1: client 127.0.0.1#39955 (api.twitter.com): checking rate limit for api.twitter.com

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Fisher, German Bight, Humber: Cyclonic 3 or 4, increasing 5 to 7, perhaps gale
8 for a time later in German Bight and Humber. Slight, becoming moderate or
rough. Thundery rain or showers. Moderate or good, occasionally poor until
later.