[ratelimits] CH/TXT/id.server queries rate-limited

[Jay Daley]

On 27/10/2012, at 4:02 AM, Vernon Schryver <vjs at rhyolite.com> wrote:

> I was not thinking about increased false positives due only to a window
> 3600 times longer than the 1 second window in the BIND9 RRL patch.
> Instead I was thinking about popularly proposed schemes using bloom
> filters or hash tables without keys that take much less memory but
> that have significant false positive rates by sometimes putting two
> or more distinct responses in a single bucket.

OK, see below about memcached.

> On the contrary, that would increase the number of records by a factor
> of 5 (1 second vesus 5 seconds).  Unlike rate limiting IP packets
> and HTTP client IP addresses, at timescales shorter than DNS TTLs,
> DNS (IP,qname,qtype) streams are almost all single, unique respons/requests.
> They are not streams.  A DNS response rate limiter needs about as many
> buckets as window*qps.  In my code, practically all buckets are discarded
> or recycled after 1 second.  Your code would need to keep all buckets
> for 5 seconds before discard almost all of them with final counts of 1.

Ah, understood.

> Besides, you would get about the same effect on bad guys trying to
> skirting the limit by simply reducing the limit as in:
> 
>    rate-limit {
>        responses-per-second 5;
>        window 5;
>    };

No, that's very different, which is why I was suggesting two buckets.

> A third and even bigger issue is that you're not entirely solving
> a problem that does not yet exist and I doubt will ever exist.
> You're not entirely solving it because the bad guy need only add
> more open resolvers to get below your longer window limit.  I doubt
> the problem will ever exist because of various costs and benefits
> to bad guys of various other tactics.

Hold on.  I was not suggesting this would eliminate attacks, but that it would reduce the length of time any individual server could participate in an attack, therefore increasing the difficulty in maintaining a sustained attack.  I doubt anyone would ever claim to have a silver bullet for entirely solving this problem.

> I understand memcached to be a distributed cache for databases.
> https://code.google.com/p/memcached/wiki/NewOverview
> https://en.wikipedia.org/wiki/Memcached
> That's a good idea for distributing and speeding up databases, but it
> would be a disaster for DNS response rate limiting.  DNS RRL requires
> latencies of tiny numbers of microseconds, because the total work for
> a DNS transaction is a small number of microseconds.  Speeding up a
> distributed database with typical delays of hundreds to several thousand
> microseconds is an entire different problem.  No competitive authoritative
> DNS server implementation delays responses for disk accesses or network
> chitchat.

> That said, there is an aspect of DNS response rate limiting that
> could use some network chitchat for something of a distributed
> database.  Large authoritative DNS servers use lots of computers.
> It would be good if they could share blacklists.

when memcached is used over the wire it can deliver low hundred of microsecond latency:

https://www.facebook.com/note.php?note_id=39391378919

memcached when used on the same server it is even faster but I don't have the data any more.

cheers
Jay

> 
> 
> 
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> ratelimits mailing list
> ratelimits at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/ratelimits


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley