Null blocking SERVFAIL

fenichelar

I am seeing some strange behavior with null blocking. After first starting unbound, A queries for a blocked domain return "0.0.0.0" and AAAA queries for a blocked domain return "::". But after a short amount of time, the same A/AAAA queries sometimes start returning SERVFAIL. Restarting unbound temporarily resolves the issue. Is anyone else seeing this?

dig a www.googletagmanager.com

; <<>> DiG 9.20.2 <<>> a www.googletagmanager.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47765
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;www.googletagmanager.com.	IN	A

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Jan 25 11:42:22 EST 2025
;; MSG SIZE  rcvd: 53

After restarting unbound, it works again at least briefly:

dig a www.googletagmanager.com

; <<>> DiG 9.20.2 <<>> a www.googletagmanager.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21301
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;www.googletagmanager.com.	IN	A

;; ANSWER SECTION:
www.googletagmanager.com. 60	IN	A	0.0.0.0

;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Jan 25 11:44:49 EST 2025
;; MSG SIZE  rcvd: 69

Unbound is not forwarding. DNSSEC is enabled. Query name minimization is enabled. IPv6 DNSBL is enabled.

fenichelar

With increased log level and servfail logging, the unbound logs show the following:

debug: mesh_run: python module exit state is module_error
error: SERVFAIL <www.googletagmanager.com. A IN>: misc failure

Gertjan

@fenichelar said in Null blocking SERVFAIL:

Restarting unbound

You've set unbound logging to the max, so chances are your history is now gone.
But, when you run :

grep 'start' /var/log/resolver.log

what do you see ?
Does unbound restart often ?
While it restart, it can't handle 'DNS requests'. That would explain servfail.

fenichelar

@Gertjan No, unbound isn't restarting often. The issue is intermittently impacting only certain domains. Most domains resolve without issue.

Unbound is returning SERVFAIL because the python module is erroring, but it isn't clear why. I am going to try to add some logging to the pfblocker python script, specifically before each of the module_error exit points, to see if I can work backwards towards the cause of the issue.

Gertjan

@fenichelar

Plan B, for the moment : use Unbound mode ?!
What is your pfSense and pfBlockerng version ? I could find (nearly ?) identical Python errors, but they were from 4+ years ago.

What are your main resolver settings ? Default ?

tibere86

I have experienced the same thing when running pfBlockerNG with IPv6 DNSBL enabled along with null blocking. What I believe is occurring is that IPv4 sourced requests are null blocked (0.0.0.0 (A) /:: (AAAA)) properly, but IPv6 sourced requests are sent to the DNSBL webserver which then returns SERVFAIL due to cert issue. I posted recently (past month) in the Reddit pfBlockerNG thread about this issue, but have not received a response.

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 :

and call it a day.

If this (example) would show up :

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

or it got back :

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

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 :

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

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