[ratelimits] rate limit vs querylog

[Richard Doty]

On 9/28/12 8:29 AM, Vernon Schryver wrote:
>> From: Mathieu Arnold <mat at mat.cc>
>> I run both BIND 9.8.3-vjs197.16-P2 and BIND 9.9.1-vjs197.15-P2 so, they're
>> the right version of the patch, I think, they still are way too noisy by
>> default.
> "continue rate limit" messages to the rate-limit category are
> supposed to be triggered by 60 second timers in each rate limit bucket.
> If you set a the print-severity level of a channel that gets
> rate-limit category messages to various debugging levels,
> you can see more than message per response.
>
> The current version of the patch generates INFO level queries category
> messages for every drop or slip.
> Unless I'm confused every query generates at least one INFO level
> queries category message for every query.
>
>
> } From: Tony Finch <dot at dotat.at>
>
> } The RRL patch uses LOGCATEGORY_QUERIES in a couple of places, in
> } client.c:ns_cient_error() and query.c:query_find(), and it does
> } not check server->log_queries before making these logging calls.
> } I think this is what Richard was complaining about.
>
> Oh, thanks!
>
> My thinking was that those two places should be like QUERY_ERROR(),
> query_error(), and log_queryerror().  For example, server->log_queries
> or `rndc querylog` does not affect log messages for REFUSED responses.
> However, I didn't pay attention to the loglevel=ISC_LOG_DEBUG(3)
> statement in query_error().
>
> So should the per-response queries category rate limiting messages
> be at ISC_LOG_DEBUG(3) and not affected by `rndc querylog`
> or should they like the default per-query logging and at INFO severity
> and controlled by `rndc querylog`?

My preference would be for per-response messages to track query logging, 
so I can turn them on and off with 'rndc querylog'.  There is a symmetry 
there, both logically (because each message goes with a query), and in 
terms of data volume (because query logging is the place where we 
sometimes have to choose not to record everything).

A second benefit to that approach is that it is much easier to access 
the data.  I can't afford to log this much data all the time; having to 
fiddle the debug level and reconfig each time... I'll be more likely to 
just leave it off.

Btw I didn't say so before, but I REALLY appreciate this work.  It's 
doing great things for me.

Richard.