[bind10-dev] rrl patch for BIND 10

[JINMEI Tatuya / 神明達哉]

I've been experimentally porting BIND 9's RRL (response rate limit)
implementation to BIND 10.  While it's still missing some features of
the original version, it's mostly completed.  As I was asked
explicitly, I've pushed its current snapshot to the public repository
at the "rrl" branch.

In case someone is interested in playing with it, here is a quick
start guide:

First, build the branch and run BIND 10 of that branch, enabling
the Auth module.  By default RRL is disabled.  To enable it, configure
the module using bindctl as follows:

> config set Auth/rate-limit/enable true
> config set Auth/rate-limit/responses-per-second 5
> config set Auth/rate-limit/errors-per-second 5
> config set Auth/rate-limit/nxdomains-per-second 5
> config commit

Another feature of this branch that may be interesting is an
enhancement of the stand-alone benchmark tool for the Auth module that
supports RRL.  It can measure the query handling overhead of the
module excluding network I/O, so it's not affected by queries that
would be dropped due to RRL (which makes it difficult to measure RRL
overhead with usual benchmark tools such as queryperf).  This tool is
located in the src/bin/auth/benchmarks directory of the source tree
(always built, but not installed).

This is an example run of the tool without RRL:
% ./query_bench -n 10 -t memory -o . root.zone root-input.txt 
Parameters:
  Iterations: 10
  Data Source: type=memory, file=root.zone
  Origin: .
  Query data: file=root-input.txt (9995 queries)

Benchmark with In Memory Data Source
Processed 99950 queries in 3.830294s (26094.60qps)

root.zone is a copy of a real root zone file.
root-input.txt is a queryperf-style data file, each line consisting
of "qname qtype".

With the -r option, you can see the overhead of RRL:
% ./query_bench -r -n 10 -t memory -o . root.zone root-input.txt
[...]
Benchmark with In Memory Data Source
Processed 99950 queries in 1.305837s (76540.95qps)
Slip: 49719, Drop: 49627

In this case many queries are dropped, so the resulting qps is
actually much higher (and realistic).

A more interesting result would be that with the -s option, which
uses the specified number of different source IP addresses so it'll be
less likely to hit RRL (and closer to normal operational environment):

./query_bench -s 100000 -r -n 10 -t memory -o . root.zone root-input.txt
[...]
Benchmark with In Memory Data Source
Processed 99950 queries in 3.952757s (25286.15qps)
Slip: 0, Drop: 0

Comparing the 1st and 3rd results, you can see the net overhead of the
RRL processing (calculating the hash, looking up the RRL table, etc).
In this test scenario it's marginal (about 3% overhead, with actual
network I/O it would probably disappear in practice).

---
JINMEI, Tatuya