How can I retrieve the details that makes up the statistics?

[Chris Buxton]

On Nov 9, 2008, at 6:05 PM, JINMEI Tatuya / 神明達哉 wrote:

> At Sat, 8 Nov 2008 17:58:55 -0800,
> Steve Koon <skoon at escapia.com> wrote:
>
>> Is there a way to retrieve (or log during request) the actual queries
>> that made up the count for the NXRRSET and NXDOMAIN statistics? I am
>> curious what record types and queries that could not be served by  
>> this
>> domain.
>
> The short answer is no.
>
> If you want to know specific queries rather than or in addition to RR
> types that cause nxrrset/nxdomain, I believe you need additional
> logging; summarized statistics counters are not suitable for that
> purpose.
>
> I've actually been thinking about adding a new logging category to log
> each response, and have been wondering whether there's need for this
> feature.  Would that make you happy?

A logging category that logged not just incoming queries, but also  
outgoing queries, and also the responses sent/received to these  
queries, would be really handy. It doesn't need to log the whole  
packet (except at some debug level), but just something along the  
lines of the current logging category. For responses, also log the  
type of response: positive answer, nxrrset (or whatever you want to  
call this), nxdomain, referral, or error (with type).

This category could either log all of this at info level, or else log  
incoming queries at level notice and all other traffic at level  
notice. Or even log incoming queries at level info and all other  
traffic at debug level 1 (to retain current behavior for non-debug  
levels), and then start logging full packet contents (i.e. what we see  
in default dig output) at higher debug levels.

I see this as a replacement for the current queries logging category,  
not an addition to it.

While we're on the topic of logging, if somebody could write up a set  
of documentation of all of the current (at least non-debug) log  
messages and add it to the ARM, that would be great. I would rather  
not dig through source code looking for explanations when the log  
message itself is not perfectly clear.

Chris Buxton
Professional Services
Men & Mice