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
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
