SERVFAIL bei {cdn,blog}.getsol.us

Beobachtetes und erwartetes Verhalten

Hallo zusammen,

zuerst einmal bin ich neu hier, ich bitte um Nachsicht, wenn ich etwas falsch mache.

Pi Hole an sich läuft aber schon seit längerer Zeit in meinem Netzwerk, bis jetzt auch ohne offensichtliche Probleme.

Kürzlich fiel mir aber auf, dass ich folgende (Sub-)Domains zwar aus dem Mobilfunknetz, nicht aber aus meinem Heimnetz erreichen kann: {cdn,blog}getsol.us. Es handelt sich um u.a. das Software-Repository meiner u.a. genutzen Linuxdistribution Solus.

Pi Hole läuft bei mir unter einer Dietpi-Installation auf einem Raspberry Pi 3 Model B Rev 1.2 .
Ich nutze unbound und vermute hier auch das Problem.

Unter Verwendung von DNSSEC bekomme ich bei den o.g. Domains einen SERVFAIL zurück:

dietpi@Stachelbeere:~$ dig @127.0.0.1 -p 5335 cdn.getsol.us

; <<>> DiG 9.16.37-Debian <<>> @127.0.0.1 -p 5335 cdn.getsol.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61905
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cdn.getsol.us.			IN	A

;; Query time: 32 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sat May 06 13:37:08 CEST 2023
;; MSG SIZE  rcvd: 42

Ohne DNSSEC:

dietpi@Stachelbeere:~$ dig @127.0.0.1 -p 5335 cdn.getsol.us +cd

; <<>> DiG 9.16.37-Debian <<>> @127.0.0.1 -p 5335 cdn.getsol.us +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24931
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cdn.getsol.us.			IN	A

;; ANSWER SECTION:
cdn.getsol.us.		201	IN	A	104.26.14.228
cdn.getsol.us.		201	IN	A	172.67.68.235
cdn.getsol.us.		201	IN	A	104.26.15.228

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sat May 06 13:38:47 CEST 2023
;; MSG SIZE  rcvd: 90

Ich habe mich hier bereits im Forum umgeschaut, aber zu meinem konkreten Problem nichts gefunden. Mein Fehlerbild ist mit den o.g. Domains (durchgehend) reproduzierbar.

Die Logging-verbosity habe ich in /etc/unbound/unbound.conf.d/dietpi.conf auf verbosity: 2 gestellt und erhalte folgende Rückmeldung:

Mai 06 13:40:36 Stachelbeere unbound[7036]: [7036:0] info: resolving getsol.us. DNSKEY IN
Mai 06 13:40:36 Stachelbeere unbound[7036]: [7036:0] info: response for getsol.us. DNSKEY IN
Mai 06 13:40:36 Stachelbeere unbound[7036]: [7036:0] info: reply from <.> 185.95.218.43#853
Mai 06 13:40:36 Stachelbeere unbound[7036]: [7036:0] info: query response was ANSWER
Mai 06 13:40:36 Stachelbeere unbound[7036]: [7036:0] info: Did not match a DS to a DNSKEY, thus bogus.
Mai 06 13:40:36 Stachelbeere unbound[7036]: [7036:0] info: Could not establish a chain of trust to keys for getsol.us. DNSKEY IN

Leider komme ich damit dann ans Ende meines Lateins, da meine DNSSEC-Kenntnisse hier nicht weitreichend genug sind :frowning: .

Kann mir jemand weiterhelfen? Gibt es irgendwas, was ich tun kann, um den Fall zu heilen? Oder sind mir da die Hände gebunden? Vielen Dank schon mal vorab!

Die Himbeere

Debug Token:

https://tricorder.pi-hole.net/Iv6uTIWR/

Deine dig-Ergebnisse belegen (wie Du bereits selbst erkannt hast), dass Pi-hole hier nicht beteiligt ist - schließlich gehen die Anfragen direkt an unbound.

Ich kann Deine Beobachtung jedoch in meiner Pi-hole/unbound-Installation nicht nachvollziehen:

nslookup cdn.getsol.us
Server:  pi.hole
Address:  192.168.1.28

Nicht autorisierende Antwort:
Name:       cdn.getsol.us
Addresses:  2606:4700:20::ac43:44eb
            2606:4700:20::681a:ee4
            2606:4700:20::681a:fe4
            104.26.15.228
            104.26.14.228
            172.67.68.235

Allerdings verwende ich unbound in meiner Konfiguration als rekursiven Resolver, während Deine Log-Zeilen darauf hindeuten, dass Du unbound als DoT-Forwarder (Port 853) verwendest.

Die Fehlermeldung Could not establish a chain of trust to keys for getsol.us. würde nahelegen, dass etwas mit der DoT-Konfiguration des verwendeten DoT-Upstreams und/oder des autoritativen DNS-Servers für getsol.us nicht korrekt ist.

Wenn dem so wäre, könntest Du da client-seitig nichts dran ändern - hier müssten die jeweiligen DNS-Serveradministratoren tätig werden.

Mitunter treten solche Meldungen kurzzeitig bei den vorgeschriebenen periodischen Aktualisierungen der DNSSEC-Daten auf, wenn stellenweise irgendwo noch veraltetete Informationen gecached werden. Derartige Fehler sollten sich aber nach kurzer Zeit von selbst auflösen.

Bucking_Horn: Danke für deine Rückmeldung!

Ich benutze unbound in der Tat als DoT-Forwarder.

Das heißt,ich müsste mich entweder an den DNS-Admin der digitalen Gesellschaft bzw. dem Tech-C der o.g. Domäne wenden? Kann ich hierzu noch irgendwelche Infos an die Admins weitergeben bzw. den Fehler mehr einkreisen/debuggen?

Danke für deine wertvollen Hinweise!

Die Himbeere

Du könntest versuchen, unbound mal testweise auf einen anderen DoT-Upstream zu verbiegen und schauen, ob es dann ebenfalls zu SERVFAILs kommt.

Und wenn Dein Router DNS-over-TLS-Anfragen stellen kann, könntest Du auch versuchen, eine Anfrage über Deinen Router zu schicken, um einen eventuellen Fehler in unbound auszuschliessen.

Dein unbound-Log-Auszug ist ein guter Einsteig für eine Klärung.
Ich würde den mit der offfenen Frage versenden, warum die Auflösung hier permanent fehlschlägt und die Antwort als nicht vertrauenswürdig (bogus) eingestuft und verworfen wird (ohne zunächst eigene Vermutungen anzustellen).

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.