Bind Queries log file format

[Reindl Harald]

Am 06.02.2017 um 14:25 schrieb Warren Kumari:
> I suspect perhaps some of the thread got missed (or was unclear).
>
> The reason for adding it to the main log file *by default* is because
> of things like:
> Customer: "My BIND went Boom! It's been running fine for many years,
> and then for no reason at all it went Boom. Here are my log files..."
> ISC: "Doh. Sorry. Unfortunately the log file doesn't have sufficient
> debug info. Can you please turn on debug using <insert invocation>, so
> that we have enough logging info next time this happens?"
> Customer: "Bah. Ok. Will do...."
> <Customer enables debugging. named runs again for many years. Either
> named doesn't oops again, or, more likely, 3 years later customer
> wonders why extra logging is on, and turns it off - and then 2 weeks
> later named ooopes...>
>
> The additional logging info is specifically for the unusual bugs,
> which happen very rarely - asking customers to enable the additional
> logs after a rare event (which might not happen again for months /
> years) means that ISC cannot hunt down and squash the corner case
> bugs...

that was all clear - but it don't justify include debug informations in 
the standard query log - in doubt write that informations to a 
*specific* logfile by default and give the knowledgebale admin a config 
option to disable that debugging logic at all

i have a similar issue currently with logwatch and a by upstream changed 
log format of python spf-policyd leading in logwatch spit auch megabyte 
large mails every night with "unmatched entries" and at the same time 
really useful self written scripts seeking possible whitelist_auth 
candidates for spamassassin got broken

touching logformats has unknown consequenses all over the world even at 
places nobody would imagine until something got broken