[bind10-dev] Tracking queries and other data

[Stephen Morris]

On 2 Dec 2010, at 16:07, Shane Kerr wrote:

> 
> In the context of logging, if you want to make sense out of what is
> going on I think you need to have some unique identifier that you can
> include in each log message that reflects the various events that the
> log message may apply to. Please ignore the specific syntax, but
> something like this:
> 
>        client query WWW.ISC.ORG AAAA                <- query arrives
>          new query tag: q20101202T163557.034731-00
>        WWW.ISC.ORG AAAA not in cache 
>          query tag: q20101202T163557.034731-00
>        ISC.ORG NS not in NSAS 
>          :
>          :

My thoughts are to make the query tracing selective: instead of logging all queries or none, we tag queries we are interested in with an ID and log only queries (and related events like upstream fetches) whose ID is non-zero.  These could be enabled in a live server by appropriate commands, e.g.

trace -t A www.isc.org
Trace all queries for the A record of www.isc.org.  Each incoming A query for www.isc.org. is given a unique ID and events related to it are logged.

trace -l
List all enabled traces.

trace -d -t a www.isc.org
Disable the trace for the A queries for www.isc.org.

trace -m -t mx isc.org
"-m" indicates a partial match. Enable tracing for all MX queries to domains ending in "isc.org.".  (To enable tracing for all queries, specify a partial match of "." - all fully-qualified domain names end in ".")

trace -m -t any -c 1 isc.org.
A "one-shot" trace.  Enable tracing only for the first query (-c 1) for a name in the isc.org. domain after the tracing was enabled.  (The idea here is that if you are getting a large number of queries for a domain you are probably only interested in analyzing one in detail; enabling the trace for all queries may well generate vast amounts of data you are not interested in as well as slowing down the server.) Obviously, different count values can be specified so (for example) you could enable logging for ten consecutive queries. 

trace -f -t any ns1.isc.org
When a fetch (upstream query) is made to ns1.isc.org, enable tracing on that query that caused it (if not already enabled).  Providing that the logging also includes a message as to where the ultimate response is sent, then we know what query caused the fetch, although we won't know what query processing took place up to the point the fetch was made.

As to implementation, the "trace" command would add to a list of watched domains checked by the recursor when the query object is created.  If a match is found, the query object is given a non-zero ID.


Stephen