[ratelimits] Remarks regarding the Knot DNS 1.2.0 RRL implementation

Marek Vavruša marek.vavrusa at nic.cz
Tue Mar 5 19:02:25 UTC 2013


On 5 March 2013 19:42, Paul Vixie <paul at redbarn.org> wrote:
> ...
>
>
> 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.

Not exactly. As BIND9 RRL stores just qname hash (which is completely
reasonable with me),
it is possible to end up in the same bucket with a client asking for a
different names.
So should we store complete qnames in the tuples or should we accept
false positives?

> 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.

Ok, fair enough.

> 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.

Can't tell. To be honest, I don't have much experience as an operator.
Could we have more people to chime in?

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

So, should we store complete qnames in the tuples or should we accept
false positives?

>
> paul
>
>


More information about the ratelimits mailing list