Null blocking SERVFAIL

Gertjan

@tibere86 said in Null blocking SERVFAIL:

When I have NULL BLOCK enabled, DNSBL v6 returns SERVFAIL instead of ::

Hummmm.

I just tested with "006.freecounters.co.uk" which is part of DNSBL_ADs_Basic.

When I test with

I saw also a "ServFail".

Then I started to "play" with the python script ... and now I see :
(adding logs lines on what I think are interesting places ), like on line 1614:

                    log_info("{} Blocked {} Returned IP {} {}".format(q_name, b_ip, q_type_str, q_type))

I saw :

<30>1 2025-01-29T17:56:09.484605+01:00 pfSense.hf.tld unbound 13346 - - [13346:0] info: 006.freecounters.co.uk Blocked :: AAAA 28

... But then humm again.
If unbound return "::" then what can the browser do with this ?
It should be the, to be useful, an IPv6 GUA of pfSense .....
And &@/{#, as I'm in null blocking mode ...
Done. back to Web server mode.

Now I see :

info: 006.freecounters.co.uk Blocked ::10.10.10.1 Returned IP AAAA 28

But https://[::10.10.10.1]:443 doesn't really work.

Also : https://serverfault.com/questions/698369/what-is-the-ipv6-equivalent-of-0-0-0-0-0

fenichelar

Okay, so I have made some progress diagnosing the bug. The issue is occurring here:

msg = DNSMessage(qstate.qinfo.qname_str, q_type, RR_CLASS_IN, PKT_QR | PKT_RA)
msg.answer.append("{}. 60 IN {} {}" .format(q_name, q_type_str, b_ip))

msg.set_return_msg(qstate)
if msg is None or not msg.set_return_msg(qstate):
    qstate.ext_state[id] = MODULE_ERROR
    return True

https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-pfBlockerNG/files/usr/local/pkg/pfblockerng/pfb_unbound.py#L1617-L1623

Specifically, there is a mismatch between q_type_str and b_ip.

If the first DNS lookup is for type A, then b_ip will be 0.0.0.0. If an AAAA lookup then comes in, b_ip is still 0.0.0.0, which is wrong.

If the first DNS lookup is for type AAAA, then b_ip will be ::. If an A lookup then comes in, b_ip is still ::, which is wrong.

This is why the issue is inconsistent and restarting Unbound seems to resolve it.

More detail to come.

fenichelar

I haven't thoroughly tested yet, but here is my first pass at a fix:
https://github.com/pfsense/FreeBSD-ports/pull/1407/files.

Instead of saving the answer in the previously blocked domain details dictionary, a boolean for null blocking is saved. Then based on the query type, the appropriate answer is returned.
I also fixed an issue where SERVFAIL was being returned because the answer (an IP address) was not valid for the query type. An answer is now only included for A, AAAA, or ANY queries.
In addition, instead of ANY queries defaulting to A, they now default to both A and AAAA.
Lastly, I increased the TTL from 60 (1 minute) to 3600 (1 hour) to reduce DNS load.

Gertjan

@fenichelar

I copied pasted your diff, and will test it for a while.

@fenichelar said in Null blocking SERVFAIL:

Lastly, I increased the TTL from 60 (1 minute) to 3600 (1 hour) to reduce DNS load.

If I get it right, this is where the DNS reply "here is a 0.0.0.0 for you" created for the requesting device, if the host name was found in a blocking list (or regex, etc).
Instead of having the client device retry again one minute later as the TTL was low (60) - and if the client device respected the delay (now 3600), then yeah, way less DNS requesting should happen.
That is, if the client accepts 'NO' or 0.0.0.0 as an answer, and it respects the TTL delay.

fenichelar

@Gertjan Exactly, the intention is to increase the amount of time that the client caches the block response; either null blocking ("0.0.0.0" / "::") or webserver blocking.

Gertjan

@fenichelar

I've this - shows what my pfSense unbound is doing. Lets see what changes. I'm in now for 12 hours.

fenichelar

I have been running this since I submitted the PR. I am using null blocking with no logging. No issues. @Gertjan are you using null blocking? What about logging?

Gertjan

@fenichelar
Don't ask me
Ask my visual logs, look for yourself: day stats, weeks stats, month stats and year stats.

Since I applied the patch published above, for a week now, the servfail return code (purple ?) vanished, nearly not there anymore.

And of course I Null-log (default answer 0.0.0.0) everything, as the DNSBL-Webserver-log (default answer 10.10.10.1) is totally useless.
After all : who uses http these ? There are no public sites anymore that use http. Browsers don't want to use http anymore. http is by nature non secured. http is a thing of the past. And pfBlockerng can't redirect https to DNSBL-Webserver-log (the server page) as it can't, by law, redirect https.

fenichelar

@Gertjan So just to confirm, you have null blocking with logging?

There are 3 configurations:

Null blocking without logging
Null blocking with logging
Web server

I agreed, web server is not a good idea, but it is an option that should work. I have tested configuration #1. It sounds like you have tested #2 if I understood correctly. While I am fairly confident the patch will work for #3, I haven't actually tested it yet; so I will work on it over the next few days.

Gertjan

@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 :

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 :

@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 :

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.