On Sun, Jun 08, 2014 at 09:45:23AM -0400, Timothe Litt wrote: > Consider a continuous stream of queries to a slow server. For the sake > of exposition, assume the incremental adjustment is 1 rather than 5. > > Named drops the 11th query, but increases the limit.
It only increases the limit if one of the pending queries for that name got an answer back. If the authoritative server's not responding at all, we just carry on dropping queries, but if *is* answering -- just not quickly enough to keep up with demand -- then we adjust our queue lengths. The code was written before my time, so I'm only guessing here, but I suspect the idea was to adapt to the situation where you have a fast local network and a slow upstream connection. If we're getting queries for popular names faster than we can resolve them, it may make sense to buffer more queries. > For the former, a global threshold makes some sense - an abusive burst > of queries can be for multiple zones - or focused on one. > But isn't this what response rate limiting is for? Given RRL, does this > still make sense? RRL is response rate limiting -- it applies to output not input. > For the latter, separating the measurement/threshold tuning from the > decision to drop would seem to produce more sensible behavior than > dropping every 5i-th packet. And for it to make any sense at all, it > must be adjusted per server, not globally... As it happens I'm in the middle of a research project on this very subject; future releases will probably have some additional per-server throttling and holddown controls and more finely adjustable drop policies. Stay tuned. > Or I'm missing something, in which case the documentation needs some > more/different words :-( If the above was helpful and you feel inspired to rephrase it into text for the ARM, I'm always happy to take your patches. :) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
