Ausfälle seit der aktuellen Version v5.12 / v5.17

[THG]

Hallo,

seit dem letzte Update auf v5.12 / v5.17 habe ich deutlich Problem mit der Zuverlässigkeit. Es ist jetzt schon mehrfach passiert, dass User keinen Zugriff mehr wegen fehlender DNS Auflösung haben.

Das Verhalten ist mir völlig fremd.

Woran kann das in der aktuellen Version liegen?

Nach einem Neustart meines RPI4 läuft es dann wieder, bis das Problem wieder auftritt.

[Blackbrook]

Nutzt du unbound?

Was spucken folgende Befehle aus:

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335

Ich sehe SERVFAIL in den Replies und meine mich erinnern zu können das da was mit der AUthentifizierung nicht passt - sorry, bin kein Experte. Ich habe bei mir Probleme mit der Zeitdifferenz gehabt. Nach einem Reboot oder längerer Downtime (Urlaub) hatte der Pi eine stark abweichende Uhrzeit, was dazu geführt hat, dass die Zertifikate von der Gegenseite abgelehnt wurde. Abhilfe schaffte ein RTC Modul. Kann sein, dass bei dir nach dem Neustart es einige Zeit braucht und dann die Zeit synchronisiert wird, welche vielleicht auf eine andere Zeitzone gesetzt ist?!

[THG]

Ja ich nutze unbound.

pi@rpi-pihole:~ $ dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335

; <<>> DiG 9.16.27-Raspbian <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60498
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.	IN	A

;; Query time: 389 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sat Sep 10 10:00:25 CEST 2022
;; MSG SIZE  rcvd: 57


; <<>> DiG 9.16.27-Raspbian <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48501
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.	IN	A

;; ANSWER SECTION:
sigok.verteiltesysteme.net. 60	IN	A	134.91.78.139

;; Query time: 39 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sat Sep 10 10:00:25 CEST 2022
;; MSG SIZE  rcvd: 71

pi@rpi-pihole:~ $ 

[Blackbrook]

das sieht aus wie es soll ... Zeit passt?

https://docs.pi-hole.net/guides/dns/unbound/#test-validation

[THG]

Uhrzeit stimmt

[jfb]

@Blackbrook

I see SERVFAIL in the replies

You see BOGUS in the replies, which means that unbound was not able to authenticate that the domain is valid. There is a certificate for the domain, but it did not authenticate.

[Blackbrook]

For me to learn from this: what is the difference between SERVFAIL reply and BOGUS status?

@THG: laut @jfb ist das ein Zertifikats Problem, unbound konnte die Domain nicht validieren bzw. (meine Interpretation) hat unbound das invalide Zertifikat abgelehnt. Bringt dich das weiter?

[Blackbrook]

@THG vielleicht hilft ein Update der CA Zertifikate?

https://manpages.debian.org/jessie/ca-certificates/update-ca-certificates.8.en.html

via SSH auf den Pi (oder dort wo pi-hole läuft) und dann update-ca-certificates

[yubiuser]

@Blackbrook

For me to learn from this: what is the difference between SERVFAIL reply and BOGUS status?

How do I interperet the DNSSEC column in the query log?

As of Pi-hole 3.3, you can see the DNSSEC status in the query log. [40] SECURE are records that have been signed and verified to be unchanged from the authoritative DNS server INSECURE are records that either have no signature or DNSSEC is not implemented for the domain; either the domain is unsigned and not implementing DNSSEC or there are other issues BOGUS are records that have been signed but have changed or been altered from the authoritative DNS server You will see INSECURE, but th…

More in depth:

https://pi-hole.net/blog/2021/12/12/understanding-dnssec-validation-using-pi-holes-query-log/

[THG]

@Blackbrook

Danke für die Antworten aber warum passiert das aus heiterem Himmel und nach einem Neustart ist dann alles wieder ok. Wenn ein Zertifikat ungültig ist, ist es doch nach einem Neustart immer noch ungültig.

Zur Info:

pi@rpi-pihole:~ $ update-ca-certificates
Updating certificates in /etc/ssl/certs...
rm: cannot remove 'ca-certificates.crt': Permission denied

[Bucking_Horn]

Ohne Kenntnis der angefragten Domänen (im Bildschirmfoto geschwärzt) wird sich das nicht klären lassen.

Eine mögliche Erklärung:
DNSSEC-Datensätze müssen regelmässig durch den Betreiber des entsprechenden autoritativen DNS-Servers aktualisiert und neu signiert werden. Sollte hierbei ein Fehler passieren, wird die DNSSEC-Validierung durch Pi-hole fehlschlagen und als BOGUS gemeldet.
In der Regel wird das durch den DNS-Server-Betreiber umgehend korrigiert. Nach erfolgter Korrektur sollte die Auflösung i.d.R wieder funktionieren, spätestens nach Ablauf der TTL.

Eine andere Erklärung wäre, dass die DNS-Antworten manipuliert wurden und daher die DNSSEC-Validierung mit BOGUS fehlschlagen muss.

[THG]

@Bucking_Horn

Wenn die Probleme auftreten sind es sehr viele unterschiedliche Domänen die betroffen sind und nicht nur wenige, darunter viele namhafte Domänen.

Die Wahrscheinlichkeit das alle diese Domänen nicht richtig durch die Betreiber aktualisiert werden, kann man denke ich ausschließen.

Des Weiteren gab es diese Ausfälle kein einziges mal mit den Versionen vor dieser aktuellen Version.

Ich als User würde da mehr den Rückschluss ziehen, dass am Pihole etwas dieses Verhalten auslöst.

[Blackbrook]

Vielleicht hilft der Upload eines Debug Token den Entwicklern? pihole -d

Du wirst im Prozess gefragt, ob du die Ergebnisse hochladen möchtest. Wenn du das machst, taucht am Ende dann ein Link auf, den hier posten. Dann können die sich das anschauen und sehen mehr.

[THG]

Das werde ich machen, wenn das Problem wieder da ist.

[Bucking_Horn]

@THG

Ich als User würde da mehr den Rückschluss ziehen, dass am Pihole etwas dieses Verhalten auslöst.

Eher nicht:

@THG

Woran kann das in der aktuellen Version liegen?

Dein Bildschirmfoto zeigt eindeutig, dass das an unbound liegt - als der verwendete Upstream-DNS lehnt localhost#5335 die DNS-Anfragen ab (refused upstream).

Um das Problem weiter einzugrenzen, könntest Du Validierungsfehler in unbound loggen.

Falls Du unbound nach unserem Guide eingerichtet hast, änderst Du dazu den Anfang von /etc/unbound/unbound.conf.d/pi-hole.conf (s.a. Add logging to unbound):

server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound/unbound.log"
    verbosity: 0
    val-log-level: 2

unbound erzeugt dann nach einem Neustart bei fehlgeschlagenen Validierungen Einträge wie diese:

[1662926622] unbound[30530:0] info: validation failure <sigfail.verteiltesysteme.net. A IN>: signature crypto failed from 134.91.78.141

@THG

Wenn die Probleme auftreten sind es sehr viele unterschiedliche Domänen die betroffen sind und nicht nur wenige, darunter viele namhafte Domänen.

Wenn tatsächlich alle Domänen betroffen sein sollten, könnte das -wie bereits von anderen erwähnt- auf eine falsche Zeiteinstellung auf dem RPi hindeuten. Mit einer inkorrekten Zeitbasis würden alle DNSSEC-Validierungen fehlschlagen, und zwar bereits bei der Validierung in unbound'.

Die von Dir durchgeführte Überprüfung der Zeit auf Deinem Pi-hole-Host scheint in einen Zeitraum zu fallen, in dem auch die testweisen dig-Kommandos wieder sauber durchgelaufen sind.

Kannst Du Dich erinnern, wie es mit der Zeit bei Auftreten der Störung aussah?
Es wäre auf jeden Fall sinnvoll, das dann unmittelbar zu prüfen.

Auf welcher Hardware läuft Pi-hole bei Dir?

Du könntest außerdem prüfen, ob die involvierten autoritativen DNS-Server zum Zeitpunkt des Ausfalls ggf. gestört waren.

[THG]

Danke @Bucking_Horn

Pihole läuft auf einem RPi4

Es wäre grundsätzlich schön, wenn man das Datum aber besonders die Uhrzeit im Status des Pihole sehen könnte, denn damit wäre eine sofortige Abweichung sichtbar.

Ich werde beim nächsten Auftreten mehr dokumentieren-

[yubiuser]

@THG

Es wäre grundsätzlich schön, wenn man das Datum aber besonders die Uhrzeit im Status des Pihole sehen könnte, denn damit wäre eine sofortige Abweichung sichtbar.

Im Query Log werden alle Queries mit Zeitstempel erfasst.