[bind10-dev] Logging of Individual Packets

[Jerry Scharf]

Stephen,

For those new to the discussion, the idea of this is allow detailed 
logging on a limited set of incoming requests. On high traffic servers, 
turning up the logging on all packets to track a problem can be problematic.

In my thinking about debugging issues, I was imagining it would be more 
based on the query source (e.g. source IP address, command channel 
query) or the type of operation (e.g. dynamic DNS update) than the 
qname. I think you were using the qname as an example, but I just wanted 
to fill in the discussion.

Some particular cases that I was thinking of were:
    show view and answer selection for queries from an address range
    bump the logging for dynamic DNS updates within a given section of 
the namespace
    have a command channel query gather extreme detail about how the 
query is processed
    see how the upstream server selection works for a series of queries 
in the same zone
    watch the entire stream of fills for DNSSEC validation of a query

In my thinking, the logging context was a persistent thing that could be 
used for various filters. There is nothing that says it should work that 
way, just my thought. I was imagining that support customers would have 
a few logging contexts that the ISC support team worked out, and then 
the support team could just say "Add this filter and use d99 logging... 
Now  remove the filter and send us the log."

warmly,
jerry

On 01/31/2011 10:11 AM, Stephen Morris wrote:
> On 28/01/2011 15:56, Jerry Scharf wrote:
>
>> As I have been working on the MRD , the issue of debugging and logging
>> is back in the forefront. As part of this, it really seems like there
>> wants to be the ability to have different packets be processed with
>> different amounts of logging. One case for this is for the digcc command
>> to be able to collect much more detail that the standard traffic. A
>> second case is where a problem is being seen on a busy server and you
>> want more logging for some packets but not others.
>>
>> There are two aspects to this from my perspective, that there needs to
>> be the ability for the server have different logging "contexts" and that
>> the server needs to be able to decide which context to use for a given
>> query.
> The logging code does have the idea of multiple contexts, so in practice
> this should be _relatively_ easy.  If the query (presumably based on the
> name being queried for) is identified as one that should be tracked, a
> logger is created with a name based on the domain name and a pointer to
> it held in the query context object  The code then logs trace-related
> events to that logger.
>
> For example, if we identify that queries to www.example.com should be
> tracked, we create a logger called (e.g. "trace.com.example.www") and
> add a pointer to it in the query structure.  By making the logger a
> sub-logger of some known component (in this case, "trace") we can set
> default options for the logging of query tracing.
>
> Perhaps the most complicated part of it is identifying the queries you
> want to log and setting up per-query configuration options.
>
> Stephen