Pi-hole: Resolution of domain pi.hole fails ue to DNSSEC issue (systemd-resolved, dnsmasq)

[flannelhead]

In raising this issue, I confirm the following:

• [x] I have read and understood the contributors guide.
• [x] The issue I am reporting can be replicated.
• [x] The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:

1

---

Expected behaviour:

On a computer using systemd-resolve as the DNS resolver, Pi-hole web GUI (on another computer in the same network) can be accessed at address http://pi.hole/admin.

Actual behaviour:

DNS queries of address pi.hole fail due to a DNSSEC error.
$ dig pi.hole gives no resolution.
$ resolvectl query pi.hole gives:
pi.hole: resolve call failed: DNSSEC validation failed: no-signature

Pi-hole web GUI is however accessible by the IP address of the Pi-hole server, i.e. navigating to http://192.168.0.31/admin gives the admin UI.

For comparison, navigating to pi.hole works on Windows (same computer) and Android. Also otherwise Pi-hole is functional and DNS resolution of Internet domains confirmedly works on any client device.

Steps to reproduce:

Set up systemd-resolved as the DNS resolver using e.g. the instructions on Arch Wiki. Ensure that the option

[Resolve]
DNSSEC=allow-downgrade

is set in /etc/systemd/resolved.conf (this is the default setting). Ensure the Pi-hole is available by its IP and is set as the DNS server on the client computer. Then run the command:
$ resolvectl query pi.hole
which should yield the output:
pi.hole: resolve call failed: DNSSEC validation failed: no-signature
The command
$ dig pi.hole
should also fail.

I was also able to reproduce this by using dnsmasq instead of systemd-resolved, configuring DNSSEC per these instructions.

Debug token provided by uploading pihole -d log:

https://tricorder.pi-hole.net/0cp6tm31d8!

Troubleshooting undertaken, and/or other relevant information:

Setting

[Resolve]
DNSSEC=no

will result in the DNS query of pi.hole succeeding. Same with dnsmasq (instead of systemd-resolved) if the dnssec section is removed from the dnsmasq config.

[dschaper]

pi.hole is indeed an unsigned record, and should be handled as any other unsigned record.

Setting DNSSEC=allow-downgrade will show the behavior you are seeing:

Man Page:

Client programs looking up DNS data will be informed whether lookups could be verified using DNSSEC, or whether the returned data could not be verified (either because the data was found unsigned in the DNS, or the DNS server did not support DNSSEC or no appropriate trust anchors were known). In the latter case it is assumed that client programs employ a secondary scheme to validate the returned DNS data, should this be required.

You are being informed that the data could not be verified because it was found unsigned.

I do not see this as an issue.

As for the debug token, you do not have Pi-hole configured correctly. You have configured Pi-hole to be on an address at 192, but the address of the interface eth0 is on 172.

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
   172.19.0.2/16 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)

[✗] No IPv6 address(es) found on the eth0 interface.

[i] Default IPv4 gateway: 172.19.0.1
   * Pinging 172.19.0.1...
[✓] Gateway responded.

*** [ DIAGNOSING ]: Ports in use
[*:53] is in use by pihole-FTL
[*:53] is in use by pihole-FTL
[127.0.0.1:4711] is in use by pihole-FTL

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] www.ws002.www.datasecu.download is 0.0.0.0 via localhost (127.0.0.1)
[✗] Failed to resolve www.ws002.www.datasecu.download via Pi-hole (192.168.0.31)
[✓] doubleclick.com is 216.58.211.142 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Pi-hole processes
[✗] lighttpd daemon is inactive
[✗] pihole-FTL daemon is inactive

*** [ DIAGNOSING ]: Setup variables
    BLOCKING_ENABLED=true
    PIHOLE_DNS_1=1.1.1.1
    PIHOLE_DNS_2=1.0.0.1
    QUERY_LOGGING=true
    INSTALL_WEB_SERVER=true
    INSTALL_WEB_INTERFACE=true
    LIGHTTPD_ENABLED=
    IPV4_ADDRESS=192.168.0.31
    IPV6_ADDRESS=
    PIHOLE_INTERFACE=eth0

[flannelhead]

Thank you for the reply, @dschaper.

pi.hole is indeed an unsigned record, and should be handled as any other unsigned record.

Setting DNSSEC=allow-downgrade will show the behavior you are seeing:

Man Page:

Client programs looking up DNS data will be informed whether lookups could be verified using DNSSEC, or whether the returned data could not be verified (either because the data was found unsigned in the DNS, or the DNS server did not support DNSSEC or no appropriate trust anchors were known). In the latter case it is assumed that client programs employ a secondary scheme to validate the returned DNS data, should this be required.

You are being informed that the data could not be verified because it was found unsigned.

Yes, indeed this seems to be true. Since this is preventing the resolution of pi.hole on client devices, I wonder if I have to adjust Pi-hole or systemd-resolved somehow to resolve the issue. The obvious fix would be turning DNSSEC of in systemd-resolved, but obviously that is a tradeoff.

From the systemd-resolved manual:

Site-private DNS zones generally conflict with DNSSEC operation, unless a negative (if the private zone is not signed) or positive (if the private zone is signed) trust anchor is configured for them. If "allow-downgrade" mode is selected, it is attempted to detect site-private DNS zones using top-level domains (TLDs) that are not known by the DNS root server. This logic does not work in all private zone setups.

I wonder if it would be possible to make such a configuration to Pi-hole (adding a negative trust anchor?) that the pi.hole domain could be resolved even with DNSSEC on.

As for the debug token, you do not have Pi-hole configured correctly. You have configured Pi-hole to be on an address at 192, but the address of the interface eth0 is on 172.

Yep, indeed this is the case. The Pi has the address 192.168.0.31 in the local network, but Pi-hole is running in Docker which has its own virtual network with the 172 address. The relevant ports are forwarded out of the container. I had to set $ServerIP explicitly so that pi.hole would give 192.168.0.31 as the address. Otherwise it would actually respond with 0.0.0.0 for some reason. (That's a separate issue with docker-pi-hole, which seems to have been already reported.)

[dschaper]

Yes, indeed this seems to be true. Since this is preventing the resolution of pi.hole on client devices, I wonder if I have to adjust Pi-hole or systemd-resolved somehow to resolve the issue. The obvious fix would be turning DNSSEC of in systemd-resolved, but obviously that is a tradeoff.

If Pi-hole is utilizing DNSSEC and validating the records as it receives query responses then having the clients validate data already validated doesn't do anything but complicate the configurations really. If you trust Pi-hole to properly validate the records, then let it handle that task as designed and turn of DNSSEC in systemd-resolved.

[flannelhead]

Thank you for the reply, again. :)

The client I have is a laptop and thus not always using Pi-hole as the DNS (although soon could be if I set up a VPN); therefore I wouldn't like to disable DNSSEC. However, it turned out the resolution was as simple as just creating a file /etc/dnssec-trust-anchors.d/pihole.negative with a single line pi.hole on the client computer.

Would this be something worth documenting? Since the default configuration of systemd-resolved at least on Arch is allow-downgrade, having this solution written down somewhere would probably save debugging for people stumbling upon the issue. I can submit the necessary edits if there is a proper place to put them :)