[Info] Achtung fritz.box wird extern (z.B. per Google DNS) FALSCH ausgelöst

Roboto

Neuer User
Mitglied seit
15 Nov 2008
Beiträge
166
Punkte für Reaktionen
60
Punkte
28
und zeigt auf eine NFT gallery Seite. Das dürfe vor allem Leute betreffen die in Ihrem Browser nicht die Fritte selbst sondern einen anderen DNS (z.b. DOH DNS) eingerichtet haben betreffen.

Siehe auch
 
@KunterBunter
Stimmt. nur lesen ggf. viele einen Thread mit einem Titel "Zugriff auf FBF 6660 nicht mehr möglich: Zertifikatsproblem" nicht, da man es u.U. für ein bestimmtes Problem einer Cable Box hält (und man ggf. gar keine Cable Box hat) und daher nicht wissen kann das es sich ein generelles sicherheitsrelevantes Problem handelt, dass alle Fritzboxen betrifft. Ging mir zumindest so.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: voipivo und Grisu_
Deshalb darf dein Thread auch bleiben, während folgende zugemacht oder sogar gelöscht wurden.
 
  • Like
Reaktionen: Roboto
Moin


Rich (BBCode):
# ntpdate fritz.box
18 Feb 15:13:12 ntpdate[4240]: step time server 192.168.188.1 offset 152813420.914816 sec
Ich muss ab und zu mal einen Laptop in die aktuelle Raumzeit zwingen, und dann würde mir das auch sehr schnell auffallen.
Ich lass die FRITZ!Box per DoT über
anycast.uncensoreddns.org
unicast.uncensoreddns.org
auflösen...
Rich (BBCode):
Genutzte DNS-Server
82.144.41.8
82.145.9.8
89.233.43.71 (DoT verschlüsselt)
91.239.100.100 (DoT verschlüsselt)
2001:1438:2:3::8
2001:1438:2:4::8
2a01:3a0:53:53:: (aktuell genutzt für Standardanfragen - DoT verschlüsselt)
2001:67c:28a4:: (DoT verschlüsselt)
 
  • Like
Reaktionen: rmh
Im Synology-Forum (https://www.synology-forum.de/) überschlagen sich grad die Ereignisse. Kaum einer, der *.fritz.box in Verbindung mit einem externen Nameserver (PiHole etc.) verwendet kommt noch lokal auf sein NAS, weil alles auf 54.39.222.96 (ursf1.viagenie.ca) aufgelöst wird.
 
Dann sind wohl diese "externen Nameserver" schlecht konfiguriert, wenn sie für diese Domain selbst auf externe Forwarder anstelle der lokalen FRITZ!Box zurückgreifen.


Und wenn das nicht reichen sollte, gibt es beim dnsmasq immer noch die Option, für eine Domain gezielt einen Resolver zu definieren (mit der --server- bzw. --local-Option):


Ähnliches gilt für praktisch JEDE Software für Nameserver, die irgendwo verwendet wird - das "Delegieren" der Verantwortung für (Sub-)Domains ist eine Grundfunktion im DNS … man muß es eben nur richtig konfigurieren.
 
Dann sind wohl diese "externen Nameserver" schlecht konfiguriert
Das würde ich nicht sagen, denn die tun das, was sie tun sollen.
Ich denke eher, das AVM da einen Bock geschossen hat und "fritz.box" verwendet, ohne sich diese Domain zu schützen. Kaum registriert sich die dann einer, landet man irgendwo.
Klar kann man das mit etwas Konfiguration beheben/umgehen, aber ganz sauber ist das nicht.
 
Das würde ich nicht sagen, denn die tun das, was sie tun sollen.
Nein, die sind genauso schlecht konfiguriert wie die DNS-Server der deutschen Provider vor einiger Zeit, als man bei einem Domain Name Vertipper auf eine Werbeseite von denen geleitet wurde. Zum Glück gibt es das jetzt nicht mehr. Wenn ich keine Weiterleitung wünsche, dann soll sie auch nicht gemacht werden.
In diesem Fall hier wird der ungültige Domain Name fritz.box auf eine Hinweisseite von URS weitergeleitet.
URS.png
 
Zuletzt bearbeitet:
Verstehe ich nicht, was hat das mit Weiterleitungen zu tun?
Wenn du eine Domain "google.com" für dich registrierst, nur weil Google verpennt hat, die für sich zu registrieren, können die DNS-Server doch nichts dafür, dass alle google.com-Anfragen bei dir landen.
 
Falsch verstanden. Die Domain fritz.box ist nirgendwo mehr registriert. Die Registrierung wurde entfernt (siehe obigen Screenshot).
Die von dir beschriebenen sich überschlagenden Ereignisse treten doch erst seit gestern auf, seitdem die Weiterleitung existiert.
 
Und was ist dann das?
Code:
C:\>nslookup irgendwas.fritz.box. 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Nicht autorisierende Antwort:
Name:    irgendwas.fritz.box
Addresses:  2607:5300:60:408a::96
          54.39.222.96
C:\>nslookup -q=ns irgendwas.fritz.box. 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

fritz.box
        primary name server = ursns1.viagenie.ca
        responsible mail addr = hostmaster.urs.viagenie.ca
        serial  = 1709655485
        refresh = 86400 (1 day)
        retry   = 7200 (2 hours)
        expire  = 7776000 (90 days)
        default TTL = 3600 (1 hour)
Erklär bitte mal.
Aber egal, auf jeden Fall werden Anfragen an fritz.box-Adressen bei allen externen DNS-Servern momentan falsch aufgelöst.
Selbst, wenn das eine Hinweis-Seite wäre, löst das nicht das Problem.
 
Zuletzt bearbeitet von einem Moderator:
denn die tun das, was sie tun sollen.
Na dann - dann lösen sie ja auch die lokale Domain fritz.box (so man die weiterhin verwendet, seitdem die TLD box offiziell konnektiert wurde) korrekt auf und dann verstehe ich nicht, warum jemand damit Probleme haben sollte.

Wer bei korrekter Konfiguration eben seinen LOKALEN DNS-Server befragt (also üblicherweise denjenigen, der auch - quasi als Nebenjob - per DHCP die IP-Adressen im LAN verteilt und die Zuordnungen verwaltet und das muß nicht mal die FRITZ!Box sein), der wird auch die korrekte Auflösung bei der Abfrage erhalten. Ich denke nicht, daß jemand tatsächlich den Google-NS unter 8.8.8.8 als lokalen(!) DNS-Resolver verwenden sollte - insofern ergibt das gezeigte Beispiel auch keinen Sinn.

Und selbst wenn sich AVM diese Subdomain sichern sollte (oder das zumindest versucht), würde eine solche EXTERNE Abfrage nur dann funktionieren (als neue Angabe für den SOA einer Delegation), wenn die IP-Adresse des lokalen Resolvers unveränderlich (und damit sicher bekannt) wäre, was dann JEDE Verwendung eigener DNS-Server (zumindest für Netzwerk-Laien) ausschließt.

Für eine delegierte Subdomain fritz.box würde auch der (autorisierende) Nameserver für die TLD box keine nxdomain-Antwort liefern und wenn der (SOA-)Nameserver für ALLE Subdomains von fritz.box dann eine negative Antwort liefern sollte (technisch gesehen sind auch A- und AAAA-Einträge solche Subdomains), bringt das auch keinen Fortschritt bei einer Lösung.

Da nutzt nicht einmal die "Reservierung" der IP-Adressen 192.168.180.1 bzw. 192.168.180.2 bei AVM als Synonym für die in der Box konfigurierten Forwarder etwas, denn das sind eben auch nur diejenigen, die für EXTERNE Auflösung zuständig sein sollen und nicht für lokale.

Das Problem (das nennt sich dann "split DNS") kennt auch jeder (DNS-)Administrator in einer Firma, bei der intern zusätzliche Namen aufgelöst werden sollen, die von extern niemanden zu interessieren haben … und ein ordentlciher DNS-Server (und den von AVM zähle ich dazu) hat für solche unterschiedlichen Berechtigungen sogar "access control lists" (ACL), mit denen geregelt wird, für welche Netzwerksegmente woher/wie aufgelöst werden soll. Bei AVM wird das u.a. für die Isolation des Gastnetzes verwendet - das kann sich jeder in den Supportdaten genau ansehen.

Wer sich selbst zum (lokalen) DNS-Admin kürt, sollte dann eben auch dafür sorgen (und dazu auch in der Lage sein), daß seine Infrastruktur WIRKLICH funktioniert und dann haben Abfragen zur Auflösung lokaler Namen NICHTS auf externen DNS-Servern (sofern die nicht SOA der eigenen(!), lokalen Domain sind) zu suchen. Punkt.

Denn auch der "Rebind-Schutz" im Resolver (der eine Auflösung externer Abfragen auf lokale Adressen verhindern soll) hat ja seinen Grund …

EDIT:
Aber egal, auf jeden Fall werden Anfragen an fritz.box-Adressen bei allen externen DNS-Servern momentan falsch aufgelöst.
Was wäre denn - nach Deiner Ansicht - die korrekte Auflösung und wie sollte das - unter Beachtung der Hierarchie im DNS - funktionieren?

EDIT2:
Und bitte die "externen Nameserver" aus meinem Zitat (die Quelle spezifizierte das ja auch noch als "PiHole etc.") nicht mit öffentlich erreichbaren (also WIRKLICH externen) Resolvern verwechseln - ich meinte schon DIE (lokalen) Installationen, die extern zur FRITZ!Box sind und die der (LAN-)Administrator dann selbst vernünftig konfigurieren sollte (bzw. muß, wenn man Wert auf die korrekte Funktion legt).
 
Zuletzt bearbeitet:
Was wäre denn - nach Deiner Ansicht - die korrekte Auflösung
Die korrekte Lösung wäre, dass *.fritz.box-Namen von externen Name-Servern wie früher erst gar nicht gefunden/aufgelöst werden. Dann käme als Meldung wenigstens "kenne ich nicht" anstatt "kann nicht verbinden".

Ich war selbst verwundert, wie viele Anwender den DNS-Server ihrer Fritzbox auf ihren Clients gar nicht direkt nutzen sondern Lösungen wie PiHole etc. dazwischen haben. Wenn die dann nicht so konfiguriert sind, dass Anfragen nach *.fritz.box nicht zur Fritzbox gehen ("Conditional Forwarding" bei PiHole), sondern extern aufgelöst werden, kommt es zu dem beschriebenen Effekt.

Jeden Tag gibt z.B. im Synology-Forum momentan gehäuft Anfragen wie z.B. diese hier, wo Anwender jammern "Ich komm nicht mehr auf mein NAS, \\<IP> geht noch, aber \\<Name> nicht mehr".
 
Zuletzt bearbeitet von einem Moderator:
Tja, da haben diese Benutzer sich dann darauf verlassen, daß eben KEINE Antwort (bzw. explizit nxdomain) kam und danach dann andere/weitere Mechanismen für eine Namensauflösung genutzt wurden (WINS-Abfragen, die sowohl mit einem Server als auch per Broadcasts arbeiten können oder auch mDNS).

Das ist aber ohnehin eine Sicherheitslücke, wie sich jetzt mal exemplarisch zeigt, auch wenn das zuvor immer nur "theoretisch" beschrieben wurde - sich darauf zu verlassen, daß eine BESTIMMTE Antwort auch genau so wie erwartet gegeben wird, macht einen (bzw. seine Installation) eben von einem externen Faktor abhängig.

Ist die Konfiguration hingegen korrekt, erfolgt erst gar keine Abfrage eines externen Nameservers für die lokal verwendete Domain - mithin interessiert es auch nicht wirklich, was da als Antwort zurückkäme.

Das eigentliche Problem liegt also nicht in der Antwort, sondern darin, daß da überhaupt gefragt wird.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.