How do I disable this? I don't use DNSSEC with dnsmasq, Unbound is handling DNSSEC (would be nice if proxy-dnssec - dnsmasq setting - generated something meaningful, using the info from unbound, now it's SERVFAIL - possible?)
This is always the case for update/dnsmasq, the dnsmasq version string does only update on dnsmasq tags - which hasn't happened so far.
Well, as always: simply set SHOW_DNSSEC=false in /etc/pihole/pihole-FTL.conf
Not possible. The SERVFAIL from unbound does not include any reason, it is simply a SERVFAIL. proxy-dnssec is "broken by design" and should be considered deprecated.
In most cases, enabling DNSSEC validation within dnsmasq is a better option.
I have it in both FTL and unbound and have not encountered a single false-positive in the last two years.
I occasionally read topics (various forums), claiming unbound returns false positives, experienced them occasionally myself, found this work around in the unbound mailing list.
second message: permanent work around (unbound config change)
third message: temporary work around (unbound- control command)
edit
wouldn't it be great if you provided a pihole-FTL.conf with all configuration options listed, like a lot of other programs do, e.g.
# Should FTL analyze and include automatically generated DNSSEC queries in the Query Log?
# SHOW_DNSSEC=true
The file is automatically generated, automatically reloaded on changes and FTL will even annotate what the default was when you change it and clearly mark the value as changed. It is furthermore possible in v6.0 to change everything from the web interface.
Unbound with DNSSEC validation configured will reply with the AD bit for
secure answers and SERVFAIL for bogus answers. Insecure answer will get
the answer without the AD bit set.
Newer versions (>= 1.16.0) will also attach EDE codes for DNSSEC
validation failures to the SERVFAIL answers.
This is a quote from the dnsmasq man. Does make me think of this, translates to something like "we from wceend (the company) recommend wceend ( the product)...
dnsmasq with option proxy-dnssec doesn't do any DNSSEC related analysis at all so this will not be in the logs, either. FTL could, however, look at the queries, check the AD bit of successful queries and trust this as SECURE or INSECURE. For SERVFAIL, we could indeed check the EDE and derive BOGUS when this is the case.
see the reply on the unbound mailing list
Our development server is running Ubuntu 22.04 which ships unbound 1.13.1. I set up a separate unbound next to it but am not seeing any EDNS details in the SERVFAIL:
After searching quite deeply through the unbound documentation, I found:
The EDE errors can be turned on by ede: yes, it is default disabled. Validation errors and other errors are then reported.
And, indeed, setting this to yes gives us some EDE response code (Wireshark screenshot):
Neither dnsmasq not FTL post-process the ENDS data from failed replies so far. I will look into changing this. Feel free to remind me at some point if I forget about it. However, do not read this a promise that it will be added. If this turns out to need a major rewrite at some point, I'm not very in favor of it given that (a) enabling DNSSEC validation in dnsmasq/pihole-FTL is a good (and the typically used) option and that (b) EDNS is even disabled by unbound by default. This feature is not likely to reach more than two users in the end.
Please try FTL branch new/ede-dnssec. When you enable the debug flags DEBUG_QUERIES, DEBUG_EDNS0 and DEBUG_DNSSEC, you should see related lines in FTL.log. But even without these debug flags, you should see the status being reflected on the web interface when proxy-dnssec is used.
Note that this will make FTL trust whatever upstream in not being able to have been modified in transit. This is typically a valid assumption on your local network (moreover on the same device), but not across the Internet. SERVFAIL will be considered BOGUS if the upstream contains related EDE information. However, this can also lead to incorrect SECURE marks when your upstream sets the AD bit for whatever reason. This is also the reason why it is recommended to have dnsmasq/pihole-FTL do DNSSEC instead of using proxy-dnssec.
# required for proxy-dnssec (dnsmasq)
ede: yes
ede-serve-expired: yes
in dnsmasq.d/dnssec.conf
# requires use of "ede: yes" and "ede-serve-expired: yes" in unbound.conf
proxy-dnssec
I assume the value in pihole-FTL.db / query_storage / dnssec DON'T match the values, described in this document. Is there a mapping available between unbound EDE code and the dnssec value in the database?
will now try to see if the dnsmasq options "dnssec-no-timecheck" and "dnssec-check-unsigned=no" do what is expected...
I hope this will remain part of FTL.
Thanks for your time, effort and another great addition to pi-hole!
http://www.dnssec-failed.org/
resolving stops, no more dns, no more dashboard, ftl restart required to solve the problem
the system (linux terminal) remains responsive, load average: 0.02, 0.05, 0.06
opening the web interface in an alternate browser has the same result, can login, but no result.
edit
enabled recommended debug flags - see above
visited two "normal" sites, than www.dnssec-failed.org
Sorry. I have seen the cause - SERVFAIL with invalid EDE data from upstream was causing this. I just pushed the fix for it, forgot to hit "Git Push" yesterday...
INSECURE (refused by upstream), however the dnssec field value = 2, reply type = 7 Does this imply I will never see BOGUS / ABANDONED in the query log (need to consult the unbound log for detail?). This is NOT a problem, much better than simple SERVFAIL.
Okay, this is interesting... The first one behaves as expected (BOGUS) and is of type A. The two others are not. However, this isn't the important difference here. Your upstream apparently really didn't include the EDE codes in the two INSECURE cases.
To verify this, we need to pump the reply received from unbound. It can be enabled by adding the following to a file like /etc/dnsmasq.d/99-record.conf:
dumpfile=/etc/pihole/dump.pcap
dumpmask=0x00ff
This file should show us if my speculation is right and it is missing from upstream. Please also upgrade your FTL before as I added a bit more debug logging to the ENDS0 code (no functional change) - the compilation is still running and should be done in 1-2 minutes (done and uploaded).
installed new ftl
Pi-hole version is v5.16.2 (Latest: v5.16.2)
AdminLTE version is v5.19 (Latest: v5.19)
FTL version is new/ede-dnssec vDev-538c6a0 (Latest: v5.22)
cleared ftl log
ran the tests in the given order (dig A , followed by dig AAAA, edge, firefox
