DNSSEC discussion - support for proxy-dnssec

pihole checkout ftl update/dnsmasq

  Pi-hole version is v5.16.2 (Latest: v5.16.2)
  AdminLTE version is v5.19 (Latest: v5.19)
  FTL version is update/dnsmasq vDev-879708d (Latest: v5.22)
  1. pihole -vv doesn't show a difference (for dnsmasq) between master & update/dnsmasq, only the FTL info section shows a difference, dnsmasq not updated?
****************************** FTL **********************************
Version:         vDev-879708d
Branch:          update/dnsmasq
Commit:          879708d6 (2023-04-01 14:13:22 +0200)
Architecture:    armv7hf (compiled on CI)
Compiler:        arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0

****************************** dnsmasq ******************************
Version:         pi-hole-v2.89-9461807
Features:        IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile

****************************** SQLite3 ******************************
Version:         3.41.1

******************************** LUA ********************************
Version:         5.4
Libraries:       inspect.lua (8.46 KB)

***************************** LIBNETTLE *****************************
Version:         3.8
GMP:             Full
  1. sudo service pihole-FTL status shows a line:
SHOW_DNSSEC: Enabled, showing automatically generated DNSSEC queries

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?)

Isnt that the "Use DNSSEC" option under the DNS tab?

disabled, message appears anyway

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)


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?

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.

1 Like

see the reply on the unbound mailing list, here.

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:

dig +short TXT CH version.bind -p 5335
"unbound 1.17.1"

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):
Screenshot from 2023-04-07 12-04-51

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.

I asked clarification here, hopefully Simon will read this and react upon the additional information, provided by unbound...

Search results for 'proxy-dnssec' - Pi-hole Userspace

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.

edit Related PR:

pihole-FTL and unbound are running on the same raspberry pi 3B.

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-8a4488c (Latest: v5.22)

in unbound.conf:

# 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

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!

something appears to be wrong.

if FTL is running and responding:

than, when using a browser to visit:

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.

enabled recommended debug flags - see above
visited two "normal" sites, than www.dnssec-failed.org

crash ->
FTL.zip (7.9 KB)


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

no apologies, ensures the 'tester' really does some tests, ensures a better end result.

I now see:

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.

BOGUS (refused upstream) dnssec field value = 3, reply type = 7

No, INSECURE is wrong here. This seems to suggest that there is no EDE from upstream or it isn't interpreted correctly.

Please enable


On my Pi-hole, I see the following for this domain (my logging output is somewhat different):

2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: **** new UDP IPv4 query[A] query "www.dnssec-failed.org" from lo/ (ID 25, FTL 28142, src/dnsmasq/forward.c:1758)
2023-04-08 13:52:41.522 [2159442M] DEBUG_DNSSEC: Setting DNSSEC status to INSECURE in src/dnsmasq_interface.c:763
2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: www.dnssec-failed.org is not known
2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: Checking if "www.dnssec-failed.org" is in gravity: no
2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: Checking if "||org^" is in gravity: no
2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: Checking if "||dnssec-failed.org^" is in gravity: no
2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: Checking if "||www.dnssec-failed.org^" is in gravity: no
2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: DNS cache: is not blocked
2023-04-08 13:52:41.522 [2159442M] DEBUG_QUERIES: **** forwarded www.dnssec-failed.org to (ID 25, src/dnsmasq/forward.c:553)
2023-04-08 13:52:41.523 [2159442M] DEBUG_EDNS0: EDNS(0) pheader: 00 00 29 04 D0 00 00 00 00 00 06 00 0F 00 02 00 06  (17 bytes)
2023-04-08 13:52:41.523 [2159442M] DEBUG_EDNS0: EDNS(0) requestor's UDP payload size: 1232 bytes
2023-04-08 13:52:41.523 [2159442M] DEBUG_EDNS0: EDNS(0) code 15, optlen 2 (bytes 4 - 6 of 6)
2023-04-08 13:52:41.523 [2159442M] DEBUG_EDNS0: EDNS(0) EDE: DNSSEC bogus (code 6)
2023-04-08 13:52:41.523 [2159442M] DEBUG_QUERIES: **** got error reply from www.dnssec-failed.org is SERVFAIL (ID 25, src/dnsmasq/forward.c:786)
2023-04-08 13:52:41.523 [2159442M] DEBUG_QUERIES:      EDE: DNSSEC bogus (6)
2023-04-08 13:52:41.523 [2159442M] DEBUG_DNSSEC: Setting DNSSEC status to BOGUS in src/dnsmasq_interface.c:2516
2023-04-08 13:52:41.523 [2159442M] DEBUG_QUERIES: Set reply to SERVFAIL (7) in src/dnsmasq_interface.c:2519

Can you confirm this or do you see something different (as said, logging output is expected to not be precisely 1:1)?

No, INSECURE is wrong here. This seems to suggest that there is no EDE for upstream or it isn't read properly.

for some reason, there is a difference between:

cleared the FTL log, performed the requests as listed above, with debug flags enabled.

FTL.zip (9.6 KB)

I don't have any DNSSEC extensions in the browser.

the messages start changing


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

means you're having fun?

  • added the 99-record.conf file

  • 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

FTL.zip (35.5 KB)

Thanks, is there still something unexpected in the Query Log (dashboard) as in your screenshot earlier?

start of test:

already forwarded: