@fenichelar said in Null blocking SERVFAIL:
So just to confirm, you have null blocking with logging?
well .. you got me there.
I did use, since yesterday 11/02, switch my two DNSBL feeds to :
5c7ae6be-e1c5-45f8-af95-0b3a3aa2acb8-image.png
as I wanted to test with these settings for a while. And of course forgot about it already.
Btw : I didn't saw the pfBlockerng Blocked DNSBL page.
I nearly never visit web sites that are loaded with adds and stuff like that. So, pfBlockerng has nothing to do if it was just. I'm also sharing my connection with an entire hotel, loaded with clients (they are the real testers ^^) . Dono what they do, what they saw. If things went bad, they would have come to the reception to complain about the free service ^^
I know they do, as they also yell that there is nothing worth watching on the TV in their room (the 30 or so national channels - it's all publicity 24/24h and I don't block that (yet)).
I'm back at :
7dc95f9a-79d6-4a6c-9b62-7598cd9c01c9-image.png
@fenichelar said in Null blocking SERVFAIL:
but it is an option that should work
It does.
It woks well for we browser requests that are made with "http".
It can't - and you don't want to - work for https requests.
Added to what I've said above : let's do the test, and I propose this fact check method :
a new LAN pass rule :
85dd531f-1830-49ad-8e04-5049d72ca15d-image.png
Now I can see over time how often port 80 is used.
I'm curious ....
If most web server requests are https, which presume, then the "DNSBL-Webserver-log" can't work. It won't show up. At best, an browser error page shows up : as the "DNSBL-Webserver-log" certificate wasn't the one that the browser was waiting for.
Nothing is broken, imho, all is by design ^^ TLS (=https) behavior can't be patched easily.