<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><pre class="gmail-m_-5383274120411220125m_4207465000984740680bz_comment_text" id="gmail-m_-5383274120411220125m_4207465000984740680comment_text_0" style="font-size:medium;font-family:monospace;white-space:pre-wrap;width:50em;color:rgb(0,0,0);font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration:none">1) Mimic what's common in the "networking world", allowing to configure a (higher) burst limit, could be a way of allowing bursty clients to finish all lookups without getting slowed down by dropped queries. 
</pre></div></blockquote><div>I like this idea:)</div><div>I observe lot of clients, that send a lot of queries in first second of data transmission.</div><div>Perfect solution (for me;) would be : If IP send more than X queries in Y seconds, deny all queries from this IP for Z seconds </div><div> <br></div><div>example of my usecase:</div><div><div>second 1: Regular Client: 80qps</div><div>second 2: Regular Client: 10qps</div><div>second 3: Regular Client: 5qps</div><div>second 4: Regular Client: 4qps</div><div>second 5: Regular Client: 3qps</div><div><br></div><div>second 1: Malicious Client: 50qps</div><div>second 2: Malicious Client: 50qps</div><div>second 3: Malicious Client: 50qps</div><div>second 4: Malicious Client: 50qps</div><div>second 5: Malicious Client: 50qps</div><div><br></div></div><div>ip-ratelimit 40 might be perfect for malicious client, but it impacts regular client experience. </div><div><br></div><div>Even measuring number of queries for two seconds ( instead of 1 ) would make huge improvement.</div><div><br></div><div><br></div><div>BR</div><div>M</div><div><br></div><div><br></div></div></div>
</div></div>