Servfail Probleme bei Google-Adressen (kein Unbound konfiguriert)

Hallo zusammen,

ich beziehe mich auf folgenden, leider bereits geschlossenen Thread:
Servfail bei (unter anderem) google.com - kein Unbound - Help / Deutschsprachige Hilfe - Pi-hole Userspace (pi-hole.net)

Die Probleme treten leider wieder verstärkt auf. Ich erreiche viele Google-Seiten nicht. Im PiHole ist immer ein "SERVFAIL" zu sehen. "google.com" ist betroffen und auf dem iPhone funktioniert auch die YouTube-App nicht, diese versucht anscheinend die Domain "youtubei.googleapis.com" ohne Erfolg aufzulösen, auch hier ein "SERVFAIL".

Folgendes habe ich nun bereits für Troubleshooting versucht:
IPv6 auf den Clients deaktiviert da meistens versucht wurde ein AAAA-Record aufzulösen. Ohne Erfolg, der A-record bekommt genauso einen "SERVFAIL":

DNS-Einstellungen auf dem Router zurückzusetzen, da ich manuelle DNS-Server (z.B. digitalcourage) konfiguriert habe und DNS over TLS aktiviert habe. Leider auch mit den Provider DNS-Servern kein Erfolg.

Testweise manuelles Ändern des DNS-Servers auf die Fritz!Box, es funktioniert sofort. Daher muss der PiHole zumindest Teil des Problems sein.

Nun ist das Problem, dass ein "dig @192.168.2.5 google.com" sowohl IPv4 als auch IPv6 anscheinend keine Probleme verursacht...

> ; <<>> DiG 9.16.10 <<>> @192.168.2.5 google.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62832
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;google.com.                    IN      A
> 
> ;; ANSWER SECTION:
> google.com.             149     IN      A       216.58.212.174
> 
> ;; Query time: 35 msec
> ;; SERVER: 192.168.2.5#53(192.168.2.5)
> ;; WHEN: Tue Dec 29 15:50:03 Mitteleuropõische Zeit 2020
> ;; MSG SIZE  rcvd: 55
> 
> ; <<>> DiG 9.16.10 <<>> @192.168.2.5 google.com AAAA
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61061
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;google.com.                    IN      AAAA
> 
> ;; ANSWER SECTION:
> google.com.             94      IN      AAAA    2a00:1450:4001:802::200e
> 
> ;; Query time: 333 msec
> ;; SERVER: 192.168.2.5#53(192.168.2.5)
> ;; WHEN: Tue Dec 29 15:50:39 Mitteleuropõische Zeit 2020
> ;; MSG SIZE  rcvd: 67

Leider weiß ich nun nicht weiter...

Raspbian sowie PiHole wurden auf den aktuellen Stand gebracht.

Debug Token: https://tricorder.pi-hole.net/x2lpmi1z13

Mit dem DNS Server von digitalcourage hatte ich oft Probleme darum bin ich derzeit bei Google. Habe die Fritzbox 7590

Wie gesagt hab ich mit den Provider-DNS Servern (Telekom) leider die gleichen Probleme. :pensive:

Ich hole das ganze nochmal hoch, da ich leider weiterhin starke Probleme mit PiHole habe. So schlimm, dass ich aktuell ohne arbeiten muss. Leider bekomme ich weiterhin zig "SERVFAIL" oder "N/A" Meldungen:


Leider kommen die Meldungen einfach random. Google funktioniert aktuell z.B.. Dafür macht O365 Probleme.

DNS-Server auf der Fritz!Box wurden auf Standard gestellt (also Provider-DNS). Pi-Hole ist aktuell und System auch, gebootet wurde auch einmal. Ich weiß nun echt nicht mehr weiter...

Debug-Token: https://tricorder.pi-hole.net/ke0iggqv2u

Your Pi-hole is using the router as the upstream DNS resolver. Change this to a third party DNS server and see if the problem resolves.

*** [ DIAGNOSING ]: Setup variables
    DNSMASQ_LISTENING=single
    DNS_FQDN_REQUIRED=true
    DNS_BOGUS_PRIV=false
    DNSSEC=false
    REV_SERVER=true
    REV_SERVER_DOMAIN=fritz.box
    REV_SERVER_TARGET=192.168.2.1
    REV_SERVER_CIDR=192.168.2.0/24
    BLOCKING_ENABLED=true
    PIHOLE_INTERFACE=eth0
    IPV4_ADDRESS=192.168.2.5/24
    ...
    PIHOLE_DNS_1=192.168.2.1#53
    ....

Hi, that is an intended setting. I want my router to make the DNS requests since I want to have the device names in the network overview of my router, using "*.local" names and want to use DNS-over-TLS. Is that not a recommended setting?
As mentioned: I do not have any problems when using my router as the DNS-forwarder. Works instantly.

@jfb Okay since this seems to not work stable I configured unbound which is asking the root DNS servers. Only change I did is to enable and prefer IPv6. Seems to work now, even with IPv6.

Why isn't this working correctly with my router as an upstream DNS server? Sometimes it works, sometimes not. This was running fine for a year or so.

Since I can't use DNS over TLS with them I, do I have any disadvantages in terms of security now? That shouldn't be the case because I am asking the root servers directly, without any other 3rd party DNS server, right?

No less security, and you have gained privacy since no upstream DNS server has your DNS history.

SERVFAIL-Fehler können auf einer ganzen Reihe von Ursachen beruhen, was die Fehlersuche erschwert. Man kann daraus unmittelbar nur schliessen, dass irgendeiner der befragten Server einen Fehler gemeldet hat.

Eventuell lassen sich weitere Details herausfinden, wenn Du die fehlerhafte Domäne über einen öffentlichen DNS-Server anfragst, also z.B.:

dig @1.1.1.1 www.apple.com

Wenn das ebenfalls zu einem SERVFAIL führt, lässt sich aus der Antwort vielleicht ein Grund ableiten.
Beispielsweise würde im folgenden Abschnitt:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 06 ("..")
;; QUESTION SECTION:

die 06 in der Zeile OPT nach RFC 8914 bedeuten, dass eine DNSSEC-Validierung mit DNSSEC Bogus fehlschlug. Weitere Fehlercodes finden sich im RFC. Neuere Versionen von dig werfen ggf. direkt einen Fehlertext aus.

Wenn über den öffentlichen Server kein SERVFAIL zurückkommt, liegt die Vermutung nahe, dass es sich nur um einen temporären Fehler gehandelt hat, oder dass die FB als Pi-holes Upstream diesen Fehler selbst erzeugt.

Da unbound die für die jeweiligen Domänen zuständigen autoritativen DNS-Server direkt befragt, eliminiert der Einsatz von unbound zwei mögliche Fehlerquellen oder besser Fehlerentstehungsorte:
Zum einen die Fritzbox, und zum anderen die von der Fritzbox beauskunfteten DNS-Server und ggf. dahinterliegende weitere rekursive Resolver.

Generell kann ein SERVFAIL aber auch mit unbound durchaus auftreten (von einem befragten DNS-Server gemeldet werden).


DNS-over-TLS schützt den DNS-Verkehr, indem es diesen verschlüsselt.
Während des Transports wird das Mithören durch Dritte damit erheblich erschwert. Auf dem DoT-DNS-Server liegt aber trotzdem Deine kompletten DNS-Historie vor, da Anfragen dort natürlich wieder entschlüsselt werden. Die DNS-Historie wird dabei regelmässig monetarisiert.

Bei Verwendung von unbound erhält kein einzelner DNS-Server mehr Deine Historie, da immer die zuständigen DNS-Server direkt befragt werden.
Darüber hinaus valiidert unbound (in der von Pi-hole empfohlenen Konfiguration) über DNSSEC (sofern von den befragten Servern unterstützt), ob die DNS-Antworten ggf. manipliert wurden. Mit DoT oder DoH alleine wird diese Validierung nicht abgedeckt.

unbound bietet also einen Gewinn an Privatheit/Datenschutz und eine andere Qualität von Sicherheit gegenüber der Verwendung von DoT in der FB.

Im privaten Heimnetz ist das eine Frage der persönlichen Präferenz.
Die meisten Privatanwender müssen dabei nicht annehmen, dass jemand ihre Leitung abhört und DNS-Anfragen mitliest. Man kann jedoch fast sicher davon ausgehen, dass die eigene DNS-Historie vermarktet wird.

Mit einem Laptop in einem öffentlichen WLAN im Cafe würde ich DoT bevorzugen, dann aber bereits für die Verbindung zwischen Laptop und Router. Für einen solchen Einsatzzweck wäre allerdings prinzipiell eine VPN-Verbindung die bessere Wahl.

2 Likes

Also ich kann ähnliches berichten. Die google.com-Domains werden nicht aufgelöst. Ansonsten funktioniert alles so weit ich sehe.

Hier meine Config:

Pi-Hole im Docker-Container auf einer DS720+.
Router: FB 7590
Provider: 1&1
Upstream DNS-Server im Pi-Hole: Fritzbox
DNS in der FB: vom Provider zugewiesene
kein DoT, kein DNSSEC, kein DoH, kein Unbound, kein Stubby (zumindest nicht mehr)
in Pi-Hole "conditional Forwarding" eingetragen
IPV4+IPV6

Wenn ich nun im Pi-Hole andere DNS-Server eingebe, läuft's sofort.

Wenn ich die FB nach google.com frage (nslookup - 192.168.178.1) kommt schön brav die richtig Antwort. Pi-Hole löst mit NICHT-FB-DNS-Server google.com ordentlich auf. Nur in der Config, dass der Client Pi-Hole fragt und dieser die FB und die FB den DNS des Providers... läuft's nicht.

Deshalb gehe ich auch davon aus, dass Pi-Hole zumindest ein Teil des Problems ist.

Jemand eine Idee wie man die nicht funktionieren Config wieder aus Laufen bekommt? Es muss schließlich gehen, auch wenn es einen Workarround gibt.

Ja ich würde auch gerne wissen woran das genau liegt. Vor allem weil es total sporadisch auftritt. Auf einmal geht es dann wieder bis es nach ein paar Wochen wieder nicht geht. Ich bin mit unbound zufrieden, damit scheint es nun stabil zu laufen.

Ich hatte früher auch Stubby laufen. Da gab's auch keine Probleme. Jetzt bin ich aber von einem RPi auf einen Dockercontainer auf der Diskstation umgezogen. Und da die Fritzbox mittlerweile DoT unterstützt, habe ich auf den Stubby verzichtet. Das reicht mir an Privacy.

Komisch, dass sich hier nicht mehr Leute mit diesem Problem melden... Eine Lösung scheint es ja auch noch nicht zu geben. Es wäre schon gut, wenn sich die Entwickler mal die Sache ansehen könnten... :slight_smile:

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