[Bind10-uides] thoughts on a debugging/logging system for BIND 10

[Jerry Scharf]

Hello,

First, I have not fallen off the face of the earth. I have been dealing 
with family problems, but they are improving now.

I am writing up a first pass of the requirements doc for the command 
tool (should be ready to ridicule this week.) One of the things that is 
up is how to debug servers, especially ones with things like views. I 
was thinking of a command tool command called digcc that can send 
queries over the command channel, set query parameters and collect extra 
data from the server as well.

At the same time, there was a discussion by the developers of logging 
for tracing various activities like how a packet creates upstream 
packets, selects which nameserver to conenct to, etc. There was also a 
discussion of a tag for a query so that all the secondary data could be 
collected back to the primary query.  These ideas collided in my brain, 
and I wanted to bounce the idea I came up with off you all.

It all starts with the logging system. I am proposing that there be 
named "logging instances." I am not sure logging instances is the best 
name, but the idea is that is describes all the logging things that wold 
happen if it were to be the default logging for the server. The 
operators create the logging instances like "trackupstream" or 
"datasource" with all the desired logging configuration. This has the 
nice advantage of being able to load a new logging instance on the 
server, test and make it default. The rollback is also easy, switch back 
to the prior logging instance as default.

The next step is to introduce ID tagging to queries. Any query that has 
an ID is processed with extra data collection and which its linked 
logging instance. If any child queries are created, they also get the 
same ID tag so that all the information comes together.

The final step comes with the command channel query mechanism. It has 
the ability to set things a typical query could not (source address, 
etc.) The output part of the logging would be overridden and all the 
logging would be captured to a buffer and returned to the command tool 
after the answer. The digcc command looks a good deal like regular dig, 
but has extra arguments that can control all the extra things that can 
be done over the command channel.

I think this does what people need to do for debugging most DNS 
problems. It allows detailed queries to be processed on an active server 
without needing to impact any of the other traffic. It allows someone to 
tell an administrator 'run these commands and send me the output." With 
some tricks, it allows people to choose between fastest query processing 
and limited logging and logging with all the bells and whistles and some 
drop in performance.

First, does this sound like the right way to go about this? Second, what 
specific things jump out as important features or that need to be 
addressed if we take this approach?

thanks,
jerry