Regarding DNS, the query string is encrypted on HTTPS. It can still be cached on logs on their side for example. It can be seen on the script, but the credentials would still have to be there somewhere.
I'm not quite sure what you mean by "Additionally out of the box fail2ban won't work with docker containers". fail2ban is installed locally on the pi.
If you had installed for example your web server on a container, the logs will be on the container. Fail2ban on the host won’t be able to parse the ones inside the container (by default, needs more work).
There's also a similar pam module called pam_tally2, which I haven't used.
In fact, here, it's automatically configured on each and every host at install-time (via the post-installation scripts in my kickstart files). I can't remember a time when I ever needed to "touch" it afterwards.
(A few years ago, I evaluated pam_tally2 vs. pam_faillock and settled on pam_faillock but, unfortunately, I can't recall what led me to that choice.)
---
[0]: In reality, though, it doesn't really do much. There's only two Internet-facing servers with 22/TCP open to the world -- the bastion hosts -- and only public-key authentication is permitted on those.
Who is "anyone" in this context? At most, it would only be anyone that has access to logs and the Pi itself. A man-in-the-middle wouldn't see them because it's HTTPS.
oh snap...because the logs are in the container. Hadn't thought of that. Good shout