<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">...<br>
<br>
Marek VavruĊĦa wrote:
<blockquote
cite="mid:CACgotOSE1xaSKm8kT2ZxeGxkoiZP0XwQ+_RbGjv86qSdc5rA8w@mail.gmail.com"
type="cite">BIND RRL also aliases many tuples into one set of
counters, it's just less
probable.</blockquote>
<br>
the mapping of tuples to buckets is specified in the tech-note, and
BIND9 RRL adheres to that mapping.<br>
<br>
<blockquote
cite="mid:CACgotOSE1xaSKm8kT2ZxeGxkoiZP0XwQ+_RbGjv86qSdc5rA8w@mail.gmail.com"
type="cite"> 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.
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CACgotOSE1xaSKm8kT2ZxeGxkoiZP0XwQ+_RbGjv86qSdc5rA8w@mail.gmail.com"
type="cite">
<blockquote type="cite"><pre wrap="">bands, classifiers, separate limits for large responses, are all ideas worth
considering... later, after we've got feature parity.
paul
</pre></blockquote>
<pre wrap=""><!---->
This is just about "how to identify flows", but it sounds reasonable.
Let's see what the deployers think first.</pre>
</blockquote>
<br>
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.<br>
<br>
if the tech-note is inadequate in its description of the mapping from
tuple to bucket, please propose more exact wording.<br>
<br>
paul<br>
<br>
<br>
<blockquote
cite="mid:CACgotOSE1xaSKm8kT2ZxeGxkoiZP0XwQ+_RbGjv86qSdc5rA8w@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
</blockquote>
</body></html>