SERVFAIL Probleme mit Pi-Hole + Unbound + Hyperlocal an FreshTomato WRT + NordVPN

Hallo zusammen,

ich betreibe mein pi-hole auf einem Raspberyy Pi 3B+. Ich habe mich an diese Anleitung gehalten, um pi-hole, unbound und hyperlocal einzurichten.

Mein Router läuft auf FreshTomato WRT. Dort habe ich NordVPN eingerichtet, um alle meine Geräte über VPN laufen zu lassen. Das pi-hole ist als einziger DNS konfiguriert (via Dnsmasq) und funktioniert auch soweit in Verbindung mit dem VPN.

Mein Problem: Ich bekomme immer wieder "Server not found" im Firefox bzw. SERVFAIL im pi-hole log bei Websites, die eigentlich zugänglich sein sollten. Das wird häufiger, wenn der Raspberry Pi eine Weile gelaufen ist. Ein Reboot des Pi behebt die Problematik kurzzeitig. Da ich mich mit Netzwerkthemen nicht sonderlich gut auskenne weiß ich nicht so richtig, wo ich anfangen soll, nach der Lösung für das Problem zu suchen. Kann mir jemand Starthilfe geben?

Danke!

SERVFAIL-Probleme treten in Zusammenhang mit unbound und DNSSEC öfter auf, wenn die Uhrzeit auf dem RPi nicht stimmt.

Kontrollier mal Uhrzeit (timedatectl) und Zeitzone (sudo raspi-config) auf Deinem RPi und pass diese an.

Danke für den Tipp, das scheint mir hier aber (leider) nicht das Problem zu sein.
Bildschirmfoto 2020-08-02 um 10.35.25

Ich fürchte, abgesehen von zeitlichen Abweichungen, trägt Deine Pi-Hole-Maschine nicht viel zu einem SERVFAIL bei. Ein solcher Status zeigt ganz allgemein an, dass auf der Serverseite während einer versuchten Domänen-Auflösung etwas schief gelaufen ist.

Dies kann in unbound, aber auch in jedem anderen während der Rekursion kontaktierten DNS-Server passiert sein. Es kann ein Hinweis auf eine Fehlkonfiguration bei einem autoritativen DNS-Server sein, oder eine Firewall oder Weiterleitungsregel auf dem Weg kann Low-Source-Ports blockieren, usw...
Pi-hole hat auf all dies keinen Einfluss, es bekommt nur den Fehler mitgeteilt.

Wenn SERVFAIL nur begrenzt und immer wieder für genau dieselben angefragten, wenigen Domänen auftritt, handelt es sich wahrscheinlich tatsächlich um einen server-seitigen Konfigurationsfehler für diese Domänen.
In diesem Fall könnte man durch passendes Anlegen von Local DNS records einen temporären Workaround einrichten. Temporär, weil man so natürlich nicht mehr mitbekommt, wenn sich die IP-Adresse für einen Hostnamen ändern sollte. Als dauerhafte Lösung und für mehr als ein, zwei Domänen taugt das also nicht.

Das Problem tritt scheinbar zufällig auf, auch Domains, die vorher problemlos funktioniert haben, können plötzlich für die nächsten 20 Minuten "gesperrt" sein (also SERVFAIL liefern). Und scheinbar auch relativ wahllos, also nicht begrenzt.

Wenn du schreibst, dass pi-hole nicht die Ursache des Problems ist, meinst du damit, ich sollte mich besser an ein anderes Forum wenden? Ich hatte gehofft, dass hier auch einiges Wissen über Unbound und Hyperlocal vorhanden ist und mir vielleicht trotzdem jemand weiterhelfen kann...

Wenn ich es richitg verstanden habe müsste ich der DNS-Anfrage durch das System folgen und schauen, an welcher Stelle es zum SERVFAIL kommt? Wie und in welcher Reihenfolge schaue ich da aber was an?

Nein, soweit sind wir noch nicht ganz, und das hätte ich Dir dann direkt empfohlen. :wink:

Dass SERVFAIL bei Dir nicht nur für einzelne Domänen, sondern eher zufällig auftritt, macht die Eingrenzung allerdings nicht einfacher.

Mir fallen zwei unbound-Einstellungen ein, die bei der Rekursion zu Problemen führen könnten: Strikte QNAME-Minimierung (zwar wünschenswert, wird aber längst nicht von allen DNS-Servern unterstützt) und 0x20-Kodierung (experimentell).

Da Du eventuell nicht mit der Konfiguration aus Pi-holes unbound-Guide gearbeitet hast:
Verwendest Du qname-minimisation-strict oder use-caps-for-id in Deiner unbound-Konfiguration?

1 Like

Entferne testweise auf der DNS-Seite die lokale IP von Unbound und aktiviere dafür irgendeinen der direkt von Pi-hole unterstützen DNS Server. Nur um zu sehen, ob es etwas mit Unbound zu tun hat.

1 Like

Verwendest Du qname-minimisation-strict oder use-caps-for-id in Deiner unbound -Konfiguration?

Ich gebe zu, ich habe mich nicht strikt an die Anweisungen des kuketz-Forums gehalten, sondern habe auf die aktuelle Unbound-Anleitung zurückgegriffen. Hier meine Konfiguration für die von dir genannten Variablen:

@ /etc/unbound/unbound.conf.d/pi-hole.conf
use-caps-for-id: no

@ /etc/unbound/unbound.conf.d/qname-minimisation.conf
qname-minimisation: yes

Entferne testweise auf der DNS-Seite die lokale IP von Unbound und aktiviere dafür irgendeinen der direkt von Pi-hole unterstützen DNS Server.

Das kann ich auf jeden Fall die kommenden Tage ausprobieren, danke für den Tipp!

Sieht ok aus: 0x20-Kodierung ist abgeschaltet, und strikte QNAME-Minimierung ist vermutlich aus.
(Du hast qname-minimisation-strict nicht gepostet, daher nehme ich an, dass es diesen Wert bei Dir nicht gibt, so dass der Vorgabewert gelten würde).

Falls Du das noch nicht getan hast, könntest Du noch versuchen, die root.hints zu aktualisieren.

Und im Falle eines neuerlichen SERVFAIL könntest Du für die fehlgeschlagene Domäne direkt prüfen, wie sich ein öffentlicher Server im Vergleich dazu verhält bzw. ob eine Auflösung über einen öffentlichen Server funktioniert:

dig @127.0.0.1 -p 5335 pi-hole.net 
dig @9.9.9.9 pi-hole.net

Dabei ist natürlich pi-hole.net durch Deine SERVFAIL-Domäne zu ersetzen.

Du hast qname-minimisation-strict nicht gepostet, daher nehme ich an, dass es diesen Wert bei Dir nicht gibt, so dass der Vorgabewert gelten würde

Genau, ich konnte ihn mit grep unterhalb von /etc/unbound/unbound.conf.d nicht finden.

Die root.hints sind (und waren) aktuell (Stand vom 16.07., 20:33).

Danke für den Vorschlag mit dem Vergleich via dig, das werde ich als nächstes testen.

Entferne testweise auf der DNS-Seite die lokale IP von Unbound und aktiviere dafür irgendeinen der direkt von Pi-hole unterstützen DNS Server.

UPDATE: Soweit ich bisher sehen kann funktioniert alles problemlos, wenn Unbound nicht aktiviert ist. Es scheint also an Unbound / Hyperlocal zu liegen.

Es liegt vielleicht an der Verwendung von unbound, aber nicht zwingend an unbound selbst.
Eine rekursive Auflösung ist etwas anderes als die Abfrage an einen öffentlichen DNS-Server. Letzterer kann eine Antwort z.B. auch dann aus seinem Cache ausliefern, wenn der autoritative DNS-Server (kurzzeitig) ausgefallen ist.
Wenn unbound diesen direkt befragt, erhält es bei Nicht-Verfügbarkeit natürlich auch keine Antwort.

Das sehe ich ein, aber dann müsste die Problematik so oder ähnlich ja bei den meisten Nutzern auftreten? In meinem Fall handelt es sich zumindest nicht um eine Seltenheit, sondern um ein relativ ärgerliches Dauerproblem. Und da das hoffentlich nicht der Fall ist, hoffe ich auf ein lösbares Problem in meiner Konfiguration :slight_smile:

So, ich hatte das Problem gerade mit support.apple.com.

pi@raspberrypi:~ $ dig @127.0.0.1 -p 5335 support.apple.com

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> @127.0.0.1 -p 5335 support.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18723
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;support.apple.com.		IN	A

;; Query time: 2 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Aug 03 11:28:33 CEST 2020
;; MSG SIZE  rcvd: 46
pi@raspberrypi:~ $ dig @103.86.96.100 support.apple.com

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> @103.86.96.100 support.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37618
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;support.apple.com.		IN	A

;; ANSWER SECTION:
support.apple.com.	300	IN	CNAME	prod-support.apple-support.akadns.net.
prod-support.apple-support.akadns.net. 300 IN CNAME support-china.apple-support.akadns.net.
support-china.apple-support.akadns.net.	3600 IN	CNAME support.apple.com.edgekey.net.
support.apple.com.edgekey.net. 3600 IN	CNAME	e2063.e9.akamaiedge.net.
e2063.e9.akamaiedge.net. 20	IN	A	2.21.58.137

;; AUTHORITY SECTION:
net.			3196	IN	NS	b.gtld-servers.net.
net.			3196	IN	NS	j.gtld-servers.net.
net.			3196	IN	NS	l.gtld-servers.net.
net.			3196	IN	NS	i.gtld-servers.net.
net.			3196	IN	NS	e.gtld-servers.net.
net.			3196	IN	NS	f.gtld-servers.net.
net.			3196	IN	NS	d.gtld-servers.net.
net.			3196	IN	NS	k.gtld-servers.net.
net.			3196	IN	NS	h.gtld-servers.net.
net.			3196	IN	NS	m.gtld-servers.net.
net.			3196	IN	NS	g.gtld-servers.net.
net.			3196	IN	NS	c.gtld-servers.net.
net.			3196	IN	NS	a.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.	3245	IN	A	192.5.6.30
a.gtld-servers.net.	3245	IN	AAAA	2001:503:a83e::2:30
b.gtld-servers.net.	3245	IN	A	192.33.14.30
b.gtld-servers.net.	3245	IN	AAAA	2001:503:231d::2:30
c.gtld-servers.net.	3245	IN	A	192.26.92.30
c.gtld-servers.net.	3245	IN	AAAA	2001:503:83eb::30
d.gtld-servers.net.	3245	IN	A	192.31.80.30
d.gtld-servers.net.	3245	IN	AAAA	2001:500:856e::30
e.gtld-servers.net.	3245	IN	A	192.12.94.30
e.gtld-servers.net.	3245	IN	AAAA	2001:502:1ca1::30
f.gtld-servers.net.	3245	IN	A	192.35.51.30
f.gtld-servers.net.	3245	IN	AAAA	2001:503:d414::30
g.gtld-servers.net.	3245	IN	A	192.42.93.30
g.gtld-servers.net.	3245	IN	AAAA	2001:503:eea3::30
h.gtld-servers.net.	3245	IN	A	192.54.112.30
h.gtld-servers.net.	3245	IN	AAAA	2001:502:8cc::30
i.gtld-servers.net.	3245	IN	A	192.43.172.30
i.gtld-servers.net.	3245	IN	AAAA	2001:503:39c1::30
j.gtld-servers.net.	3245	IN	A	192.48.79.30
j.gtld-servers.net.	3245	IN	AAAA	2001:502:7094::30
k.gtld-servers.net.	3245	IN	A	192.52.178.30
k.gtld-servers.net.	3245	IN	AAAA	2001:503:d2d::30
l.gtld-servers.net.	3245	IN	A	192.41.162.30
l.gtld-servers.net.	3245	IN	AAAA	2001:500:d937::30
m.gtld-servers.net.	3245	IN	A	192.55.83.30
m.gtld-servers.net.	3245	IN	AAAA	2001:501:b1f9::30

;; Query time: 82 msec
;; SERVER: 103.86.96.100#53(103.86.96.100)
;; WHEN: Mon Aug 03 11:28:55 CEST 2020
;; MSG SIZE  rcvd: 1008

EDIT: In diesem Fall war support.apple.com nach 7 Minuten wieder auflösbar:

pi@raspberrypi:~ $ dig @127.0.0.1 -p 5335 support.apple.com

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> @127.0.0.1 -p 5335 support.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1242
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;support.apple.com.		IN	A

;; ANSWER SECTION:
support.apple.com.	268	IN	CNAME	prod-support.apple-support.akadns.net.
prod-support.apple-support.akadns.net. 268 IN CNAME support-china.apple-support.akadns.net.
support-china.apple-support.akadns.net.	3020 IN	CNAME support.apple.com.edgekey.net.
support.apple.com.edgekey.net. 3020 IN	CNAME	e2063.e9.akamaiedge.net.
e2063.e9.akamaiedge.net. 20	IN	A	2.21.58.137

;; Query time: 15 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Aug 03 11:38:35 CEST 2020
;; MSG SIZE  rcvd: 215

Hoffentlich! Die Chancen dafür werden allerdings kleiner, nachdem wir die üblichen Verdächtigen bereits ausgeräumt haben. :thinking:

Gibt über mein unbound keine Probleme:

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> @127.0.0.1 -p 5335 support.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18487
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;support.apple.com.             IN      A

;; ANSWER SECTION:
support.apple.com.      300     IN      CNAME   prod-support.apple-support.akadns.net.
prod-support.apple-support.akadns.net. 300 IN CNAME support-china.apple-support.akadns.net.
support-china.apple-support.akadns.net. 3600 IN CNAME support.apple.com.edgekey.net.
support.apple.com.edgekey.net. 21600 IN CNAME   e2063.e9.akamaiedge.net.
e2063.e9.akamaiedge.net. 20     IN      A       23.203.81.34

;; Query time: 361 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Aug 03 11:33:34 CEST 2020
;; MSG SIZE  rcvd: 215

Ich denke auch, dass das nicht auf alle unbounds zu verallgemeinern ist. Wie bereits erwähnt, es tritt bei mir nicht nach einem klaren Muster auf und löst sich nach (im Normalfall) 10-30 Minuten von selbst. Aber jedesmal Abwarten und Tee trinken ist leider auch keine Lösung :neutral_face:

EDIT: Jetzt mit www.amazon.de:

pi@raspberrypi:~ $ dig @127.0.0.1 -p 5335 www.amazon.de

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> @127.0.0.1 -p 5335 www.amazon.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39692
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.amazon.de.			IN	A

;; Query time: 3 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Aug 03 11:45:13 CEST 2020
;; MSG SIZE  rcvd: 42

EDIT 2: Jetzt wieder OK (Nach 4 Minuten):

pi@raspberrypi:~ $ dig @127.0.0.1 -p 5335 www.amazon.de

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> @127.0.0.1 -p 5335 www.amazon.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4945
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.amazon.de.			IN	A

;; ANSWER SECTION:
www.amazon.de.		300	IN	A	185.102.219.175

;; Query time: 600 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Aug 03 11:49:00 CEST 2020
;; MSG SIZE  rcvd: 58

Wird ebenfalls ohne Probleme bei mir aufgelöst.
Ich verwende unbound in exakt der im Guide vorgeschlagenen Konfiguration.

Bei der Rekursion kann die gesamte einbezogene Infrastruktur eine Rolle spielen. Auf die genaue server-seitige Auflösung haben wir beide keinen direkten Einfluss. Im Unterschied zu Dir verwende ich jedoch kein VPN.

Um zu sehen, ob das einen Unterschied macht:
Hast Du die Möglichkeit, den unbound-Verkehr über das normale Netz auszuleiten?

Ich hab das nochmal überprüft. Bei mir fehlte in /etc/unbound/unbound.conf.d/pi-hole.conf:

    # 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

Ich habe das hinzugefügt und unbound neu gestartet (sudo systemctl restart unbound). Wobei ich vermute, dass das keinen Einfluss hat, da ip6 sowieso deaktiviert war:

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

Ansonsten ist auch meine Konfiguration 1:1 aus dem Guide.

Ich habe daraufhin erneut einige SERVFAILs festgestellt, das Problem löste sich diesmal allerdings jedesmal schon nach etwa einer Minute. Wenn es dabei bleibt kann ich damit leben :wink:

Insgesamt läuft momentan alles ziemlich rund muss ich zugeben. Ich verdächtige aber noch den rebound-Neustart nach der Änderung der config. Ich schätze, dass das Problem spätestens heute abend wieder da ist. Ich melde mich aber auf jeden Fall wieder mit einem Update.

Nach ein paar Stunden waren die Probleme wieder da. Dauer bis zur Verfügbarkeit bei einer Beispiel-URL: 13 Minuten. Bei anderen URLs ähnlich.

Auch vorher häufig benutzte URLs (z.B. YouTube) fallen plötzlich aus und brauchen dann eine Viertelstunde, um sich zu "erholen".

Womit könnte ich es als nächstes versuchen?

EDIT:

Hast Du die Möglichkeit, den unbound -Verkehr über das normale Netz auszuleiten?

Hmm, ich kann meine VPN-Einstellungen wieder aus dem Router entfernen, aber das möchte ich eigentlich nur ungern tun :confused:

Ändert sich etwas, wenn du in der /etc/unbound/unbound.conf.d/pi-hole.conf die Zeile
cache-min-ttl: 3600 deaktivierst und einen Neustart von Unbound durchführst?

Eine persönliche Anmerkung zum Script /usr/local/bin/updatechecklocalroot aus dem von dir genannten Guide: Overkill, Spielerei und in Teilen auch unnötig.

Vielen Dank erst einmal für deine Hilfe!

Ändert sich etwas, wenn du in der /etc/unbound/unbound.conf.d/pi-hole.conf die Zeile
cache-min-ttl: 3600 deaktivierst und einen Neustart von Unbound durchführst?

Da ich mich, was die unbound-config angeht, am Original-Guide orientiert habe, sind cache-min-ttl und cache-max-ttl bereits auskommentiert. Wäre es dann sinnvoll, diese zu aktivieren?

Eine persönliche Anmerkung zum Script /usr/local/bin/updatechecklocalroot aus dem von dir genannten Guide: Overkill, Spielerei und in Teilen auch unnötig.

Okay, das kann ich nur schwer beurteilen... denkst du denn, es könnte ein Problem darstellen?