search

NLnetLabs / unbound

Unbound is a validating, recursive, and caching DNS resolver.
https://nlnetlabs.nl/unbound
BSD 3-Clause "New" or "Revised" License
3.11k stars 357 forks source link

option for safe logging #36

Open appliedprivacy opened 5 years ago

appliedprivacy commented 5 years ago

We run public DNS resolvers that aim to protect the user's privacy by offering transport layer encryption and not having any query name logging, but when using unbound we are faced with logs that contain more data than we want according to our privacy policy even though we are running with verbosity: 0

unbound: info: validator: error. failed to classify response message:  ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0#012;; flags: qr ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 #012;; QUESTION SECTION:#-scrubbed-#011IN#011NS#012#012;; ANSWER SECTION:#-scrubbed-#0113548#011IN#011A#-scrubbed-#012#012;; AUTHORITY SECTION:#012#012;; ADDITIONAL SECTION:#012;; MSG SIZE  rcvd: 80

and we currently do not see any way to avoid this via an unbound configuration option.

We would suggest to add an option that allows privacy focused DNS resolver operators to use unbound without having that kind of data in their logs.

It could be something like:

safelogging: 1

which would result in safer logs where sensitive data like:

wcawijngaards commented 5 years ago

I believe that error is fixed by the commit https://github.com/NLnetLabs/unbound/commit/edf1ad369aea0134fe7856ad3bc4bcf48d814fc3 . It should then not happen anymore. This particular log message should then not happen, exept other bugs. Are there other log messages that need to be redacted, or do you think that, even though the bug is resolved, it is important to also remove potential internal-bug message contents for privacy reasons?

appliedprivacy commented 5 years ago

This particular log message should then not happen, exept other bugs. Are there other log messages that need to be redacted, or do you think that, even though the bug is resolved, it is important to also remove potential internal-bug message contents for privacy reasons?

Thanks for fixing the specific bug causing the log entries.

More generally speaking, we believe it should be up to the operators to decide whether they want to have any sensitive data in their logs at all, so it would still be great to either have something like a safelogging option or just safe logs by default in verbosity: 0 mode.

Thank you!