Null blocking SERVFAIL

[Gertjan]

@tibere86 said in Null blocking SERVFAIL:

but IPv6 sourced requests are sent to the DNSBL webserver which then returns SERVFAIL

If a LAN device, a browser wants to visit www.google.com, it will do a DNS lookup first.
Let's imagine IPv6 and IPv4 is avaible for IP traffic : your pfSense, and your ISP, is full dual stack = can route IPv4 and IPv6.
Your browser, probably the DNS forwarder in your device, will send the request to the default DNS.
This can be over IPv4 or IPv6.
It will ask for an A and an AAAA record if IPv6 is available. It's normal to see your device asking for an AAAA record even when there is no IPv6 gateway (so the AAAA answer can't be used - don't ask me why ^^)

If "www.google.com" was listed in a DNSBL 'v4', then 10.10.10.1 or 0.0.0.0 will be return by pfBlockerng.
If "www.google.com" was listed in a DNSBL 'v6', then ::10.10.10.1 or :: will be return by pfBlockerng.
In both cases, it will be this local IP (10.10.10.1 or 0.0.0.0 or the IPv6 counterpart), or the resolved A = IPv4 or AAA = IPv6 - but not SERVFAIL, as this means there was an error somewhere, like the resolver (unbound) couldn't resolve the DNS request.
reasons could be : Uplink (WAN) down or unbound wasn't running ...

@tibere86 said in Null blocking SERVFAIL:

DNSBL webserver

If you fully understood what https is, you wouldn't use the "DNSBL webserver" or 10.10.10.1
This DNSBL webserver was nice to have when everything was http (http can redirected).
https can not be redirect.

So : use :

login-to-view

and call it a day.

If this (example) would show up :
login-to-view

the browser was authorized to show insecure pages.
That is, TLS was till used, but the browser was asking for this cert :

login-to-view

or it got back :

login-to-view

Normally, a browser shouldn't show anything - or just this :

login-to-view

as everybody knows an important security issue happened. They will bail out. They will be safe.

if a web page was showing up, like this one :

login-to-view

then their browser was accepting https redirection.
That's a major security risk (for this user, his device, your network ...).

[tibere86]

@Gertjan Thanks for the reply and information. Can you confirm that even with NULL BLOCK enabled, DNSBL v6 returns :: for sites on block list?
This is not what's occuring for me. When I have NULL BLOCK enabled, DNSBL v6 returns SERVFAIL instead of ::

[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

login-to-view
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

login-to-view

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

1. Null blocking without logging
2. Null blocking with logging
3. 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 :

login-to-view

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 :

login-to-view

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

login-to-view

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.