[ratelimits] Remarks regarding the Knot DNS 1.2.0 RRL implementation

[Paul Vixie]

...

Marek Vavruša wrote:
> BIND RRL also aliases many tuples into one set of counters, it's just
> less probable.

the mapping of tuples to buckets is specified in the tech-note, and
BIND9 RRL adheres to that mapping.

> I don't feel like this is too much important, RRL is not a silver
> bullet and I take it as a very clever yet simple way to combat a
> problem nowadays, not as as thing that's meant to last. And if there's
> a possibility that two flows will share a same limit (unpredictably
> and time limited)? I would be okay with that, if it works reasonably
> well otherwise. But I also understand if anyone disagrees. 

i just want RRL to work the same on all the servers that folks might be
running, assuming a mix of BIND9 and non-BIND9. we can and should
propose, model, debate, implement, and test other ideas beyond that. but
not as the first order of business.

>> bands, classifiers, separate limits for large responses, are all ideas worth
>> considering... later, after we've got feature parity.
>>
>> paul
>
> This is just about "how to identify flows", but it sounds reasonable.
> Let's see what the deployers think first.

i think we're in disagreement. if someone using OSPF ECMP to
front-loadbalance a brace of DNS servers, one third of which run BIND9,
one third run Knot, and one third run NSD; if an attack comes which
registers as a certain response profile -- that is, what is omitted and
what is not omitted; if one of the servers is taken down for
maintainance and is thus removed from the ECMP set; then the response
profile should not change, even though there will be a new ECMP hash
directing 4-tuple flows toward the remaining ECMP brace members. that's
a nightmare for operators. we do not need to wait for them to experience
it and tell us that we should not have coded it that way.

if the tech-note is inadequate in its description of the mapping from
tuple to bucket, please propose more exact wording.

paul


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/ratelimits/attachments/20130305/2c3b530e/attachment.htm>