[dns-operations] correction about RRL leakage

[Vernon Schryver]

On Monday I wrote:

> I think the complaint is that DNS RRL with "slip 0" and the recommended
> "responses-per-second 10" could send 10 DNS response/second to the
> victim.  

That is not right because it is an unlikely worst case.  It is true
that a reflection DoS attack of "responses-per-second" identical queries
per second for a long time would not be filtered by DNS RRL.  However,
as this section from the documentation tries to say, excess responses
during one second suppress responses for subsequent "window" seconds:

]    Rate limiting uses a "credit" or "token bucket" scheme. Each
]    identical response has a conceptual account that is given
]    responses-per-second, errors-per-second, and nxdomains-per-second
]    credits every second. A DNS request triggering some desired
]    response debits the account by one. Responses are not sent
]    while the account is negative. The account cannot become more
]    positive than the per-second limit or more negative than window
]    times the per-second limit. A DNS client that sends requests
]    that are not answered can penalized for up to window seconds
]    (default 15).

For example, given "slip 0; responses-per-second 10;" and an attack
of at least 20 forged requests/second, DNS RRL will allow a total 10
responses for the entire duration of the attack.  Those 10 responses
will be for the first 10 requests.  The later requests will not be
answered.

Of course, an attacker could send 10 or fewer requests/second and have
all of them answered.  That kind of attack is hard to handle because
it can be undetectable by the reflecting DNS server.  For an extreme
example, an attacker with a list of 1,000,000 open resolvers could
send each open resolver one forged request every 10 seconds for
<random>.isc.org and send the victim about 0.5 Gbit/sec.  None of the
reflectors is likely to see anything odd about one stray NXDOMAIN every
10 seconds.


Vernon Schryver    vjs at rhyolite.com