From scharf at isc.org Sun Dec 5 23:04:34 2010 From: scharf at isc.org (Jerry Scharf) Date: Sun, 05 Dec 2010 15:04:34 -0800 Subject: [Bind10-uides] thoughts on a debugging/logging system for BIND 10 Message-ID: <4CFC1A82.1080507@isc.org> 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 From scharf at isc.org Wed Dec 8 01:14:31 2010 From: scharf at isc.org (Jerry Scharf) Date: Tue, 07 Dec 2010 17:14:31 -0800 Subject: [Bind10-uides] a significant partial pass on the product requirements document Message-ID: <4CFEDBF7.1020308@isc.org> Hi, My fingers need a break and there is enough here to start taking feedback. The doc is missing scripting, help and two appendices. The rest is a solid first pass. As I was looking at the commands in the appendix, there was some inconsistency in the style in different areas, so that is one thing to clean up. I welcome all input on content, design, omissions, layout and anything else that strikes you. thanks for looking at this, jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: BIND 10 CT PRD v0.1.doc Type: application/msword Size: 183296 bytes Desc: not available URL: