Unbound DNSSEC not working after upgrade to 4.0

[diameter]

I was a beta tester before 4.0. I had followed the instructions from this page Redirecting...

Per the instructions is this test:
You can test DNSSEC validation using

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353
dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353

Now post the update to 4.0, when I test DNSSEC using these commands, I get the following errors:

user@pihole:~ $ dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.10.3-P4-Raspbian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; connection timed out; no servers could be reached
user@pihole:~ $ dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353

; <<>> DiG 9.10.3-P4-Raspbian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5353
;; global options: +cmd
;; connection timed out; no servers could be reached

The test from here: https://dnssec.vs.uni-due.de/
now shows this:

DNSSEC Resolver Test

This test determines whether your DNS resolver validates DNSSEC signatures. For this test you need JavaScript turned on.

WARNING: test result is inconclusive. You may be suffering from low network performance or have a sensitive adblocker.

Most people will experience a negative test result (no DNSSEC validation) – that's ok and no reason to panic.

Note, before the update to 4.0 this worked fine.

To update to 4.0 I did the following:
pihole checkout master
sudo rm /etc/pihole/ftlbranch

The update performed successfully without errors. When I then did pihole -up, everything was up to date. The bottom of the web page is showing:
Pi-hole Version v4.0 Web Interface Version v4.0 FTL Version v4.0

Thank you for your help!

[diameter]

I followed this from the beta article

Help Us Beta Test FTLDNS – Pi-hole

If you want to go back to the master branch at any time, the reversal process is fairly trivial:

To Revert to master:

sudo rm /etc/pihole/ftlbranch
pihole checkout master

Should I have not removed that branch?

[technicalpyro]

Yes you should remove the ftlbranch file. The error you are seeing is one due to unbound NOT due to v4.0 i would double check the setupo guide and your unbound config files to make sure nothing has changed to be sure and troubleshoot from there

[diameter]

I turned off DNSSEC in the pihole DNS settings and now it works fine. Thank you!

[diameter]

These are my settings now:
Never forward non-FQDNs -> Checked
Never forward reverse lookups for private IP ranges -> Checked
Use DNSSEC -> Unchecked

Is this correct when using unbound?

Thank you.

[diameter]

I'm using unbound and I noticed now that I "unchecked" Use DNSSEC, the DNSSEC test succeeds, but I no longer see DNSSEC in the log. Is this by design?
Thank you

[diameter]

Thank you technicalpyro for your response. Checking out the branch to Master should not change my unbound config files, correct? They were set during the beta according to your documentation.

To ensure I understand the upgrade properly since I was coming from the beta with unbound...
The upgrade to 4.0 is does not include unbound. However, it adds the necessary files in the upgrade to support it. To get unbound working, one must follow this doc

Redirecting...

And this doc which I followed during the beta has not changed for 4.0?
I'm sorry, it's all a bit confusing. Thank you!

[technicalpyro]

yes that is correct the upgrade will not touch unbound at all however it seems the issue you saw was due to having DNSSEC enabled on the Pi-hole side.

to move from the beta back to master delete the /etc/pihole/ftlbranch file and run pihole checkout master

[DL6ER]

@diameter

now that I “unchecked” Use DNSSEC, the DNSSEC test succeeds, but I no longer see DNSSEC in the log.

This is correct. When we don't validate DNSSEC inside Pi-hole ourselves, we have no way of getting the proper DNSSEC response. As of Pi-hole v4.0 (including dnsmasq v2.79), DNSSEC is still knows to cause some (but unfortunately enough!) headaches. We hope that this improves in a future version. One of the next versions (may already be in Pi-hole v4.1, but it largely depends on the development state of dnsmasq at that time), will at least propagate the SERVFAIL message, generated by unbound when the domain is BOGUS, into the Query Log.