pihole uses the router (fritzbox) as the only upstream
the router distributes pihole as the local DNS via DHCP
conditional forwarding is disabled (because the router is already the upstream)
In this scenario, I tried enabling DNSSEC, but it seems to break the lookup of the local domain (fritz.box). From the dnsmasq log, I get that the IP was resolved correctly but DNSSEC transforms the reply into a servfail:
Dec 6 23:36:17 dnsmasq[446]: query[A] fritz.box from 192.168.188.102
Dec 6 23:36:17 dnsmasq[446]: forwarded fritz.box to fd00::464e:6dff:xxxx:xxxx
Dec 6 23:36:17 dnsmasq[446]: dnssec-query[DS] fritz.box to fd00::464e:6dff:xxxx:xxxx
Dec 6 23:36:17 dnsmasq[446]: reply fritz.box is BOGUS DS
Dec 6 23:36:17 dnsmasq[446]: validation fritz.box is BOGUS
Dec 6 23:36:17 dnsmasq[446]: reply fritz.box is 192.168.188.1
DNSSEC enabled:
% dig fritz.box @192.168.188.111
; <<>> DiG 9.10.6 <<>> fritz.box @192.168.188.111
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4581
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;fritz.box. IN A
;; Query time: 65 msec
;; SERVER: 192.168.188.111#53(192.168.188.111)
;; WHEN: Sun Dec 06 23:54:43 CET 2020
;; MSG SIZE rcvd: 27
DNSSEC disabled:
% dig fritz.box @192.168.188.111
; <<>> DiG 9.10.6 <<>> fritz.box @192.168.188.111
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58685
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; QUESTION SECTION:
;fritz.box. IN A
;; ANSWER SECTION:
fritz.box. 9 IN A 192.168.188.1
;; AUTHORITY SECTION:
fritz.box. 9 IN NS fritz.box.
;; ADDITIONAL SECTION:
fritz.box. 9 IN A 192.168.188.1
fritz.box. 9 IN AAAA fd00::464e:6dff:xxxx:xxxx
;; Query time: 63 msec
;; SERVER: 192.168.188.111#53(192.168.188.111)
;; WHEN: Sun Dec 06 23:54:56 CET 2020
;; MSG SIZE rcvd: 101
Is there a way to either fix DNSSEC for the local domain or exclude it from DNSSEC?
First, if your using the Fritzbox as your sole upstream then you don't need to use both an IPv4 and an IPv6 address. IPv4 is fine, it will respond with AAAA records without issue.
Dec 7 00:02:35 dnsmasq[593]: using nameserver fd00::464e:6dff:fe43:636f#53
Dec 7 00:02:35 dnsmasq[593]: using nameserver 192.168.188.1#53
Second, the Fritz is the one returning the BOGUS DS response, Pi-hole is just forwarding that along.
Dec 6 23:36:17 dnsmasq[446]: dnssec-query[DS] fritz.box to fd00::464e:6dff:xxxx:xxxx
Dec 6 23:36:17 dnsmasq[446]: reply fritz.box is BOGUS DS
Dec 6 23:36:17 dnsmasq[446]: validation fritz.box is BOGUS
Dec 6 23:36:17 dnsmasq[446]: reply fritz.box is 192.168.188.1
You can try dig +trace ds fritz.box but I don't think you'll get DNSSEC working on a local domain like that since there isn't a .box TLD or a root . record to start the DNSSEC chain.
Lastlly, check your IPv6 configuration, it's not set up correctly.
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] dvvkdxejwh.com is 0.0.0.0 via localhost (127.0.0.1)
[✓] dvvkdxejwh.com is 0.0.0.0 via Pi-hole (192.168.188.111)
[✓] doubleclick.com is 172.217.168.78 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] pilkanozna.yolasite.com is :: via localhost (::1)
[✓] pilkanozna.yolasite.com is :: via Pi-hole (fd00::211:32ff:feca:bcef)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
There's no access from the Pi-hole to 2001:4860:4860::8888
And noted that you're using ngnix so there may be other configuration changes that you have made that we are unable to see.
In addition to Dan's findings from your debug log, I can confirm that behaviour for Fritzboxes:
DNSSEC for fritz.box domains fails because either it cannot establish a chain of trust for fritz.box or because it somehow -in absence of a proper .box parent - expects fritz.box to be digitally signed. You may be able to get around this by settting up the appropriate SOA and NS records for box, but I think you can't do so with Pi-hole's dnsmasq alone.
Fortunately, dnsmasq also supports disabling DNSSEC for fritz.box: Conditional Forwarding will get you a working resolution for fritz.box domains.
Strictly speaking, setting the appropriate server option would be enough, as
DNSSEC validation is turned off for such private nameservers (...)
(quoted from dnsmasq documentation)
You could achieve this without CF, by creating a custom dnsmasq configuration (e.g. at /etc/dnsmasq.d/42-dnssec-local-bypass.conf) containing just the following line:
server=/fritz.box/192.168.178.1
Adjust the IP address to match your FB as required.
Caution when using this latter approach:
You have to remember to watch out for potential conflicts when enabling CF at a later time.
I wasn't aware that conditional forwarding disables DNSSEC validation for private nameservers and that is a fine workaround.
Regarding IPv6 connectivity: I don't have a working native IPv6 internet connection, so not being able to reach 2001:4860:4860::8888 is probably expected. My intention to configure IPv6 for pihole is to use IPv6 for the local connection to the FB.
Since you do not have public IPv6 connectivity, there is no advantage using IPv6 in your local private network (and as far as public networking is concerned, advantages would lie mainly with ISPs).
If you are doing this to make yourself familiar with IPv6, that's actually a good approach, as you don't run any risk of involuntarily exposing devices via their public IPv6 address.
If learning about IPv6 is not your intention, you may as well spare yourself from a few head-aches by disabling IPv6 altogether.
Really not needed. It will provide AAAA records over IPv4 just fine. Though not having anything to reach those AAAA associated addresses makes the process kind of futile and just adds more wait time as your clients try IPv6 and fail before trying the IPv4 address.
Right, I don't want to derail this thread with IPv6 My intention was to prepare my networking setup to be ready for the day when my ISP finally decides to support it, but that might take another decade or so.
Btw, I did not configure nginx consciously - I use the official Docker image.
Ah, information like Docker and Synology are good things to know ahead of time. We have separate sections for those topics because their use can affect Pi-hole and how we approach troubleshooting.
My intention was to prepare my networking setup to be ready for the day when my ISP finally decides to support it, but that might take another decade or so.