[ratelimits] Remarks regarding the Knot DNS 1.2.0 RRL implementation

[Marek Vavruša]

On 6 March 2013 05:36, Paul Vixie <paul at redbarn.org> wrote:
> can afilias and nominet please jump in here? we've already heard from icann.
>
>
> Marek Vavruša wrote:
>
>
> 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?
>
>
> yes, please. ops people, please indicate your desires here, even if it's
> just to +1 what jabley already said.
>
>
> 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?
>
>
> in bind9 there's a 32 bit hash of the qname in each chained bucket. that's a
> far larger collision domain than you'll see in an unchained hashing scheme.
> so my answer to your question is: "it depends on the size of the collision
> domain".
>
> paul

I agree, so should we update the memo to reflect that? This collision
rate is is more than acceptable,
I just pointed to the fact that the memo mandates perfect mapping and
then we get to a situation when
neither one implements it because it's not (from my point of view) required.
Personally, I would leave it open to implementation, but then we get
into the debate about if "far larger" is enough or how bad is "quite
small" or other uncertain terms.

Marek