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?
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.
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?
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.
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
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:
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
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
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
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
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.
Ä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.
Ä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?
