Nein.
Ich hätte darauf hinweisen sollen, dass ich die manuelle Konfiguration aktiviert habe.
Das heißt, es wird genau die unbound Konfiguration verwendet, die im Blog Artikel dokumentiert ist:
server:
# If no logfile is specified, syslog is used
# logfile: "/var/log/unbound/unbound.log"
username: unbound
pidfile: /var/run/unbound.pid
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
verbosity: 0
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
# 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
## Performance
# More cache memory, rrset=msg*2 | Default: 4m, 4m
msg-cache-size: 32m
rrset-cache-size: 64m
# Time to live [minimum|maximum] for RRsets and messages in the cache | Default: 0, 86400
cache-min-ttl: 3600
cache-max-ttl: 86400
# Serve old responses from cache with a TTL of 0 in the response without waiting for the actual resolution to finish | Def
ault: no, 0
serve-expired: yes
serve-expired-ttl: 86400
# Fetch DNSKEYs earlier (DNSSEC): More cpu usage, less latency | Default: no
prefetch-key: yes
# Helps to reduce the query rate towards targets that get a very high nonexistent name lookup rate | Default: yes
aggressive-nsec: yes
Nur bei Verwendung dieser Konfiguration lauscht unbound auf 127.0.0.1:5335.
Wenn ich auf die von OpenWrt generierte Konfiguration umstelle, dann sehen die Services etwas anders aus:
root@router:~# netstat -tulpn | grep 53
tcp 0 0 172.16.10.2:53 0.0.0.0:* LISTEN 3268/AdGuardHome
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 6776/unbound
tcp 0 0 0.0.0.0:5335 0.0.0.0:* LISTEN 6776/unbound
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 3268/AdGuardHome
tcp 0 0 172.16.1.2:53 0.0.0.0:* LISTEN 3268/AdGuardHome
tcp 0 0 ::1:53 :::* LISTEN 3268/AdGuardHome
tcp 0 0 ::1:8953 :::* LISTEN 6776/unbound
tcp 0 0 :::5335 :::* LISTEN 6776/unbound
udp 0 0 172.16.10.2:53 0.0.0.0:* 3268/AdGuardHome
udp 0 0 172.16.1.2:53 0.0.0.0:* 3268/AdGuardHome
udp 0 0 127.0.0.1:53 0.0.0.0:* 3268/AdGuardHome
udp 0 0 0.0.0.0:5335 0.0.0.0:* 6776/unbound
udp 0 0 ::1:53 :::* 3268/AdGuardHome
udp 0 0 :::5335 :::* 6776/unbound
Wenn ich dann dig fail01.dnssec.works @172.16.1.2 -p 53 ausführe, dann ist die Ausgabe so wie gewünscht:
root@router:~# dig fail01.dnssec.works @172.16.1.2 -p 53
; <<>> DiG 9.20.4 <<>> fail01.dnssec.works @172.16.1.2 -p 53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25862
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fail01.dnssec.works. IN A
;; Query time: 0 msec
;; SERVER: 172.16.1.2#53(172.16.1.2) (UDP)
;; WHEN: Mon Mar 10 19:48:12 CET 2025
;; MSG SIZE rcvd: 48
