Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Lokaler DNS wird im Browser nur mit Punkt am ende aufgelöst
ich habe ein Problem, das ich mir nicht erklären kann:
Ich habe eine CCU3 Homeautomatisierungszentrale (im Prinzip ein Raspberry), diese hat den Hostnamen CCU3 bei mir und ist im Router (Technicolor) Kabelbox) auch so unter den Devices gelistet, die zugehörige bezogene IP steht dabei 192.168.0.62
Wenn ich versuche die Box per HTTP://CCU3/ im Browser zu erreichen, dann wird die Seite nicht gefunden, während HTTP://192.168.0.62/ geht.
nslookup 192.168.0.62 liefert CCU3 zurück.
nslookup CCU3 liefert 192.168.0.62 zurück.
Ping auf CCU3 schlägt fehl, auch mit ipconfig /flushdns
Ping auf 192.168.0.62 geht natürlich
Jetzt kommt es, wenn ich im Browser einen Punkt hinter CCU3 mache, dann wird der Name aufgelöst:
HTTP://CCU3./
Kann mir jemand erklären woran das liegt?
Bei Win10 und Win11 gleiches Verhalten, einzig mit dem iPhone wird HTTP://CCU3/ direkt ohne Punkt aufgelöst.
Irgendwie kann ich mir im Windows keine Bug vorstellen, zumal alle anderen Linux Devices (wie das MyBook Nas) einwandfrei tun
ein FQDN endet immer mit einem "." das zeichnet ein FQDN aus, eine URL z.B. besteht aus einem Protokoll-Typ "HTTP / HTTPS" anschließend kommt eine IP-Adresse oder ein FQDN der mit einem Punkt endet zum schluss kommt dann nur noch die Top-Level Domain z.B. "de".
Sprich das verhalten ist im ersten Moment richtig.
Aber ich weiß und kann nachvollziehen was du meinst und worauf du hinaus möchtest.
Wie sehen denn deine DNS Einstellungen aus?
Meist hat dies mit einer Falschen Konfiguration dessen zu tun.
ein FQDN endet immer mit einem "." das zeichnet ein FQDN aus, eine URL z.B. besteht aus einem Protokoll-Typ "HTTP / HTTPS" anschließend kommt eine IP-Adresse oder ein FQDN der mit einem Punkt endet
Ok gut zu wissen!
Extrem komisch finde ich, dass das Nas Webinterface im Browser hierbei ohne Probleme geht.
Auch komisch ist, dass das Webinterface der CCU3 auf dem iPhone ohne Punkt aufrufbar ist.
Irgendwie schließt das für mich eine Fehlkonfiguration aus, zumal ich in der Kabelbox auch nichts einstellen kann, die ist immer auf Kabelbox.local (das steht so in der Lan Einstellung als Info mit dabei) HTTP://CCU3.Kabelbox.local/ hab ich auch mal probiert, tut aber nicht.
Kann das was mit der Arbeitsgruppe des lokalen Windows PC was zu tun haben, die hat das iPhone ja nicht
".local" kann nicht, das ist mDNS vorbehalten. Das ist also definitiv nicht die "normale" Domain der Box. Das iPhone wird sie aber möglicherweise trotzdem nutzen aufgrund der Bonjour Dienste (die sind mDNS basiert).
Insgesamt scheinen Domain und SearchDomain einiger (oder aller) Geräte nicht zusammenzupassen. Das erklärt die Probleme bei der Namensauflösung.
Dass man Webinterfaces immer einfach durch Eingabe des Namen oder IP Adresse eines Devices aufrufen kann.
Das geht hier einfach nur dann wenn ich den Namen mit einem Punkt abschließe, über die IP Adresse tut das selbstverständlich immer
Ein DHCP-Server verteilt normalerweise eine lokale Domain an seine Clients. Das heißt, dass zB "MeinPC" beispielsweise eigentlich "MeinPC.irgendwas.lan" heißt. Darüber hinaus füllt der DHCP-Server beim Client noch die besagte DNS-Suffixsuchliste. Das sind weitere Domains, die ebenfalls lokal verwendet werden. Beides, das Primäre DNS-Suffix des eigenen Systems sowie die Suffixsuchliste, findet man beispielsweise bei ipconfig /all
Wenn man nun auf einem anderen PC den Namen "MeinPC" aufzulösen versucht, setzt dieser PC mehrere DNS-Queries ab, die nacheinander "MeinPC" um die Suffixe in der Suchliste erweitert. Ein . am Ende des Hostnamens teilt dem System jedoch mit, dass dies explizit nicht passieren soll, sondern der Name so wie er ist vollständig ist (siehe FQDN wie von @toxic189 beschrieben).
Ich gehe daher davon aus, dass das Gerät "CCU3" in diesem Falle eine fehlerhafte Konfiguration beim DNS-Suffix aufweist oder sogar überhaupt keinen konfiguriert hat. Daher funktioniert "CCU3" nicht, weil dort die besagten DNS-Suffixe implizit angehängt werden und nichts gefunden wird, während "CCU3." funktioniert, weil dieser Host explizit keinen Suffix hat und deswegen ohne angehängtes Suffix gesucht und gefunden wird.
Prüfe daher am CCU3-System ob die lokale Domain korrekt gesetzt ist. Da du von einem PI sprichst, sollte
hostname -f
den FQDN des Systems zeigen, also Name.Domain. Wenn dort nur der Name steht, ist keine Domain gesetzt.
Darüber hinaus ist wohl davon auszugehen, dass CCU3 über eine statische IP-Konfiguration verfügt. Wenn du diese auf DHCP umstellst und im DHCP-Server die dazugehörige IP statisch reservierst, sollte CCU3 die Domain eigentlich automatisch korrekt zugewiesen bekommen.
Vielen Dank für die tolle Erklärung!
Ich kucke mir das mal genauer an, aber auf DHCP hatte ich die CCU3 schon einmal und es ging auch nicht,
vermutlich hat die CCU3 genau da ein Problem
Was heißt das denn konkret? Ist das tatsächlich ein PI, auf den man ggfs auch via SSH zugreifen kann, oder wie ist das zu verstehen?
*edit
Selbst beantwortet. Hier wird erklärt wie man SSH-Zugriff aktiviert: Klick!
Damit hat man gegebenfalls mehr Möglichkeiten, dem Problem auf den Grund zu gehen und wie oben beschrieben den FQDN des Systems auszulesen bzw. allgemein die DHCP-Einstellungen zu checken.
Wenn nicht mehr benötigt, kann man den SSH-Zugriff wieder deaktivieren.
Natürlich setzt das voraus, dass du überhaupt Zeit und Mühe investieren möchtest, dem Problem auf den Grund zu gehen. Mit . am Ende hast du ja eine funktionierende Lösung, die nicht wirklich wehtut. Ich würde das untersuchen und final lösen wollen, aber das ist nun mal berufliche Neugierde, der innere Monk des Informatikers. Als reiner Anwender würde ich tendenziell eher mit der Schulter zucken und den . ohne weiteren Gedanken hinnehmen - gibt schlimmere workarounds, die deutlich mehr Mühe kosten als .. .. .. ein Punkt
Ich bin Elektroniker, mich interessieren Fehler auch, ich wills verstehen.
Ich habe schon gekuckt wie ich auf das Linux komme :-) Testen kann ich es aber erst zuhause...
Ich verstehe das nicht, kann das sein, dass hier das Kabelmodem der Übertäter ist und keine korrekten DNS Daten liefert?
Hier handelt es sich um ein Vodafone CGA4233DE, das Ding ist eine Krücke, hier wollte ich mal die DHCP Bereiche von 192.168.0.x auf 192.168.1.x umstellen, das schlug fehl und der Support sagte wenn ich das umstelle erlischt die Garantie und Funktion -> das lief also in eine Sackgasse und ich änderte einfach alle anderen Clients in meinem Netzwerk.
By the way: die CCU3 wird auch so als CCU3 im Übersichtsmenü wo die verbundenen Geräte gelistet werden angezeigt.
Hier eventuell noch Daten von Windows aus, die hilfreich sein könnten:
C:\Users\georg>ping 192.168.0.134 -a
Ping wird ausgeführt für 192.168.0.134 mit 32 Bytes Daten:
Antwort von 192.168.0.134: Bytes=32 Zeit=7ms TTL=64
Antwort von 192.168.0.134: Bytes=32 Zeit=9ms TTL=64
Antwort von 192.168.0.134: Bytes=32 Zeit=9ms TTL=64
Antwort von 192.168.0.134: Bytes=32 Zeit=9ms TTL=64
Ping-Statistik für 192.168.0.134:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 7ms, Maximum = 9ms, Mittelwert = 8ms
C:\Users\georg>tracert 192.168.0.134
Routenverfolgung zu ccu3 [192.168.0.134]
über maximal 30 Hops:
# arp -a
kabelbox (192.168.0.1) at 02:10:18:f3:0b:c4 [ether] on eth0
? (192.168.0.43) at 06:34:d5:2a:2e:e4 [ether] on eth0
LGwebOSTV (192.168.0.113) at 4c:1b:86:ff:11:2c [ether] on eth0
Laptop (192.168.0.129) at 50:76:af:cb:0a:6b [ether] on eth0
#
Vielleicht kann man aus dem allem was ableiten, ich habe absolut keine Ahnung.
Inzwischen wurde im Gegensatz zum Anfang des Threades das Kabelmodem getauscht, das Webinterface von dem CCU3 lässt sich nicht mehr mit CCU3. aufrufen nur noch über die IP 192.168.0.134
Ergänzung ()
Nachtrag, Tracert kann es mit CCU3. nur CCU3 kann nicht aufgelöst werden. Im Browser tut das leider aber nicht mehr
C:\Users\georg>tracert ccu3.
Routenverfolgung zu ccu3 [192.168.0.134]
über maximal 30 Hops:
1 8 ms 7 ms 9 ms ccu3 [192.168.0.134]
Ablaufverfolgung beendet.
C:\Users\georg>tracert ccu3
Der Zielname ccu3 konnte nicht aufgelöst werden.
Noch ein Nachtrag: Ping auf Kabelbox mit und ohne Punkt das gleiche:
C:\Users\georg>ping kabelbox
Ping-Anforderung konnte Host "kabelbox" nicht finden. Überprüfen Sie den Namen, und versuchen Sie es erneut.
C:\Users\georg>ping kabelbox.
Ping wird ausgeführt für kabelbox [192.168.0.1] mit 32 Bytes Daten:
Antwort von 192.168.0.1: Bytes=32 Zeit=14ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit=8ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit=8ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit=8ms TTL=64
Ping-Statistik für 192.168.0.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 8ms, Maximum = 14ms, Mittelwert = 9ms
Hier handelt es sich um ein Vodafone CGA4233DE, das Ding ist eine Krücke, hier wollte ich mal die DHCP Bereiche von 192.168.0.x auf 192.168.1.x umstellen, das schlug fehl und der Support sagte wenn ich das umstelle erlischt die Garantie und Funktion -> das lief also in eine Sackgasse und ich änderte einfach alle anderen Clients in meinem Netzwerk.
What? Also das mit der Garantie halte ich für eine grob fahrlässig falsche Aussage seitens des Supports. Wenn man beispielsweise Home Office macht, kann es sogar sein, dass man die IP/das Subnetz ändern MUSS (Stichwort: VPN). Es mag sein, dass sich der Support weigert, zu supporten, wenn man Einstellungen ändert, aber mit der Garantie hat das nichts zu tun - es sei denn der Router ist gemietet und somit Eigentum des Providers. Wobei auch dann ist das Ändern des Subnetzes wie erwähnt unter Umständen erforderlich.
Ich behaupte einfach mal, dass da der Mitarbeiter vom Callcenter in Bangladesh (oder wohin auch immer Vodafone - wie alle anderen auch - seinen Support auslagert) einfach keine Lust oder nicht das nötige Wissen hatte, dir da weiterzuhelfen.
fft schrieb:
Ich verstehe das nicht, kann das sein, dass hier das Kabelmodem der Übertäter ist und keine korrekten DNS Daten liefert?
Was heißt falsch? Die lokale Domain ist nicht zwingend erforderlich. Namen und deren Auflösung sind gewissermaßen eine optionale Schicht über dem eigentlichen Netzwerk, eine Komfortfunktion.
Sollte die Kabelbox keine derartigen Einstellungen zulassen, wäre das Auslagern von DHCP und DNS eine Option. Ein Raspberry PI, o.ä. mit pihole könnte beispielsweise sowohl als DNS- als auch als DHCP-Server fungieren, inkl. frei konfigurierbarer lokaler Domain, zB "fft.lan". Dann sollten auch alle DHCP-Clients dieselbe lokale Domain vom DHCP bekommen und sich ohne irgendwelche Punkte im Namen gegenseitig finden können
Das sind keine geeigneten Tools zum Test der Namensauflösung. Ping dient prinzipiell nur zu grundlegenden Verbindungstests und tracert dient der Wegverfolgung, also Prüfung des Routings. Beide nutzen implizit Namensauflösung, aber das ist nicht ihre Aufgabe, sondern lediglich Mittel zum Zweck. Namensauflösung prüft man hingegen mittels "nslookup".
Wenn ich das alles richtig interpretiere, dann kann ich vermutlich an der Situation nichts ändern, weil der Router einen Fehler bei DNS macht, richtig?
Oder könnte ich noch was testen, bevor man an dem Punkt das einfach so stehen lassen muss?
Raijin schrieb:
Also das mit der Garantie halte ich für eine grob fahrlässig falsche Aussage seitens des Supports.
Ja so ist das eben, aber an wen soll man sich wenden, wenn nach der Umstellung der Lokalen IP keine Verbindungen mehr zustande kommen?
Wenn die einem nicht helfen wollen, dann muss man es aber so lassen wie es (ab werk) tut, mehr möglichkeiten habe ich ja nicht.
Ich könnte ne Fritzbox oder ähnliches nehmen, wo die Einstellungen die man hat auch einfach tun :-)
Die lokale IP des Routers nebst DHCP-Bereich zu ändern, ist einer der häufigsten Anwendungsfälle überhaupt. Es gibt zahlreiche Hilfen wie man da konkret vorgeht, sei es bei Youtube oder zB auch hier. Einfach nur die IP des Routers ändern ist eben nur die halbe Miete. Wenn danach keine Verbindungen mehr möglich sind, haben die Clients im Netzwerk in der Regel noch das alte Subnetz und suchen den Router auf der falschen Adresse. Passt man die Clients an, was bei DHCP meist durch einen Neustart am einfachsten erledigt ist, klappt's auch mit der neuen IP.
fft schrieb:
Ich könnte ne Fritzbox oder ähnliches nehmen, wo die Einstellungen die man hat auch einfach tun :-)
Wenn danach keine Verbindungen mehr möglich sind, haben die Clients im Netzwerk in der Regel noch das alte Subnetz und suchen den Router auf der falschen Adresse. Passt man die Clients an, was bei DHCP meist durch einen Neustart am einfachsten erledigt ist, klappt's auch mit der neuen IP.
Hast du spaßeshalber mal "CCU3.local" probiert? Wie @riversource schon schrieb, erfüllt .local einen speziellen Zweck und muss nicht explizit irgendwo als Domain eingetragen sein.
Ergänzung ()
Übrigens:
Wenn alle Stricke reißen, kann man ggfs auch auf den Clients, mit denen man eine Verbindung zu CCU3 herstellen möchte, den Namen "CCU3" nebst IP in die hosts-Datei schreiben. Die hosts-Datei ist sozusagen ein lokaler Override für die Namensauflösung und wenn dort ein Eintrag gefunden wurde, erfolgt keine weitere DNS-Auflösung. Heißt: CCU3 sollte dann auch ohne . funktionieren. Das ist natürlich nur ein Workaround, aber sollte funktionieren.
