Problem mit DNS Auflösung bei FritzBox seit Labor FW 7.19-77060/77061

Hallo,

ich habe folgendes Problem, die Adresse api.weather.com wird nicht aufgelöst über den Pihole obwohl diese nicht geblockt wird und selbst wenn der Pihole deaktiviert wurde. Warum auch immer, wird auch teilweise die lokale Domäne angehängt.

Apr  7 16:42:00 dnsmasq[10384]: query[A] api.weather.com from 192.168.2.3
Apr  7 16:42:00 dnsmasq[10384]: forwarded api.weather.com to fd00:::10c4
Apr  7 16:42:00 dnsmasq[10384]: query[AAAA] api.weather.com from 192.168.2.3
Apr  7 16:42:00 dnsmasq[10384]: forwarded api.weather.com to fd00:::10c4
Apr  7 16:42:00 dnsmasq[10384]: reply api.weather.com is <CNAME>
Apr  7 16:42:00 dnsmasq[10384]: reply api.weather.com.edgekey.net is <CNAME>
Apr  7 16:42:00 dnsmasq[10384]: reply e12930.ksd.akamaiedge.net is NODATA-IPv6
Apr  7 16:42:05 dnsmasq[10384]: query[A] api.weather.com from 192.168.2.3
Apr  7 16:42:05 dnsmasq[10384]: cached api.weather.com is <CNAME>
Apr  7 16:42:05 dnsmasq[10384]: cached api.weather.com.edgekey.net is <CNAME>
Apr  7 16:42:05 dnsmasq[10384]: forwarded api.weather.com to 192.168.2.1
Apr  7 16:42:05 dnsmasq[10384]: forwarded api.weather.com to fd00:::10c4

Anscheinend kommt auf den A query keine Antwort.

Ein nslookup direkt mit der fritz.box liefert aber das korrekte Ergebnis.

nslookup api.weather.com

Server:         192.168.2.1
Address:        192.168.2.1:53

Non-authoritative answer:
api.weather.com canonical name = api.weather.com.edgekey.net
api.weather.com.edgekey.net     canonical name = e12930.ksd.akamaiedge.net
Name:   e12930.ksd.akamaiedge.net
Address: 72.247.156.33

Non-authoritative answer:
api.weather.com canonical name = api.weather.com.edgekey.net
api.weather.com.edgekey.net     canonical name = e12930.ksd.akamaiedge.net

( Vorweg: Ausgaben von Kommandos oder aus Logdateien werden wie eingefügt angezeigt, wenn Du den entsprechenden Text markierst und dann aus dem Menü </> - Preformatted text wählst. Ich habe Deinen Post entsprechend überarbeitet, damit <CNAME> auch zu sehen ist :wink: )

Das hat wahrscheinlich Dein von Windows aus ausgeführtes nslookup verursacht, das eine Suche immer sowohl für den angegebenen als auch für den um die lokale Domäne erweiterten Namen durchführt.

Es kann mitunter vorkommen, dass unterschiedliche DNS-Server eine angefragte Domäne unterschiedlich beantworten, z.B. um mit der IP-Adresse des vermuteten räumlich naheliegendsten Hosts zu antworten.

Allerdings sieht es so aus, als ob Du Deine FritzBox als Upstream-DNS-Server für Pi-hole verwendest, da wäre eine Abweichung oder gar eine leere Antwort eigentlich nicht zu erwarten.

Tritt das Problem denn dauerhaft auf, oder nur sporadisch?

Im letzteren Fall könnte es sein, dass der von Dir in der FB hinterlegte DNS-Server zeitweise überlastet war und so kurzfristig Antworten schuldig geblieben ist.

Sorry der Editor war etwas ungewohnt ich gelobe Besserung :slight_smile:

Ist kein Windows ist ein Debian Buster

Dem ist so, meine FB ist im Pihole als Upstream DNS eingetragen sowohl IPv4 also auch IPv6

Nein das Problem ist seit Sonntag statisch, ist mir heute erst aufgefallen, da das Wetter in meiner Haussteuerung nicht mehr aktualisiert wird. Es tritt auch nicht nur hier auf. z.B. die Anfrage für google.de wird aufgelöst, bei www.google.de tritt das gleiche Verhalten auf. Selbst wenn ich in der Navigation auf Disable -> Permanently gehe tritt das Problem auf, trage ich im Client die FB als DNS ein tritt es nicht auf auch nicht sporadisch.

Das spricht eher dafür, dass es ein Problem mit dem Upstream-DNS gibt, entweder in der FB oder im Zusammenspiel zwischen FB und Pi-hole.

Stell doch bitte mal ein Debug Token zur Verfügung.

pihole -d

oder über die Web-Oberfläche
Tools | Generate debug log

So etwas hatte ich auch schon vermutet, daher habe ich im Pihole statt der FB die gleichen DNS Server wie in der FB (Quad9 / Cloudflare) eingetragen und damit tritt das Problem nicht auf.

Das Problem scheint bei allen Subdomains aufzutreten, z.B. play.google.com

Bis Sontag hat es aber ohne Probleme funktioniert :frowning:

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

Dein Debug Log sieht soweit ok aus: Es sind keine offensichtlichen Fehler zu erkennen.

Es gibt nur eine minimale Auffälligkeit:
Wenn Du Deine FB als einzigen Upstream-DNS für Pi-hole verwendest, kannst Du auf Conditional Forwarding verzichten, solange Du gleichzeitig Never forward reverse lookups for private IP ranges nicht anhakst (was momentan auch nicht der Fall ist).

Das sollte aber beides weder für sich noch zusammengenommen keinen Einfluss auf die Auflösung öffentlicher Namen haben.

Ich nehme an, Du hast Pi-hole in Deiner FB als lokalen DNS-Server unter Heimnetz|Netzwerk|Netzwerkeinstellungen|IPv4- bzw. IPv6-Adressen konfiguriert.

Damit würde ich konfigurationsseitig keinen Grund sehen, warum es zu Abweichungen kommen könnte.

Nimmt man dazu die Zeilen aus Deinem Log:

Apr  7 16:42:05 dnsmasq[10384]: query[A] api.weather.com from 192.168.2.3
Apr  7 16:42:05 dnsmasq[10384]: cached api.weather.com is <CNAME>
Apr  7 16:42:05 dnsmasq[10384]: cached api.weather.com.edgekey.net is <CNAME>
Apr  7 16:42:05 dnsmasq[10384]: forwarded api.weather.com to 192.168.2.1
Apr  7 16:42:05 dnsmasq[10384]: forwarded api.weather.com to fd00:::10c4

Dann sieht es ganz so aus, als hätte Pi-hole alles richtig gemacht und die Anfrage an die FB weitergeleitet - aber die Antwort der FB bleibt aus.

Wie hast Du es denn vorher geschafft, acht DNS-Server in der FB einzutragen? Verwendest Du vielleicht ein Custom-ROM?

Und hast Du sonst noch kürzlich irgendetwas in Deinem Netzwerk geändert oder neu hinzugefügt?

Korrekt der Pihole wird als DNS per DHCP verteilt. (IPv4 & IPv6 hier nicht per DHCP sondern Router Advertisement)

Im Prinzip ja, aber das erklärt nicht, warum es kein Problem gibt wenn ich die FB im Client als DNS eintrage.

Ich habe die aktuelle Labor FW auf meiner FB7590 hier wird DNSoTLS unterstützt und hier werden die DNS Server per FQDN eingetragen und dann aufgelöst.

image

Das einzige was in den letzten Tagen geändert wurde, es kam eine neue Labor FW raus, die habe ich aber bereits am Freitag installiert, aufgetreten ist das Problem aber erst am Sonntag.

Spekulativ: Freitag - wäre das nahe genug am Sonntag, um es vielleicht erst dann zu bemerken?
Um einen Fehler der Laborversion auszuschliessen, könntest Du theoretisch auf die Normalversion zurücksetzen, aber das mußt Du selbst entscheiden.

Und da mir die sinnvollen Erklärungsansätze ausgehen, ist das folgende eigentlich auch alles spekulativ: :wink:

Es gibt meines Wissens nur ein Szenario, in dem eine FB eine DNS-Antwort aktiv unterdrücken würde: Wenn der DNS-Rebind-Schutz zuschlägt.

Das würde er aber eigentlich nur, wenn ein von der FB befragter Upstream-DNS-Server in der Antwort für einen öffentlichen Hostnamen eine private IP-Adresse zurückliefern würde.
Und diese Voraussetzungen liegen bei api.weather.com und in Deiner Konfiguration alle nicht vor.

Trotzdem, da dies die einzige mir bekannte Funktion ist, die ein solches Verhalten erklären könnte, und Deine FB ja sozusagen mit einer Beta-Firmware läuft: Versuch mal, ob es etwas bringt, Pi-hole als Ausnahme vom Rebind-Schutz in der FB einzustellen.

Und eine zweite Sache könntest Du auch noch probieren:
Du verwendest derzeit die link-lokale IPv6-Adresse (fe80::) als Gateway für Pi-hole. Versuch stattdessen mal, auf die ULA-Adresse der FB umzustellen (die wird in der FB etwas versteckt unter Heimnetz|Netzwerk|Netzwerkeinstellungen|IPv6-Adressen direkt über dem ULA-Präfix angezeigt).

Da die Haussteuerung das Wetter alle 5 Minuten aktualisiert und das laut Log bis zum 05.04 12:39 funktioniert hat, eher nein.
Mir ist allerdings eingefallen, dass ich auf dem Debian Updates gemacht habe und ich hab im apt Log mal nachgesehen, ich habe am 05.04 12:37 das Paket libgnutls30 aktualisiert, dass würde von der Zeit her passen, allerdings wie sollte eine TLS Bibliothek sich auswirken?

Hier ist der Host des Pihole bereits als Ausnahme eingetragen :slight_smile:

Der Internetzugang funktioniert, da auf dem gleichen Host auch ein nginx als Reverse Proxy läuft, wäre mir das Aufgefallen wenn es hier Probleme geben würde

War ja auch nur spekulativ, wie gesagt: Wäre bei Deinem Setup (Pi-hole nicht als Upstream in der FB) nicht nötig.

Auch das war ja spekulativ: Technisch gibt es keinen Grund, warum es mit der link-lokalen Adresse nicht funktionieren sollte (solange Pi-hole direkt an der FB hängt), und Dein Debug Log bestätigt das auch als unproblematisch.
Aber vielleicht behandelt die FB-Laborversion DNS-Anfragen je nach Herkunftsadresse unterschiedlich.

Anscheinend scheiden Veränderungen in der FB aber aufgrund des Zeitpunkts aus Deinem Haussteuerung-Log ohnehin als Ursache aus.

Läßt sich das testweise rückgängig machen?

Hab den Downgrade gerade gemacht, hat aber nix gebracht.

Es liegt wohl tatsächlich an der FB, diese leitet wohl einen CNAME reply nicht mehr weiter.

nslookup api.weather.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
api.weather.com canonical name = api.weather.com.edgekey.net.
api.weather.com.edgekey.net     canonical name = e12930.ksd.akamaiedge.net.
Name:   e12930.ksd.akamaiedge.net
Address: 104.109.87.105

nslookup api.weather.com 192.168.2.1
;; connection timed out; no servers could be reached

nslookup weather.com 192.168.2.1
Server:         192.168.2.1
Address:        192.168.2.1#53

Non-authoritative answer:
Name:   weather.com
Address: 72.247.156.33

Oder doch an einem der vielen Upstream-Server.
Du siehst ja nicht direkt, welchen DNS-Server die FB ihrerseits kontaktiert.

Du könntest mit nslookup eine Auflösung über jeden einzelnen Upstream testen.
Aber das ist nicht völlg vergleichbar, wegen der Verwendung von DoT in der FB. Aus einem positiven Test könntest Du also nicht unmittelbar ableiten, dass es nicht an den Upstream-Servern liegt, da die sich über DoT anders verhalten könnten.
Ob es an DoT liegt, könntest Du zusätzlich durch Wechsel auf klassisches DNS in der FB überprüfen.

Wie bereits zuvor festgestellt, sieht das aber insgesamt nicht nach einem Pi-hole-Konfigurationsproblem aus. Pi-hole leitet die Anfrage korrekt an Deine FB weiter, diese bleibt aber die Antwort schuldig. :thinking:

Ich hätte gleich erwähnen können, dass ich das bereits getan hatte, also ich habe alle Upstream DNS Server getestet und die Antworten alle korrekt. Auch wenn man DoT komplett deaktiviert, tritt es weiter auf. Ich vermute tatsächlich einen Fehler in der FW, daher hab ich das mal gemeldet.

1 Like

Mit dieser Erkenntnis könnten wir dieses Topic dann eigentlich schliessen.

Es wäre toll, wenn Du uns hier dennoch über den Ausgang der FritzBox-Labor-Nachforschungen informieren würdest.

In diesem Zusammenhang habe ich noch eine Bitte:
Könntest Du Deinen Topic-Titel bezüglich der FB-Laborversion erweitern (also z.B. Teilweises Problem mit DNS und FritzBox Laborversion 7.xxx)?
Dies würde unseren Lesern hier eine bessere Einschätzung erlauben, ob das Thema möglicherweise für ihre eigenen Probleme (noch) relevant ist.

Werde ich natürlich machen.

Ich habe jetzt da ich auf DoT nicht verzichten wollte, unbound installiert und hier DoT konfiguriert und diesen als Upstream im Pihole eingetragen. Das Problem tritt hier nicht auf, es liegt also definitiv an der FB

Wo hast du denn diese schöne Übersicht im Menü der FB gefunden? Ich habe eine FB 7530 mit der Labor FW 7.1977.. finde dies aber nicht.

Wird unter Internet -> Online Monitor angezeigt allerdings nur in der Erweiterten Ansicht.

Super danke. Da ich kein DoT verwende ist die Liste recht kurz und ich habe sie immer übersehen.

Hallo, ich habe genau dasselbe Problem mit schlechter / fehlender Namensauflösung wie du seit dem letzten Fritz-Labor -Update auf die 7.19.77204. Habe genau dieselbe Konstellation wie du. Pi-Hole fragt Fritzbox, diese fragt DoT-Server. Kurze Zeit funktioniert es, dann geht keine Namensauflösung mehr...
Du hast deine Fritzbox zurück zur offiziellen Version geflasht und das Problem blieb dasselbe? Das wäre ja richtig Sch...!
Habe jetzt mal versuchsweise die Provider-DNS genommen, natürlich ohne DoT, und probiere damit. Bin schon reichlich genervt...
Viele Grüße pehebo

Nein, auf meiner FB läuft immer noch die Labor FW (aktuell ebenfalls 77204), die offizielle habe ich zwischenzeitlich nicht getestet, da es erst mit der 77061 auftrat und bei den vorangegangenen Versionen nicht.

Auch ich hatte ohne DoT getestet da auch ich das im Verdacht hatte, aber das Problem trat zumindest bei mir auch ohne DoT auf.

Auch an dich die Bitte, es bei avm zu melden