@DL6ER Is SHOW_DNSSEC=false in /etc/pihole/pihole-FTL.conf the same as unchecking validate DNSSEC in the front end?
NO it's not, SHOW_DNSSEC=false in /etc/pihole/pihole-FTL.conf only affects logging.
This is expected and conforms to this comment on the reliability of the AD bit when using proxy-dnssec ( dnsmasq man page):
--proxy-dnssec
Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients. This is an alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between dnsmasq and the upstream servers, and the trustworthiness of the upstream servers. Note that caching the Authenticated Data bit correctly in all cases is not technically possible. If the AD bit is to be relied upon when using this option, then the cache should be disabled using--cache-size=0. In most cases, enabling DNSSEC validation within dnsmasq is a better option. See--dnssecfor details.
Screams for a PCAP, I'd say.
This has already been answered by @jpgpi250 .
1 Like
compiled the unbound branch with caching (git clone --branch features/ede-caching-cachedb h t t p s://github.com/NLnetLabs/unbound)
what does INSECURE (stale answer) mean?
INSECURE is the DNSSEC status (AD bit was 0 from unbound) as usual.
The extra text "(stale answer)" is the EDE status reported from the upstream. In this case, unbound responded with an expired answer and you have ede-serve-expired: yes enabled to make this visible.
I can't find anything in the database that reflects the EDE codes, reported.
Will these codes be added to the database (FR), so that the DNSSEC status, including the EDE values, will also be available in the long-term Data (web interface) and sqlite3 reports (grafana - custom)?
EDE codes are not stored in the database, a lot other things aren't either (think of TTL, etc.). With v6.0, we reduce the default database retention from 12 to 3 months and can use the extra space to store additional details. Storing EDE isn't currently planned mainly because it has not been used much and almost no upstreams supported it but this has now changed with more recent unbound. So yeah, this will be considered, too.
So far, the v6.0 code does not change any database schema to avoid breaking changes because I frequently need to switch back and forth when adding new feature like PR #1551. We're already past the point where I should have set up separated/dedicated machines for v5.x and v6.0 development (actually, the machine planned to be used for v6.0 became my main Pi-hole when the Raspberry PCB died last year).
1 Like
I'm still hoping, once all unbound EDE related PR's are available in a single branch, the use of proxy-dnssec will display correct information. Currently, I'm using the unbound branch (see above) that allows redis caching, and can confirm the BOGUS status is always correct (dig & browser).
Reason for this request (storing EDE in database) is the fact the "realtime" data only covers the latest 100 queries (10 pages). Sometimes the number of queries is so high it becomes impossible to check the status of the previous request (for the same domain), adding the data to the database would make this info available in the long-term data.
Is it even necessary to add a database field? Can the additional data be reflected in the current dnssec field, using more values than the current (0..4)?
Changing the definition of the dnssec field is a breaking change. Imagine users with custom scripts that did not see this discussion here. Their scripts may simply break. Additional fields are much less invasive to third-party scripts.
You can already now get correct information by simply switching on dnssec in Pi-hole 
As has also been repeated on the mailing list, there will be no additional traffic generated by this as unbound already has the very same records for its own validation.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.