Issue Description
I know this is not a Pi-hole issue and may just be an unbound configuration issue or, simply Docker/AWS DNS is configured wrong for DNSSEC.
I noticed I could no longer pull Docker images after moving my Pi-Hole into production. I have DNSSEC enabled in Pi-Hole and the Upstream DNS Server pointed to the local unbound instance at 127.0.0.1#5335.
Following documentation and using the unbound Configure unbound - Pi-hole documentation, I get an NXDOMAIN response for production.cloudflare.docker.com which is preventing my Docker hosts from pulling Docker images.
The only two ways I have been able to resolve this is to either disable DNSSEC in Pi-Hole Admin --> Settings --> DNS --> Uncheck Use DNSSEC or by modifying /etc/unbound/unbound.conf.d/pi-hole.conf and forwarding all queries to Cloudflare via TLS.
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853
Expected Behaviour:
➜ ~ dig production.cloudflare.docker.com @127.0.0.1#5335
; <<>> DiG 9.10.6 <<>> production.cloudflare.docker.com @192.168.7.20
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22364
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;production.cloudflare.docker.com. IN A
;; ANSWER SECTION:
production.cloudflare.docker.com. 281 IN A 104.18.122.25
production.cloudflare.docker.com. 281 IN A 104.18.123.25
production.cloudflare.docker.com. 281 IN A 104.18.124.25
production.cloudflare.docker.com. 281 IN A 104.18.121.25
production.cloudflare.docker.com. 281 IN A 104.18.125.25
;; Query time: 83 msec
;; SERVER: 192.168.7.20#53(192.168.7.20)
;; WHEN: Tue Oct 18 10:42:25 EDT 2022
;; MSG SIZE rcvd: 141
Running on a Raspberry Pi 4B
➜ ~ pihole -v
Pi-hole version is v5.13 (Latest: v5.13)
AdminLTE version is v5.16 (Latest: v5.16)
FTL version is v5.18.2 (Latest: v5.18.2)
➜ ~ lsb_release -s -d
Ubuntu 22.04.1 LTS
➜ ~ uname -o -r -m
5.15.0-1016-raspi aarch64 GNU/Linux
Actual Behaviour:
➜ ~ dig production.cloudflare.docker.com @127.0.0.1 -p 5335
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> production.cloudflare.docker.com @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64316
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;production.cloudflare.docker.com. IN A
;; AUTHORITY SECTION:
docker.com. 324 IN SOA ns-207.awsdns-25.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 1799 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Tue Oct 18 10:48:26 EDT 2022
;; MSG SIZE rcvd: 139
Debug Token:
Debug Token - Uploaded Oct 18 2022 10:50 AM Eastern
Supporting config
Just to post it, here is my entire /etc/unbound/unbound.conf.d/pi-hole.conf
server:
# If no logfile is specified, syslog is used
logfile: "/var/log/unbound.log"
verbosity: 5
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: no
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single
machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10