Unbound erreicht Root-Server nicht

[zotac94]

Hallo zusammen

Ich nutze Unbound in Verbindung mit pihole auf meiner Synology. Unbound läuft als Docker Container von mvance.
Mir ist nach einer Zeit mit Unbound aufgefallen, dass gewisse Domains nicht aufgelöst werden können, welche ohne Unbound aber normal aufgelöst werden können.

pihole & unbound laufen im Hostnetzwerk. pihole unter Port 53 & unbound unter 5335.
Ich synce 1x pro Monat die root-Datei von internic:

wget https://www.internic.net/domain/named.root -O /volume3/docker/unbound/root.hints
sudo docker exec unbound unbound-anchor -a /opt/unbound/etc/unbound/root.key

Der Dockercontainer hat keine Einstellungen, bis auf das Volumemapping & die Netzwerkeinstellung Host.

Mein Unbound Config File sieht wie folgt aus (ich habe bereits auch komplett neu angefangen mit dem Configfile von mvance und nur angepasstem Port):

# sudo grep -v '#\|^$' -R /volume3/docker/unbound/unbound.conf*
server:
    cache-max-ttl: 86400
    cache-min-ttl: 300
    directory: "/opt/unbound/etc/unbound"
    ede: yes
    ede-serve-expired: yes
    edns-buffer-size: 1232
    interface: 0.0.0.0@5335
    rrset-roundrobin: yes
    username: "_unbound"
    log-local-actions: no
    log-queries: no
    log-replies: no
    log-servfail: no
    logfile: /opt/unbound/etc/unbound/unbound.log
    verbosity: 1
    aggressive-nsec: yes
    delay-close: 10000
    do-daemonize: no
    do-not-query-localhost: no
    neg-cache-size: 4M
    qname-minimisation: yes
    access-control: 127.0.0.1/32 allow
    access-control: 192.168.0.0/16 allow
    access-control: 172.16.0.0/12 allow
    access-control: 10.0.0.0/8 allow
    auto-trust-anchor-file: "/opt/unbound/etc/unbound/root.key"
    chroot: "/opt/unbound/etc/unbound"
    deny-any: yes
    harden-algo-downgrade: yes
    harden-unknown-additional: yes
    harden-below-nxdomain: yes
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-large-queries: yes
    harden-referral-path: no
    harden-short-bufsize: yes
    hide-http-user-agent: no
    hide-identity: yes
    hide-version: yes
    http-user-agent: "DNS"
    identity: "DNS"
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    ratelimit: 1000
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
    unwanted-reply-threshold: 10000
    use-caps-for-id: no
    val-clean-additional: yes
    infra-cache-slabs: 4
    incoming-num-tcp: 10
    key-cache-slabs: 4
    msg-cache-size: 2720966656
    msg-cache-slabs: 4
    num-queries-per-thread: 4096
    num-threads: 1
    outgoing-range: 8192
    rrset-cache-size: 5441933312
    rrset-cache-slabs: 4
    minimal-responses: yes
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    sock-queue-timeout: 3
    so-reuseport: yes
        root-hints: "/opt/unbound/etc/unbound/root.hints"
    include: /opt/unbound/etc/unbound/a-records.conf
    include: /opt/unbound/etc/unbound/srv-records.conf
    include: /opt/unbound/etc/unbound/forward-records.conf
remote-control:
    control-enable: no

Als ich einwenig mit dig lokal auf der Synology rumexperimentierte, ist mir aufgefallen, dass ich nicht einmal die Root Server erreiche über Unbound (pihole erreicht diese, wenn ich den Upstream Server auf Cloudflare habe).

# ./dig +trace j.root-servers.net u/127.0.0.1 -p5335

; <<>> DiG 9.16.34 <<>> +trace j.root-servers.net u/127.0.0.1 -p5335
;; global options: +cmd
.                       86336   IN      NS      a.root-servers.net.
.                       86336   IN      NS      b.root-servers.net.
.                       86336   IN      NS      c.root-servers.net.
.                       86336   IN      NS      d.root-servers.net.
.                       86336   IN      NS      e.root-servers.net.
.                       86336   IN      NS      f.root-servers.net.
.                       86336   IN      NS      g.root-servers.net.
.                       86336   IN      NS      h.root-servers.net.
.                       86336   IN      NS      i.root-servers.net.
.                       86336   IN      NS      j.root-servers.net.
.                       86336   IN      NS      k.root-servers.net.
.                       86336   IN      NS      l.root-servers.net.
.                       86336   IN      NS      m.root-servers.net.
.                       86336   IN      RRSIG   NS 8 0 518400 20241209050000 20241126040000 61050 . inTA2eJ+IJrDnXIEpr2+9+HHKj9+wmgepSUCaMpbuohHLbV4rAnQ5l78 GiNn1djHxbhDRgF1QgFZCUzlTxaAExGdtug4+FbHY9TiWkUJZKE/pK03 NjI9o/rjWr0ABZcuIhjpRkTEfVxYv0w639YkfXnMlrSGYNZzy9+QbAdj CNSBva6DC7acXheFMaD1T/QgSW4l8kEsU5tqyngmPUtOnZYv+VovCbmG X+vavvVLjYt/kWWqdyULJugBTd+hA771fdO2H7bJPg+6MSht417j5TKm BGd8AVCruu/mFMIb/jtUtWYFaciuh5L8zeOACPEJ9uYkkIdphN99fDsC h2RKTQ==
;; Received 525 bytes from 192.168.66.51#5335(192.168.66.51) in 0 ms

;; connection timed out; no servers could be reached

Ich habe auch bereits versucht den Verbositylevel auf die höchste Stufe zu stellen beim ausführen vom dig. Ich sehe da Errors wie folgende:

[1732562945] unbound[1:1] error: udp connect failed: Network is unreachable for 2001:503:ba3e::2:30 port 53 (len 28)
[1732562945] unbound[1:1] error: udp connect failed: Network is unreachable for 2001:7fd::1 port 53 (len 28)

Es ist jedoch für mich extrem schwierig zu sagen, ob diese überhaupt mit diesem Fehler zusammenhängen, da das Logfile geflutet wird von Logeinträgen. Ich habe auch schon probiert IPv6 zu deaktivieren mit dem config-Eintrag 'do-ip6: no'. Aber kein Erfolg.

Ich hab ehrlichgesagt grad keinen Plan mehr, wo weiterzusuchen. Hat allenfalls jemand noch eine Idee? Kann es sein dass mein ISP diese Anfragen eventuell blockiert?