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?)
So it seems useful to have Pi-hole doing this, too.
This is exactly what v6.0 is doing, see here for an example:
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.
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)
# requires use of "ede: yes" and "ede-serve-expired: yes" in unbound.conf
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!
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:
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).