What is the actual purpose of the "Use DNSSEC" option?

SteamType · May 11, 2020, 4:39pm

Hi there! First time poster. I'm a big fan of the work you're all doing.

I have trouble figuring out what is the real usage of the "Use DNSSEC" option in Settings. The way I see it, most of the Pi-hole workflows would most likely fall into one of these categories:

Forwarding requests to an upstream DNS server that supports DNSSEC. In this scenario, the DNSSEC validation will be done by the resolver the requests are forwarded to.
Forwarding requests to an upstream DNS server that supports DNSSEC while using a local DNS proxy to enable to use of DNSCrypt/DoT/DoH. The DNSSEC validation is still done by the upstream resolver.
Using a local resolver like Unbound. The DNSSEC validation would then be done by the local resolver (Unbound).

In these cases, the DNSSEC validation is always done outside of the Pi-hole.

I thought this option could be useful for validating DNSSEC in the event of someone using an upstream DNS resolver not supporting DNSSEC, but the comment under the option in Settings explicitly warns against doing this:
"If a domain fails validation or the upstream does not support DNSSEC, this setting can cause issues resolving domains. Use Google, Cloudflare, DNS.WATCH, Quad9, or another DNS server which supports DNSSEC when activating DNSSEC".

Nevertheless, enabling the option does give a really neat level of insight about the DNSSEC support of domains with the Secure/Insecure/Bogus status. But in my experience with my workflow (Pi-hole --> DNS proxy [Cloudflared or DNSCrypt-Proxy enabling DoH] --> Quad9), the Pi-hole validation also introduces some false positives, marking a certain number of requests "Bogus" when they shouldn't be. Not a lot, but enough to be regularly disruptive.

So in what cases can the "Use DNSSEC" option be really useful?

Oh, and I wanted to take the opportunity to congratulate everybody involved in the 5.0 release. This release rocks! I love it so much!

jfb · May 11, 2020, 4:42pm

This is due to known bugs in dnsmasq 2.80, which ships with V4.x of Pi-hole. The newly release V5.0 of Pi-hole embeds dnsmasq 2.81, which is reported to resolve these problems.

github.com/pi-hole/FTL

Update embedded dnsmasq to v2.81

pi-hole:release/v5.0 ← pi-hole:update/dnsmasq

opened 10:43AM - 13 Oct 19 UTC

DL6ER

+3327 -2537

**By submitting this pull request, I confirm the following (please check boxes, …eg [X]) _Failure to fill the template will close your PR_:** ***Please submit all pull requests against the `development` branch. Failure to do so will delay or deny your request*** - [X] I have read and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- Important or interesting features for us are **highlighted in bold**. ### New features - **Support `TCP-fastopen`** (RFC-7413) on both incoming and outgoing TCP connections, if supported and enabled in the OS. - **Add `--shared-network` config.** This enables allocation of addresses the DHCP server in subnets where the server (or relay) doesn't have an interface on the network in that subnet. - **Add `dhcp-ignore-clid` configuration option** The idea of this option was already discussed years ago on the mailing list: https://dnsmasq-discuss.thekelleys.org.narkive.com/ZoFQNaGo/ always-ignore-client-identifier#post4 In our production environment, we discovered that some devices are using 'client identifier' not unique at all, resulting on IP addresses conflicts between several devices (we saw up to four devices using same IP address). The root cause is probably a buggy operating system/configuration of devices, but this patch adds a configuration workaround on server side when fixing clients is impossible. - Support DHCP option 150 (TFTP server address, RFC 5859) - Support prefixed ranges of IPv6 addresses in `dhcp-host` - Add tag filtering of `dhcp-host` directives - Add `--script-on-renewal` option - Add DHCPv6 ntp-server (56) option handling ### Tweaks - **Improve cache behavior for TCP connections.** For ease of implementation, we always forked a new process to handle each incoming TCP connection. A side-effect of this is that any DNS queries answered from TCP connections are not cached: when TCP connections were rare, this was not a problem. With the coming of DNSSEC, it's now the case that some DNSSEC queries have answers which spill to TCP, and if, for instance, this applies to the keys for the root then those never get cached, and performance is very bad. This fix passes cache entries back from the TCP child process to the main server process, and fixes the problem. - Ensure that AD bit is reset on answers from `--address=/<domain>/<address>`. - Remove ability to compile without IPv6 support. This was the source of a large number of `#ifdefs`, originally included for use with old embedded `libc` versions. I'm sure no-one wants or needs IPv6-free code these days, so this is a move towards more maintainable code. - Remove the `NO_FORK` compile-time option, and support for uclinux. In an era where everything has an MMU, this looks like an anachronism, and it adds to (Ok, multiplies!) the combinatorial explosion of compile-time options. - Free config file values on parsing errors. - Alter DHCP address selection after `DECLINE` in `consec-addr` mode. Avoid offering the same address after a receiving a DECLINE message to stop an infinite protocol loop. This has long been done in default address allocation mode: this adds similar behavior when allocating addresses consecutively. - Severe restructuring of the internally used datastructures (`all_addr` union, log and rcode fields, etc.) - **Cache SRV records.** - Change `read_leases()` to skip invalid entries. There's no reason to stop reading the existing lease file when dnsmasq is started and an invalid entry is found, it can just be ignored. This was fallout from an Openstack bug where the file was being written incorrectly with `[]` around IPv6 addresses. - **DHCP leases: prune lease as soon as expired** We detected a performance issue on a dnsmasq running many dhcp sessions (more than 10 000). At the end of the day, the server was only releasing old DHCP leases but was consuming a lot of CPU. On a server with very large number of leases and releasing often sessions, that can waste a very big CPU time. - **Improve kernel-capability manipulation code** under Linux. The code now fails early if a required capability is not available, and tries not to request capabilities not required by its configuration. - Improve UBus support - Truncate stupidly large cache sizes. If the cache size is very large, the `malloc()` call will overflow on 32 bit platforms and `dnsmasq` will crash. Limit to an order of magnitude less. - Generalise CNAME handling Cope with cached and configured CNAMES for all record types we support, including local-config but not cached types such as TXT. Also, if we have a locally configured CNAME but no target for the requested type, don't forward the query. - Don't waste time caching zero-TTL DNS records - Generalise locally-configured CNAME handling It's now possible for the target of a CNAME to be any locally configured RR or even point to a non-existent RR. - Check for `SERV_NO_REBIND` on unqualified domains - Tweaks to TFTP: - Fail on overlarge files (block numbers are limited to 16 bits) - Honour tftp-max setting in single port mode. - Tweak timeouts, and fix logic which suppresses errors if the last ACK is missing. - Remove experimental DHCPv6 prefix-class support (The standard for this never made it beyond an internet-draft which expired in 2012, so it can be considered dead) - **Enhance `--conf-dir` to load files in a deterministic order** - Allow empty server spec in `--rev-server`, to match `--server` - Optimise closing file descriptors - Ignore routes in non-main tables (can reduce load with large routing tables) - Allow overriding of `ubus` service name ### Fixes Basically all fixes immediately apply to FTL. - Don't forward `*.bind`/`*.server` queries upstream Chaos `.bind` and `.server` (RFC4892) zones are local, therefore don't forward queries upstream to avoid mixing with supported locally and `false` replies with `NO_ID` enabled. - Fix spurious AD flags in some DNS replies from local config. - Fix build after `y2038` changes in `glibc`. - Do not rely on dead code elimination, use array instead. Make options bits derived from size and count. Use size of option bits and last supported bit in computation. No new change would be required when new options are added. Just change OPT_LAST constant. - Keep suitable capabilities if we may bind server sockets to interface or port. - Fix crash when negative SRV response over TCP gets stored in LRU cache entry. - Fix too small control array in tftp code on BSD and SOLARIS This causes tftp to fail on some BSD versions, for sure. It works by chance on others. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241068 - Fix crash freeing negative SRV cache entries. - Check for `not(DS or DNSKEY)` in `is_outdated_cname_pointer()` - Fix entries in /etc/hosts disabling static leases. It is possible for a config entry to have one address family specified by a `dhcp-host` directive and the other added from `/etc/hosts`. This is especially common on OpenWrt because it uses `odhcpd` for DHCPv6 and IPv6 leases are imported into `dnsmasq` via a hosts file. To handle this case there need to be separate *_HOSTS flags for IPv4 and IPv6. Otherwise when the hosts file is reloaded it will clear the CONFIG_ADDR(6) flag which was set by the `dhcp-host` directive. - Fix line-counting when reading `/etc/hosts` and friends For correct error messages. - Fix bug in DNS non-terminal code which could sometimes cause a `NODATA` rather than an `NXDOMAIN` reply. - **Fix compilation against nettle version 3.5 and later.** This fixes #603 - Fix memory leak in `helper.c` - Always force AD bit to zero in authoritative DNS answers. - Fix too small control array in tftp code on BSD and SOLARIS - Don't silently discard all-zeroes addresses in `host-record` - Fix `dhcp-name-match` to function when name supplied in `dhcp-host` - Fix bug which gave zero-length DHCPv6 packets if `sendto()` is interrupted - Fix `dhcp-name-match` to always match client-supplied name - Avoid RA code trampling on DHCPv6 messages - Don't send RAs on interfaces without a link-local address (@DL6ER: the source address of the RAs must be the link-local address) - Do not crash for empty domains in `server=//...` configurations (this bug has been reported by a Pi-hole user, @DL6ER submitted a patch upstream) - Fix RA problems with two interfaces on same IPv6 subnet - Fix infinite-loop router advert problems - Fix problem with netlink socket and TCP DNS - Restore ability to answer non-recursive requests - Fix parameters to `setsockopt()` for `TCP_FASTOPEN` - Update decline address handling in DHCPv6 for new multi-address world When dhcp-host options can have many IPv6 addresses, we need to deal with one of them being declined by a client. The other addresses are still valid - Fix error in IPv6 prefix calculation - Fix resource leak on `ubus_init` failure - Fix nameserver list in auth mode - ### DNSSEC related changes and fixes - Implement RFC-4036 para 5.3.3. rules on TTL values. - **Fix spurious DNSSEC validation failures** when the auth section of a reply proving that a DS record does not exist contains unsigned RRs. Only the NSEC/NSEC3 records needed to prove the non-existence of the DS record must be signed. - Treat DS and DNSKEY queries being forwarded the same as those locally originated. The queries will not be forwarded to a server for a domain, unless there's a trust anchor provided for that domain. This allows, especially, suitable proof of non-existence for DS records to come from the parent domain for domains which are not signed. - Unsigned RRs in auth section proving that a DS doesn't exist are OK. In a reply proving that a DS doesn't exist, it doesn't matter if RRs in the auth section _other_ than NSEC/NSEC3 are not signed. We can't set the AD flag when returning the query, but it still proves that the DS doesn't exist for internal use. As one of the RRs which may not be signed is the SOA record, use the TTL of the NSEC record to cache the negative result, not one derived from the SOA. - Unsigned RRs in the auth section are not bogus. Even if they are in a signed zone. - **Fix crash on `REFUSED` answers to DNSSEC queries.** Some `REFUSED` answers to DNSSEC-originated queries would bypass the DNSSEC code entirely, and be returned as answers to the original query. In the process, they'd mess up datastructures so that a retry of the original query would crash dnsmasq. - Add missing `dump_packet()` for DNSSEC query retries. - Check for `REFUSED` and `SERVFAIL` replies to DNSKEY queries. - Make the existing "insecure DS received" warning more informative by reporting the domain name reporting the issue. This may help identify a problem with a specific domain or server configuration. - Remove DSA signature verification from DNSSEC, as specified in RFC 8624 - Add support for ED448 DNSSEC signature verification (requires `libnettle 3.6`, yet to be released) - Support ECC-GOST DNSSEC signature algorithm (requires `libnettle 3.6`, yet to be released) - Fix rare problem allocating frec for DNSSEC - Tweak to DNSSEC logging

SteamType · May 11, 2020, 5:17pm

Thanks! You really intrigued me so I tried enabling the DNSSEC option again (I'm on 5.0 since yesterday evening). I still got a false positive (trying to access the ICANN website, of all places!). If this can be useful, here's the slightly sanitized relevant part of the pihole.log:

dnsmasq[3680]: query[A] www.icann.org from *.*.*.*
dnsmasq[3680]: forwarded www.icann.org to 127.0.0.1
dnsmasq[3680]: dnssec-query[DS] org to 127.0.0.1
dnsmasq[3680]: reply org is DS keytag 17883, algo 7, digest 1
dnsmasq[3680]: reply org is DS keytag 17883, algo 7, digest 2
dnsmasq[3680]: dnssec-query[DS] icann.org to 127.0.0.1
dnsmasq[3680]: dnssec-query[DNSKEY] org to 127.0.0.1
dnsmasq[3680]: reply org is DNSKEY keytag 62165, algo 7
dnsmasq[3680]: reply org is DNSKEY keytag 27074, algo 7
dnsmasq[3680]: reply org is DNSKEY keytag 17883, algo 7
dnsmasq[3680]: reply icann.org is DS keytag 17248, algo 7, digest 1
dnsmasq[3680]: reply icann.org is DS keytag 18060, algo 7, digest 1
dnsmasq[3680]: reply icann.org is DS keytag 17248, algo 7, digest 2
dnsmasq[3680]: reply icann.org is DS keytag 18060, algo 7, digest 2
dnsmasq[3680]: reply icann.org is DS keytag 41643, algo 7, digest 2
dnsmasq[3680]: reply icann.org is DS keytag 32134, algo 7, digest 2
dnsmasq[3680]: reply icann.org is DS keytag 41643, algo 7, digest 1
dnsmasq[3680]: reply icann.org is DS keytag 32134, algo 7, digest 1
dnsmasq[3680]: reply icann.org is DS keytag 41334, algo 7, digest 1
dnsmasq[3680]: reply icann.org is DS keytag 41334, algo 7, digest 2
dnsmasq[3680]: dnssec-query[DNSKEY] icann.org to 127.0.0.1
dnsmasq[3680]: reply icann.org is DNSKEY keytag 64512, algo 7
dnsmasq[3680]: reply icann.org is DNSKEY keytag 53844, algo 7
dnsmasq[3680]: reply icann.org is DNSKEY keytag 18060, algo 7
dnsmasq[3680]: reply icann.org is DNSKEY keytag 23584, algo 7
dnsmasq[3680]: dnssec-query[DS] vip.icann.org to 127.0.0.1
dnsmasq[3680]: reply vip.icann.org is DS keytag 45993, algo 7, digest 1
dnsmasq[3680]: reply vip.icann.org is DS keytag 45993, algo 7, digest 2
dnsmasq[3680]: dnssec-query[DNSKEY] vip.icann.org to 127.0.0.1
dnsmasq[3680]: reply www.icann.org is <CNAME>
dnsmasq[3680]: reply www.vip.icann.org is 192.0.32.7
dnsmasq[3831]: query[A] www.icann.org from *.*.*.*
dnsmasq[3831]: forwarded www.icann.org to 127.0.0.1
dnsmasq[3831]: dnssec-query[DNSKEY] vip.icann.org to 127.0.0.1
dnsmasq[3831]: validation www.icann.org is BOGUS
dnsmasq[3831]: reply www.icann.org is <CNAME>
dnsmasq[3831]: reply www.vip.icann.org is 192.0.32.7

The Verisign DNSSEC Analyzer doesn't report any problem with the ICANN website (DNSSEC Analyzer - www.icann.org), and when flagged as BOGUS by the Pi-hole, I could load the website correctly after trying to repeatedly access it a few times with the DIG command. This behavior is exactly what I was seeing with the 4.4 release.

Please let me know if I can be of any more help.