Bug 4241 - offer a verbosity level that does not log qnames in any case when using logfile
offer a verbosity level that does not log qnames in any case when using logfile
Status: RESOLVED WONTFIX
Product: unbound
Classification: Unclassified
Component: server
1.9.1
Other Windows
: P5 enhancement
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-03-23 12:10 CET by nusenu
Modified: 2019-03-26 08:10 CET (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nusenu 2019-03-23 12:10:05 CET
Using "verbosity 0" with syslog does not cause any logs that
contain QNAMEs as far as I've seen.

After switching from syslog to logfile (without changing the verbosity)
sometimes logs get generated that contain QNAMEs.

https://nlnetlabs.nl/pipermail/unbound-users/2019-March/011442.html

Please offer a verbosity level that prevents the logging of QNAMEs in _any_ case
to avoid causing a privacy issue.
Comment 1 Wouter Wijngaards 2019-03-25 09:29:45 CET
Hi Nusenu,

It logs errors at that verbosity level, and that one is an error.  It is not supposed to happen.  And quite likely something to fix in the server itself, eg. that this error prints.

I would like to know the full error message, so that I can debug the problem.  But if privacy is a problem, I can wait for someone else to have the issue with non privacy sensitive data in it.

Mostly verbosity 0 should not be printing qnames, by the way, it is that you have apparantly some errors that it prints them.  With errors fixed it should not print any.  But then verbosity 0 prints mostly (or, only) errors.

The logfile or syslog does not actually change what unbound logs, sorry, I maybe now realize what your report is.  But the logfile versus syslog does not really change what unbound logs.  It only prints the same string to a different call.  The syslog sometimes shortens data (depending on syslog software used), or removes newlines and tabs.

Best regards, Wouter
Comment 2 Wouter Wijngaards 2019-03-25 09:34:16 CET
Hi Nusenu,

I think I can explain why you see additional log lines when you switch from syslog to logfile.  Unbound prints the same strings, but the 'info' or 'debug' or 'error' level of the string makes syslog treat the lines differently.  For example, I believe FreeBSD comes with syslog software that will move non-errors (eg. INFO or DEBUG flagged messages) to a different destination than the other messages.  After switching to a logfile, unbound prints all of them regardless of level.  You can also configure the syslog to not discard or move those messages elsewhere, I do not really know the config precisely; but some have features or messages per type, log level and source daemon.

Best regards, Wouter
Comment 3 nusenu 2019-03-25 18:19:40 CET
Hi Wouter,

(In reply to Wouter Wijngaards from comment #1)
> Mostly verbosity 0 should not be printing qnames

if you agree that unbound should not be printing qnames into logfiles
at verbosity 0 I'm wondering why this issue (which is about achieving just that)
gets closed as WONTFIX?
Comment 4 Wouter Wijngaards 2019-03-26 08:10:17 CET
Hi Nusenu,

Well... The printout of errors needs to keep working, so I do not want to remove (or 'fix') that.

For the specific error, once fixed, you should not get it any more.  Solves your issue for this case.  (and I certainly want to fix it).

The syslog and logtofile, call the same print to log function.  After that it is logging APIs.

The reply on the mailing list showed an response with A for AAAA, that should really have been stopped by the iterator; so maybe it happened in some other way, and I wonder if it could be NAT64 related (perhaps upstream versions of it? or local config and bug?).  This about the error message itself.

Best regards, Wouter