Update Sonoma 14.4, interne Namensauflösung zickt, aber ...

[mattmiksys]

Hallo liebe Leute,

nach dem Update meines Mini M1 habe ich rätselhafte Probleme mit der internen Namensauflösung.
- Die Einträge bei den Netzwerken sehen alle korrekt aus, aber interne Gerätschaften werden nicht über den Namen (schon aber über IP) gefunden. Extern gibts keine Probleme.
- Bei Anpingen der Geräte (Synology, RasPi, auch fritz.box) wird überall immer dieselbe IP zurückgereicht (45.76.93.104), mit langen, schwankenden Antwortzeiten oder auch Timeout.
- Das Verwenden mehrerer Drucker ist unproblematisch.
- Nach dem Anlegen eines Test-Benutzers ist dort alles normal, ebenso auf meinem zeitgleich auf 14.4. gebrachten, mit praktisch gleichen Installationen versehenen MacBook Air M2.

Cache-Löschen und was ich in den letzten Stunden im Netz gefunden habe, habe ich hinter mir. Mit dem mDNSResponder habe ich allerdings Probleme: "Unload/Load failed : 5 Input/output error". So richtig passt das als Ursache ja ohnehin nicht, wenn globale Dienste bei einem Testbenutzer funktionieren.
Ich bin jedenfalls ratlos und hoffe auf Eure Ideen...

Grüße, Matthias

 

[lisanet]

- Bei Anpingen der Geräte (Synology, RasPi, auch fritz.box) wird überall immer dieselbe IP zurückgereicht (45.76.93.104), mit langen, schwankenden Antwortzeiten oder auch Timeout.

Hast du ein VPN aktiv?

 

[mattmiksys]

Mehrere VPNs habe ich in Bereitschaft, aber nicht aktiv, das wäre natürlich auch noch ein Ansatz ...
.. habe eben versucht, eine beliebige Verbindung aufzubauen, das klappt aber nicht.

 

[lisanet]

eine kurze Recherche ergab, dass die IP-Adresse die Domain vultrusercontent.com betrifft und die zu https://www.vultr.com/ gehört.

Das sieht für mich so aus, dass du von denen irgendwelche Dienste, Tools, Software hast, die deinen DNS verbogen haben oder du hast was nicht ganz passend konfiguriert.

 

[mattmiksys]

Tja, alle VPNs habe ich entfernt (das kurz geprüfte war nicht aktiv)
IP hatte ich auch mal geschaut, aber war nicht darauf gestoßen. Nun habe ich "vultr" mal gesucht, in versteckten Docker-Dateileichen gefunden und beseitigt. Neustart und .. leider keine Veränderung

 

[lisanet]

Tja, alle VPNs habe ich entfernt (das kurz geprüfte war nicht aktiv)
IP hatte ich auch mal geschaut, aber war nicht darauf gestoßen. Nun habe ich "vultr" mal gesucht, in versteckten Docker-Dateileichen gefunden und beseitigt. Neustart und .. leider keine Veränderung

Dann hat sich die Software wohl noch wo anderes eingegraben und/oder Einstellungen manipuliert.

Also prüfe mal alles was mit DNS zu tun hat, angefangen von /etc/hosts bis hin zu Einträgen in den Netzwerkeinstellungen.

 

[mattmiksys]

ich bin der Meinung, dort überall schon gewesen zu sein. Eben habe ich nslookup mit den "verschollenen" Geräten ausprobiert, alles richtig.
Die vultr-Leichen waren wohl bei Docker-Experimenten vor eineinhalb Jahren hinein gekommen, jedenfalls nicht absichtlich und nicht aktuell.
Aber danke, ich werde nochmal alles durchflöhen und berichten.

 

[Darker]

Guten Abend,

zunächst mal: Ich bin kein Mac-Benutzer. Ich bin durch Google auf den Beitrag hier gestossen, denn ich habe exakt das gleiche Problem unter Windows und im ziemlich gleichen Zeitfenster wie mattmiksys. Ich erreiche seit vorgestern (11.03.2024) mein Synology NAS auf einem Windows 10 PC nicht mehr über den Hostnamen. Ein Ping ergab als IP 45.76.93.104 anstelle von 192.168.0.xxx

Ich habe das für einen wirren Bug gehalten, mit ipconfig /flushdns den lokalen DNS Cache des Windows 10 Rechners geleert, danach ging es wieder.
Seit heute tritt das Problem wieder auf, aber nicht nur auf dem einen Win10 Rechner, sondern noch einem weiteren. Den einen PC nutzt meine Frau, den anderen nutze (ganz selten) ich, er war seit einem Monat ausgeschaltet. Daher schliesse ich auch eine Infektion mit Schadsoftware aktuell aus.

Wir nutzen keinerlei VPN Dienste. Unser Netzwerksetup:

Fritzbox, die als DHCP-Server fungiert. NAS hat statische IP, Desktop PCs ebenfalls. Die beiden Win10 Notebooks jedoch die betroffen sind haben dynamische IPs per DHCP. Die Fritzbox nutzt als DNS-Server einen PiHole (Raspberry Pi mit DNS-Server und Werbeblocker, sicher bekannt). In der Fritzbox habe ich konfiguriert, keine öffentlichen DNS-Server zu nutzen falls der lokale DNS-Server mal nicht antwortet (hat die Fritzbox nämlich manchmal stundenweise gemacht, weswegen wieder Werbung durchkam).

Wenn ich die IP per nslookup auflöse, wird mir als Host 45.76.93.104.vultrusercontent.com angegeben. Ich habe absolut keine Ahnung, wie das passieren kann. In meinen Augen bekommen die Notebooks ihre IPs vom DHCP der Fritzbox zugewiesen, zusammen mit der Info dass der PiHole als DNS-Server zu nutzen ist.

Wenn das Problem unter MacOS auftritt und unter Windows... wo liegen die Gemeinsamkeiten? Fritzbox? PiHole? Ein Bug im Synology DSM? (Ich nutze auf dem System 6.2.4-25556 Update 6 (seit eben wird mir Update 7 angeboten, damit warte ich jetzt nochmal)

Viele Grüsse
Darker

 

[Darker]

Ich glaube ich habe da eine Spur...

Anfang des Jahres haben sich Unbekante die öffentliche Domain fritz.box registriert:
https://www.heise.de/news/Verwirrend-Internet-Domain-fritz-box-zeigt-NFT-Galerie-statt-Router-Verwaltung-9610149.html

Diese Domain wurde vor einer Woche aus dem Verkehr gezogen:
https://www.heise.de/news/Fritz-box-Domain-aus-dem-Verkehr-gezogen-9647776.html

Allerdings wurde hierbei der "strittige" Domainname nur "ausgesetzt", bis die Registrierung abläuft.
Was das technisch bedeutet, ist mir nicht ganz klar, brachte mich aber auf die Idee, mal mit der
DNS-Abfrage der MX-Toolbox. Ergebnis:

Type	Domain Name	IP Address	TTL
A	fritz.box	45.76.93.104 Unknown (AS20473)	24 hrs

Unsere Geräte, die von der FritzBox eine IP per DHCP bekommen, scheinen bei der Abfrage eines Hostnamens wie nas.fritz.box als Ergebnis nun die öffentliche IP der öffentlichen Domäne fritz.box zu erhalten... oder sehe ich das falsch?

 

[lisanet]

@Darker

Super

Das scheint exakt die Erklärungzu sein. Ein nslookup auf fritz.box bringt genau diese IP-Adresse zu Tage.

Letztendlich wird nur AVM das Problem für die weitaus überwiegende Anzahl der User lösen können, da sicher nicht jedem Verwender einer Fritte geläufig ist was man dagegen tun kann.

Das Nicht-Verwenden eines individuellen DNS-Eintrages sollte einen Teil des Problemes lösen. Für Mac-User kann darüber hinaus noch Private Relay abgeschaltet werden müssen, was dann aber wiederum Tracking des User durch webseiten vereinfacht.

Zugriffe auf NAS-Systeme und andere lokale Dienste sollten so konfiguriert werden, dass sich diese NAS / Geräte / Dienste über Bonjour announcieren und man sie darüber anspricht, anstatt über einen xxx.fritz.box Namen.

Im Grunde genommen war und ist es von AVM eine technisch gesehen, selten dumme Idee, eine existente TLD als DHCP-Domain im LAN zu verwenden und nicht auf Standards wie Bonjour zu setzen. Da fällt AVM eben ihr eigenes Marketing gehörig auf die Füße.

 

[Darker]

Im Grunde genommen war und ist es von AVM eine technisch gesehen, selten dumme Idee, eine existente TLD als DHCP-Domain im LAN zu verwenden

Haben sie ja nicht. Die TLD .box ist erst seit November 2016 verfügbar (Quelle: https://newgtlds.icann.org/en/program-status/delegated-strings)
AVM verwendet als Default für das interne Netz aber schon viel länger fritz.box

Ich habe früher .local für das lokale Netz verwendet, da ich der Meinung war, das würde NIEMALS eine öffentliche TLD.
Tja was soll ich sagen, als man vor 10 Jahren die Büchse der Pandora geöffnet hat und über 1000 neue TLDs definiert hat, war wirklich jeder Blödsinn dabei und sogar .local ist jetzt eine öffentliche TLD. Dann hat es weitere 10 Jahre gedauert, bis die ICANN sich mal überlegt hat was man denn am besten lokal verwenden soll und wovon sie die Finger lassen soll. Ergebnis aus Januar 2024: .internal
Na Glückwunsch, ICANN!

Letztendlich wird nur AVM das Problem für die weitaus überwiegende Anzahl der User lösen können

Ich weiss nicht... vielleicht habe ich mir auch selbst ein Ei gelegt. Ich habe mir überlegt: Wenn der Client per DHCP gesagt bekommt, er solle beim PiHole Hostnamen auflösen, wie kommt er dann an die interne IP meines NAS? Ich muss mal prüfen, ob der PiHole überhaupt Anfragen an die Fritzbox stellt. Wenn nicht, ist das vielleicht die Lösung. Aber es würde nicht erklären, warum das Problem erst seit 2 Tagen auftritt. Ich verbinde Netzlaufwerke auf den mobilen Win10 Geräten seit Monaten, wenn nicht sogar über einem Jahr über den Hostnamen.

@mattmiksys
Derweil würde mich interessieren, ob Du auch einen PiHole oder einen lokalen DNS-Server abseits der FritzBox verwendest wie ich

 

[lisanet]

Es geht ja nicht darum .local als DHCP-domain fest zu legen, sondern eben Bonjour zu verwenden, was anders funktioneirt als eine DNS-Abfrage einer Domain. Bonjour fragt alle Geräte im lokalen Netz ab, ob der Name zu ihnen passt. Daherauch die Bezeichnung als mDNS =? multicast DNS.

Würdest du legdiglich eine lokale Domain .local verwenden, gehst zu den Weg über DNS, was dann - wie hier mit fritz.box - dazu führen kann, dass externe Namensauflösungen erfolgen, mit genau den hier vorliegenden Problemen.

Daher kann man IMO ruhig die Idee haben eine DHCP-Domain nach eigenem Gusto festzulegen. Dann muss man aber eben auch dafür Sorge tragen, dass zu dieser Domain keine Abfragen das lokale Netz verlassen.

Das kann man alles bewerkstelligen, aber IMO nicht von der überwiegenden Anzahl an Consumern erwarten, die genau die dazu erforderliche Kenntnis in Netzwerken nicht haben.

Ich finde, dass wenn einer der (zumindest in DACH) sehr weitverbreiteten Hersteller ein Consumer-Proukt vertreibt, sollte der sein Produkt auch so gestalten, dass derartige Probleme nicht auftreten. Vorallem deswegen, weil es eben einen Standard wie Bonjour / mDNS gibt. Ich bin mir auch sicher, dass AVM diesen Standard kennt, ihn aber aus reinen Marketingzwecken nicht befolgt und nun Großteil ihrer Kunden dahingehen "erzogen" hat, ihre Geräte mit "fritz.box" anzusprechen, statt mit "fritzbox.local" (via mDNS). Und daher kann ich das erst recht nicht nachvollziehen.

 

[lisanet]

vielleicht habe ich mir auch selbst ein Ei gelegt. Ich habe mir überlegt: Wenn der Client per DHCP gesagt bekommt, er solle beim PiHole Hostnamen auflösen, wie kommt er dann an die interne IP meines NAS?

Naja, eine Idee wäre, den PiHole als DHCP zu verwenden.

Besser und einfacher finde ich, wenn du dein NAS so konfigurierst, so dass es seine IP-Adressen via Bonjour announciert und du es ansprichst mit eben dem Bonjour-Namen wie "nas.local".

 

[minion]

Sehr interessant und danke für die zusammengetragenen Informationen.
Ich habe einen Mac und auch Pi-hole im Einsatz, aber letztlich konnte ich das Problem lösen, indem ich die Namensauflösung von fritz.box von 45.76.93.104 wieder zu 192.168.178.1 lokal auf dem Rechner umgebogen habe.

sudo vi /etc/hosts + Passwort (vielleicht gibt es auch andere Editoren)
Dann in der Datei einfach folgende Zeile anfügen:
192.168.178.1 fritz.box

Wenn eines Tages alles wieder wie vorher funktioniert und das 45.76.93.104 Problem an anderer Stelle gelöst wurde, dann kann man den Eintrag wieder entfernen.

 

[mattmiksys]

Na, liebe Leute, DAS ist wahrlich eine Erklärung!
Ich hatte das Problem ja mit dem Update in Verbindung gebracht, vermute nun, dass die DNS-Caches für das verwirrende "Mal-gehts-mal-nicht" gesorgt haben. So ganz habe ich die Tragweite noch nicht durchleuchtet, immerhin habe ich bei der Gelegenheit so manche finstere Ecke der Macs aufgeräumt...

 

[Soylent]

Hi,
ich hänge mich mal dran:
bei mir funktioniert seltsamerweise fritz.box im Browser noch. Ein ping verweist aber auch auf 45.76.93.104. Wie geht das?
Aufgefallen ist es mir beim Zugriff auf meine Raspberries per im Terminal per SSH auf Hostname. Da wurde das SSL-Zertifikat nicht mehr akzeptiert. "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!".
Hatte erst Schiss bezüglich eines Hacks, hab mich dann aber an die die fritz-box-Geschichte erinnert.
Workaround bis jetzt Eintrag in die hosts-Datei.
Für bessere Ideen bin ich offen.

 

[lisanet]

Wenn du für IPv6 einen eigenen DNS in der FB eingetragen hast und den für IPv6 belässt, so dass dieser weiter auf die FB zeigt, könnte das so sein: Safari bevorzugt IPv6 -> FB wird erreicht, ping im Terminal verwendet IPv4 -> geht an die falsche IP

Lösung wäre: alle eignenn DNS einträge löschen und ggf. Private Realy deaktiveren

Besser noch wäre es einen vernünftigen Router zu kaufen der nicht von AVM ist, oder den des Providers. Wenn du nicht zwingend DECT verwenden musst, dann ist selbst eine Vodafone-Station besser.

 

[Soylent]

Ja. Irgendwsowas wird der Grund sein. Danke.
Bis jetzt war ich eigentlich ganz zufrieden mit dem FritzBox-Zeug. Hab mehrere Repeater und Thermostate. Hab schon mehrere Versuche mit diversen DNS-Servern gemacht. Aber nur mit den lokalen Hosts-Settings gehts. Aber wenn man mehrere Geräte hat, ists blöd. Hoffe auf einen Fix.
Gucke jetz erst mal, wie sich PiHole macht.

 

[lisanet]

Hab schon mehrere Versuche mit diversen DNS-Servern gemacht.

eigene DNS-Einträge sind die Ursache dafür, dass die falsche IP aufgelöst wird.

Du kannst das nur lösen, indem du _ausschließlich_ die FB als DNS verwendest. Auch Private Relay kann ein Problem darstellen. Ein VPN, dass den DNS ebenso durchs VPN jagt ebenso. Alles was eben nicht die FB selbst als DNS nutzt.

Das was AVM mit dieser DHCP-Domain gemacht hat ist halt einfach dumm. Zwar toll fürs Marketing, aber netzwerktechnisch gesehen Mist. Und das fällt ihnen halt jetzt auf die Füße. Und User, die nicht in Netzwerken bewandert sind, haben Probleme. Tolle Leistung von AVM.

 

[Darker]

Du kannst das nur lösen, indem du _ausschließlich_ die FB als DNS verwendest.

Wieso? Es reicht doch, dass z.B. ein PiHole Anfragen an Hosts der DHCP-Domain zusätzlich primär bzw. ausschliesslich an die Fritzbox schickt. Dafür gibt es im PiHole eine Option unter Settings -> DNS -> Conditional forwarding

Zitat
"You can also specify a local domain name (like fritz.box) to ensure queries to devices ending in your local domain name will not leave your network, however, this is optional.The local domain name must match the domain name specified in your DHCP server for this to work. You can likely find it within the DHCP settings."

Diese Option hatte ich nicht aktiv, ich halte das aktuell noch für die Ursache meines Problems. Mehr dazu kann ich sagen, wenn der Lease abgelaufen ist (10 Tage). Nach manuellem ipconfig /renew und ipconfig /flushdns war das Problem jeweils temporär weg, daher möchte ich mal den "natürlichen" Ablauf testen, obwohl der im Prinzip ja der gleiche ist.

Deine Aussage, der Router des Providers sei "vernünftig" teile ich aus mehreren Gründen nicht. Zum einen bieten diverse Provider selbst Fritzboxen als Router, da würde sich also gar nichts ändern. Jedoch vernageln manche Provider ihre überlassenen Router, dort kann man nichtmal selbst kritische Updates installieren und muss drauf hoffen, dass der Provider tätig wird, denn oft ist eine auf den Provider angepasste Firmware nötig. Die Krönung sind dann noch Provider, die das integrierte WLAN nur gegen Bezahlung aktivieren. Es mag für manche Leute praktisch sein, sich um nichts kümmern zu müssen. Aber sich gleichzeitig um nichts kümmern zu können halte ich nicht für empfehlenswert.