21
Browserverhalten bei nicht offizieller TLD im privaten Netz
Moin,
ich hoffe ihr könnt mir helfen Licht ins Dunkel zu bringen. So ganz verstehe ich diesen ganzen Zusammenhang nicht.
Ich will in meinem internen Netz einen Webserver unter z. B. "as.khbr" erreichen. Dafür nutze ich auf meiner pfSense die DNS-Weiterleitung. Gebe ich nun dies in den Browser ein werde ich auf die Google Suche weitergeleitet. Gebe ich jedoch "http://as.khbr" ein lande ich wie gewünscht auf dem Host. Warum ist das so?
Ändere ich nun die TLD von ".khbr" zu ".local" funktioniert es gleich auf Anhieb mit "as.local". Liegt das daran diese domain speziell behandelt wird, wie bspw. "localdomain" in RFC2606. Oder wird sie als inoffizieller privater DNS Namensraum wie hier beschrieben behandel?
Aber was geht da im Browser bzw. mit dem DNS Server vor? Wo wird das entschieden was der Browser in diesem Fall macht?
Ich hab dazu nichts helfendes gefunden, weil ich nicht genau weiß wonach ich suchen muss. Kann mir jemand eine konsistente Erklärung geben?
Angenehmen Abend
Siegfried
ich hoffe ihr könnt mir helfen Licht ins Dunkel zu bringen. So ganz verstehe ich diesen ganzen Zusammenhang nicht.
Ich will in meinem internen Netz einen Webserver unter z. B. "as.khbr" erreichen. Dafür nutze ich auf meiner pfSense die DNS-Weiterleitung. Gebe ich nun dies in den Browser ein werde ich auf die Google Suche weitergeleitet. Gebe ich jedoch "http://as.khbr" ein lande ich wie gewünscht auf dem Host. Warum ist das so?
Ändere ich nun die TLD von ".khbr" zu ".local" funktioniert es gleich auf Anhieb mit "as.local". Liegt das daran diese domain speziell behandelt wird, wie bspw. "localdomain" in RFC2606. Oder wird sie als inoffizieller privater DNS Namensraum wie hier beschrieben behandel?
Aber was geht da im Browser bzw. mit dem DNS Server vor? Wo wird das entschieden was der Browser in diesem Fall macht?
Ich hab dazu nichts helfendes gefunden, weil ich nicht genau weiß wonach ich suchen muss. Kann mir jemand eine konsistente Erklärung geben?
Angenehmen Abend
Siegfried
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1424214834
Url: https://administrator.de/contentid/1424214834
Printed on: April 24, 2024 at 02:04 o'clock
21 Comments
Latest comment
Bei Chrome scheint das zum Beispiel by Design zu sein, siehe:
https://stackoverflow.com/questions/36783705/force-chrome-to-follow-url- ...
https://stackoverflow.com/questions/36783705/force-chrome-to-follow-url- ...
Hallo,
Gruß,
Peter
Zitat von @Siegfried36:
Gebe ich nun dies in den Browser ein werde ich auf die Google Suche weitergeleitet. Gebe ich jedoch "http://as.khbr" ein lande ich wie gewünscht auf dem Host.
Weil du 2-mal was anderes eingibst, dein DNS (System Intern) falsch Konfiguriert ist. Existiert überhaupt der nötige Eintrag im DNS um das zu tun was du uns (nicht deutlich) nennst, Was genau gibst du im ersten Fall denn ein, und wie unterscheidet der sich zu dein http://as.khbr und sind die richtigen IPs und Protokolle in dein uns nicht genanntes DNS System hinterlegt? Und warum überhaupt eine DNS-Weiterleitung? Wohin? Wozu?Gebe ich nun dies in den Browser ein werde ich auf die Google Suche weitergeleitet. Gebe ich jedoch "http://as.khbr" ein lande ich wie gewünscht auf dem Host.
Ich hab dazu nichts helfendes gefunden, weil ich nicht genau weiß wonach ich suchen muss. Kann mir jemand eine konsistente Erklärung geben?
Funktionsweise eines DNS (System). Dazu auch schauen wie ein DNServer sich verhält und wie dein Client ihn Benutzt. Auch mal bei https://de.wikipedia.org/wiki/Zeroconf schauen. Und auch bei https://de.wikipedia.org/wiki/Domain_Name_System oder auch https://de.ryte.com/wiki/DNS_EintragGruß,
Peter
Hallo,
Wo ist in deinen Augen der DNS-Server falsch konfiguriert, wenn der Aufruf as.khbr nicht funktioniert, http://as.khbr aber schon? Das sind auch die beiden Eingaben, der er gemacht hat. Eine DNS-Weiterleitung ist in diesen Fällen regelmäßig erforderlich, schließlich ist davon auszugehen, dass ansonsten ein externer Forwarder befragt wird. Dass die richtige IP hinterlegt ist geht aus dem erfolgreichen Aufruf mit HTTP hervor. Mal nebenbei gefragt, welche Protokolle soll er im DNS hinterlegen und was kann daran falsch konfiguriert sein?
Ganz ehrlich, das ist sowohl überflüssig als auch überheblich. Dazu habe ich den Eindruck, dass DU dich entweder nicht mit der Ursprungsfrage oder mit DNS beschäftigt hast. Wenn man die Frage nicht versteht, kann man in meinen Augen vernünftig nachfragen oder sich raushalten.
Zitat von @Pjordorf:
Weil du 2-mal was anderes eingibst, dein DNS (System Intern) falsch Konfiguriert ist. Existiert überhaupt der nötige Eintrag im DNS um das zu tun was du uns (nicht deutlich) nennst, Was genau gibst du im ersten Fall denn ein, und wie unterscheidet der sich zu dein http://as.khbr und sind die richtigen IPs und Protokolle in dein uns nicht genanntes DNS System hinterlegt? Und warum überhaupt eine DNS-Weiterleitung? Wohin? Wozu?
Weil du 2-mal was anderes eingibst, dein DNS (System Intern) falsch Konfiguriert ist. Existiert überhaupt der nötige Eintrag im DNS um das zu tun was du uns (nicht deutlich) nennst, Was genau gibst du im ersten Fall denn ein, und wie unterscheidet der sich zu dein http://as.khbr und sind die richtigen IPs und Protokolle in dein uns nicht genanntes DNS System hinterlegt? Und warum überhaupt eine DNS-Weiterleitung? Wohin? Wozu?
Wo ist in deinen Augen der DNS-Server falsch konfiguriert, wenn der Aufruf as.khbr nicht funktioniert, http://as.khbr aber schon? Das sind auch die beiden Eingaben, der er gemacht hat. Eine DNS-Weiterleitung ist in diesen Fällen regelmäßig erforderlich, schließlich ist davon auszugehen, dass ansonsten ein externer Forwarder befragt wird. Dass die richtige IP hinterlegt ist geht aus dem erfolgreichen Aufruf mit HTTP hervor. Mal nebenbei gefragt, welche Protokolle soll er im DNS hinterlegen und was kann daran falsch konfiguriert sein?
Funktionsweise eines DNS (System). Dazu auch schauen wie ein DNServer sich verhält und wie dein Client ihn Benutzt. Auch mal bei https://de.wikipedia.org/wiki/Zeroconf schauen. Und auch bei https://de.wikipedia.org/wiki/Domain_Name_System oder auch https://de.ryte.com/wiki/DNS_Eintrag
Ganz ehrlich, das ist sowohl überflüssig als auch überheblich. Dazu habe ich den Eindruck, dass DU dich entweder nicht mit der Ursprungsfrage oder mit DNS beschäftigt hast. Wenn man die Frage nicht versteht, kann man in meinen Augen vernünftig nachfragen oder sich raushalten.
1
Hi,
darauf aufbauend: Tritt das bei jedem Browser auf?
Du kannst ja auch testweise mal keinen Browser nehmen, sondern z.B. einen telnet auf Port 80 machen.
Also und prüfen, ob das klappt oder nicht.
Auch andere Geräte getestet, Mobiltelefon im WLAN z.B.?
Bei Chrome scheint das zum Beispiel by Design zu sein, siehe:
https://stackoverflow.com/questions/36783705/force-chrome-to-follow-url- ...
https://stackoverflow.com/questions/36783705/force-chrome-to-follow-url- ...
darauf aufbauend: Tritt das bei jedem Browser auf?
Du kannst ja auch testweise mal keinen Browser nehmen, sondern z.B. einen telnet auf Port 80 machen.
Also
telnet as.khbr 80Auch andere Geräte getestet, Mobiltelefon im WLAN z.B.?
Die TLD .local ist weltweit reserviert für den mDNS Dienst und damit Tabu als TLD: https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Der kann also auch immer direkt ohne DNS Server Hostnamen auflösen und .local sollte man deshalb niemals als TLD verwenden.
Welche TLDs dafür geeignet sind ist u.a. hier erklärt:
https://www.heise.de/select/ct/2017/26/1513540412603853
.home.arpa ist z.B. so eine Standard konforme lokale TLD.
Eine pfiffige DNS Auflösung für heimische RFC 1918 IP Adressen (und alle anderen auch) ist z.B. nip.io
https://nip.io
Damit kann man dann ganz ohne eigenen DNS arbeiten. Die IP ist quasi im Hostnamen vorhanden.
Möglich auch das du DNS in der pfSense nicht richtig konfiguriert hast, denn ohne Anpassung fragt die Weiterleitung immer direkt die Root DNS Server.
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Der kann also auch immer direkt ohne DNS Server Hostnamen auflösen und .local sollte man deshalb niemals als TLD verwenden.
Welche TLDs dafür geeignet sind ist u.a. hier erklärt:
https://www.heise.de/select/ct/2017/26/1513540412603853
.home.arpa ist z.B. so eine Standard konforme lokale TLD.
Eine pfiffige DNS Auflösung für heimische RFC 1918 IP Adressen (und alle anderen auch) ist z.B. nip.io
https://nip.io
Damit kann man dann ganz ohne eigenen DNS arbeiten. Die IP ist quasi im Hostnamen vorhanden.
Möglich auch das du DNS in der pfSense nicht richtig konfiguriert hast, denn ohne Anpassung fragt die Weiterleitung immer direkt die Root DNS Server.
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Zitat von @Drohnald:
Hi,
darauf aufbauend: Tritt das bei jedem Browser auf?
Du kannst ja auch testweise mal keinen Browser nehmen, sondern z.B. einen telnet auf Port 80 machen.
Also und prüfen, ob das klappt oder nicht.
Auch andere Geräte getestet, Mobiltelefon im WLAN z.B.?
Hi,
Bei Chrome scheint das zum Beispiel by Design zu sein, siehe:
https://stackoverflow.com/questions/36783705/force-chrome-to-follow-url- ...
https://stackoverflow.com/questions/36783705/force-chrome-to-follow-url- ...
darauf aufbauend: Tritt das bei jedem Browser auf?
Du kannst ja auch testweise mal keinen Browser nehmen, sondern z.B. einen telnet auf Port 80 machen.
Also
telnet as.khbr 80Auch andere Geräte getestet, Mobiltelefon im WLAN z.B.?
Hi,
ich habe es mit Safari (Handy im WLAN), Firefox (PC im gleichen Netz) und Edge (PC im glichen Netz) ausprobiert. Bei allen das gleiche Verhalten.
Habe ich bei einem Browser "http://as.khbr" eingegeben, hat der Browser die google Suche gemacht jedoch in einem kleinen Balken gefragt ob er genau diese Adresse öffnen soll. (Sorry, das habe ich ob nicht so genau beschrieben.) Wenn ich dann auf diesen Balken klicke, kommt die gewünschte Seite vom gewünschten Host. Danach erreiche ich den Host dann aber auch über "as.khbr". Vermutlich, weil das in irgendeinem Cache liegt.
Mit besten Grüßen
Zitat von @aqui:
Die TLD .local ist weltweit reserviert für den mDNS Dienst und damit Tabu als TLD: https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Der kann also auch immer direkt ohne DNS Server Hostnamen auflösen und .local sollte man deshalb niemals als TLD verwenden.
Die TLD .local ist weltweit reserviert für den mDNS Dienst und damit Tabu als TLD: https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Der kann also auch immer direkt ohne DNS Server Hostnamen auflösen und .local sollte man deshalb niemals als TLD verwenden.
Danke für den Hinweis. Das habe ich gestern auch noch gelesen, weshalb ich die derzeitige ".local" Lösung nur als Not- und nicht dauerhafte Lösung sehe.
Eine pfiffige DNS Auflösung für heimische RFC 1918 IP Adressen (und alle anderen auch) ist z.B. nip.io
https://nip.io
Damit kann man dann ganz ohne eigenen DNS arbeiten. Die IP ist quasi im Hostnamen vorhanden.
https://nip.io
Damit kann man dann ganz ohne eigenen DNS arbeiten. Die IP ist quasi im Hostnamen vorhanden.
Das kannte ich noch nicht. Das gucke ich mir mal näher an.
Möglich auch das du DNS in der pfSense nicht richtig konfiguriert hast, denn ohne Anpassung fragt die Weiterleitung immer direkt die Root DNS Server.
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Die Hosts haben über DHCP die pfSense als standard DNS Server eingetragen. Auch hat die pfSense eine DNS Regel, wobei die Hosts nur die pfSense mit ihrer DNS Anfrage erreichen.
Das mit der Weiterleitung der Anfrage schaue ich mir aber noch mal genauer an.
Mit besten Grüßen
Bitte lies dir folgendes durch:
https://bugs.chromium.org/p/chromium/issues/detail?id=30636
Wie oben bereits gesagt, da ist am Beispiel Chrome das Verhalten erklärt und nachvollziehbar. Das hat ja nichts mit Netzwerkkommunikation zu tun, sondern passiert auf Applikationsebene.
Im Grunde liegt das Problem ja darin, dass du keine gültige URI, sondern nur einen FQDN eingibst und nun der Browser interpretieren muss, was du jetzt genau möchtest. Bei (aus Chrome-Sicht unbekannten TLDs) wird das als Suchanfrage interpretiert.
https://bugs.chromium.org/p/chromium/issues/detail?id=30636
Wie oben bereits gesagt, da ist am Beispiel Chrome das Verhalten erklärt und nachvollziehbar. Das hat ja nichts mit Netzwerkkommunikation zu tun, sondern passiert auf Applikationsebene.
Im Grunde liegt das Problem ja darin, dass du keine gültige URI, sondern nur einen FQDN eingibst und nun der Browser interpretieren muss, was du jetzt genau möchtest. Bei (aus Chrome-Sicht unbekannten TLDs) wird das als Suchanfrage interpretiert.
Bitte lies dir folgendes durch:
Der Thread in deinem Link wurde 2013 geschlossen und das Problem laut deinem ersten Link seit 2018 behoben.ich habe es mit Safari (Handy im WLAN), Firefox (PC im gleichen Netz) und Edge (PC im glichen Netz) ausprobiert. Bei allen das gleiche Verhalten.
Spätestens das zeigt, dass es nicht am Chromium liegen kann.Bei (aus Chrome-Sicht unbekannten TLDs) wird das als Suchanfrage interpretiert.
die TLD ist aber doch bekannt, der DNS kennt sie. Ob die im root-DNS ist oder nicht, spielt keine Rolle. fritz.box oder speedport.ip kann auch jeder Browser direkt öffnen.Weil du immer von "Weiterleitung" schreibst: Was genau ist denn konfiguriert in pfsense? Ich hätte einen Override-Eintrag erwartet https://docs.netgate.com/pfsense/en/latest/nat/reflection.html#dns-resol ...
Zitat von @redhorse:
Bitte lies dir folgendes durch:
https://bugs.chromium.org/p/chromium/issues/detail?id=30636
Wie oben bereits gesagt, da ist am Beispiel Chrome das Verhalten erklärt und nachvollziehbar. Das hat ja nichts mit Netzwerkkommunikation zu tun, sondern passiert auf Applikationsebene.
Im Grunde liegt das Problem ja darin, dass du keine gültige URI, sondern nur einen FQDN eingibst und nun der Browser interpretieren muss, was du jetzt genau möchtest. Bei (aus Chrome-Sicht unbekannten TLDs) wird das als Suchanfrage interpretiert.
Bitte lies dir folgendes durch:
https://bugs.chromium.org/p/chromium/issues/detail?id=30636
Wie oben bereits gesagt, da ist am Beispiel Chrome das Verhalten erklärt und nachvollziehbar. Das hat ja nichts mit Netzwerkkommunikation zu tun, sondern passiert auf Applikationsebene.
Im Grunde liegt das Problem ja darin, dass du keine gültige URI, sondern nur einen FQDN eingibst und nun der Browser interpretieren muss, was du jetzt genau möchtest. Bei (aus Chrome-Sicht unbekannten TLDs) wird das als Suchanfrage interpretiert.
Genau das ist auch meine Frage und ich find auch die essentielle Frage: Wo wird hier die Entscheidung getroffen was passiert. Macht das der Browser oder ist das eine Folge von DNS?
Mein Bauchgefühl sagt mir, dass das eine "Browserentscheidung" ist. Ich habe hier einen Host mit den Namen "Nextcloud". Das habe ich gerade so in den Firefox eingegeben und bin auf der Google-Suche gelandet. Jedoch hat mir Firefox den Hinweis gegeben, ob ich nicht "http://nextcloud" öffnen will. Klicke ich da drauf, lande ich auf dem Host. Bei Chrome lande ich nur bei der Google-Suche ohne Hinweis.
Zitat von @Drohnald:
Weil du immer von "Weiterleitung" schreibst: Was genau ist denn konfiguriert in pfsense? Ich hätte einen Override-Eintrag erwartet https://docs.netgate.com/pfsense/en/latest/nat/reflection.html#dns-resol ...
Weil du immer von "Weiterleitung" schreibst: Was genau ist denn konfiguriert in pfsense? Ich hätte einen Override-Eintrag erwartet https://docs.netgate.com/pfsense/en/latest/nat/reflection.html#dns-resol ...
Das oben beschriebene Verhalten ist sowohl beim DNS-Resolver wie auch dem DNS-Forwarder der pfSense zu beobachten, mit entsprechenden DNS override Einträgen. Das diese funktionieren sieht man ja daran, dass man mit "http://Host" auf dem Host landet. Auch ein ping funktioniert tadelos und gibt die IP des Hosts zurück. Was mich zur Vermutung führt, dass der Browser damit etwas zu tun hat und nicht eine Sache des DNS ist.
Zitat von @Drohnald:
Bitte lies dir folgendes durch:
Der Thread in deinem Link wurde 2013 geschlossen und das Problem laut deinem ersten Link seit 2018 behoben.Ist es aber anscheinend nicht, man kann es ja im Chrome nachstellen.
Bei (aus Chrome-Sicht unbekannten TLDs) wird das als Suchanfrage interpretiert.
die TLD ist aber doch bekannt, der DNS kennt sie. Ob die im root-DNS ist oder nicht, spielt keine Rolle. fritz.box oder speedport.ip kann auch jeder Browser direkt öffnen.Ja, aber bis es beim DNS-Server landet, muss der Browser ja entscheiden, ob es sich um einen Suchbegriff oder eine URL handelt. Das ist dann hinfällig, wenn man die vollständige URL verwendet, da der Browser dann ja weiß, dass es sich um keinen Suchbegriff handelt.
Zitat von @Siegfried36:
Genau das ist auch meine Frage und ich find auch die essentielle Frage: Wo wird hier die Entscheidung getroffen was passiert. Macht das der Browser oder ist das eine Folge von DNS?
Mein Bauchgefühl sagt mir, dass das eine "Browserentscheidung" ist. Ich habe hier einen Host mit den Namen "Nextcloud". Das habe ich gerade so in den Firefox eingegeben und bin auf der Google-Suche gelandet. Jedoch hat mir Firefox den Hinweis gegeben, ob ich nicht "http://nextcloud" öffnen will. Klicke ich da drauf, lande ich auf dem Host. Bei Chrome lande ich nur bei der Google-Suche ohne Hinweis.
Genau das ist auch meine Frage und ich find auch die essentielle Frage: Wo wird hier die Entscheidung getroffen was passiert. Macht das der Browser oder ist das eine Folge von DNS?
Mein Bauchgefühl sagt mir, dass das eine "Browserentscheidung" ist. Ich habe hier einen Host mit den Namen "Nextcloud". Das habe ich gerade so in den Firefox eingegeben und bin auf der Google-Suche gelandet. Jedoch hat mir Firefox den Hinweis gegeben, ob ich nicht "http://nextcloud" öffnen will. Klicke ich da drauf, lande ich auf dem Host. Bei Chrome lande ich nur bei der Google-Suche ohne Hinweis.
Ja, das sieht sehr danach aus. Wenn ich z.B. avnnrfgkfrnje.de eingebe, dann erhalte ich die Rückmeldung, dass die Webseite nicht erreichbar ist. Hier führt Chrome also keine Suche durch, obwohl es den DNS-Eintrag für avnnrfgkfrnje.de nicht gibt. Chrome fällt also m.E. anhand der TLD die Entscheidung, ob es sich um eine Suche oder eine URL mit fehlendem Protokoll handelt.
Moin,
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Zitat von @redhorse:
Ja, das sieht sehr danach aus. Wenn ich z.B. avnnrfgkfrnje.de eingebe, dann erhalte ich die Rückmeldung, dass die Webseite nicht erreichbar ist. Hier führt Chrome also keine Suche durch, obwohl es den DNS-Eintrag für avnnrfgkfrnje.de nicht gibt. Chrome fällt also m.E. anhand der TLD die Entscheidung, ob es sich um eine Suche oder eine URL mit fehlendem Protokoll handelt.
Ja, das sieht sehr danach aus. Wenn ich z.B. avnnrfgkfrnje.de eingebe, dann erhalte ich die Rückmeldung, dass die Webseite nicht erreichbar ist. Hier führt Chrome also keine Suche durch, obwohl es den DNS-Eintrag für avnnrfgkfrnje.de nicht gibt. Chrome fällt also m.E. anhand der TLD die Entscheidung, ob es sich um eine Suche oder eine URL mit fehlendem Protokoll handelt.
Das ist finde ich ziemlich suboptimal und irgendwie auch übergriffig, dass sofort die Google-Suche vom Browser benutzt wird. Ist nur die Frage was die Entscheidungsgrundlage ist. Ist es eine TLD Liste im Browser wonach dieser entscheidet?
Zitat von @Lochkartenstanzer:
Moin,
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Moin,
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Da ist eine Idee! Das mache ich mal.
Zitat von @Siegfried36:
Da ist eine Idee! Das mache ich mal.
Zitat von @Lochkartenstanzer:
Moin,
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Moin,
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Da ist eine Idee! Das mache ich mal.
Aber vorher jedes Mal alle Caches (Browser, DNS, etc.) löschen.
lks
Zitat von @Siegfried36:
Da ist eine Idee! Das mache ich mal.
Zitat von @Lochkartenstanzer:
Moin,
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Moin,
Laß doch einfach einen Wireshark mitlaufen.
Dann siehst Du, ob der Browser erst den DNS fragt oder gleich Google.
lks
Da ist eine Idee! Das mache ich mal.
Ich habe jetzt mal von meinem Laptop "Nextcloud" in Chrome eingegeben und das dann mit Wireshark mitgeschnitten.
Ich versuche den jetzt mal die ersten zu interpretieren, aber korrigiert mich gerne, wenn ich falsch liege.
Die Zeilen 3 - 6 zeigen richtig an, dass meine DNS Anfrage an meine pfSense (DNS Resolver) geht. Von der bekomme ich dann die richtige IP (192.168.5.2) für den Host.
In den Zeilen 7 - 9 versucht dann mein Laptop Verbindung zu dem Host aufzunehmen, was auch gelingt, zu erkennen am ACK!?
Dann in Zeile 10 tauchen auf einmal ne IPv6 Adressen auf. Die linke (source) ist wohl eine von google, die rechte eine von Vodafone (ich bin bei Vodafone).
In Zeile 12 kommt die erste HTTP Anfrage an den Host von meinem Laptop.
Wenn man weiter nach unten geht tauchen beide IP Version weiterhin auf, jedoch kriege ich am Ende die Google-Suche im Browser präsentiert.
Zitat von @Siegfried36:
Das ist finde ich ziemlich suboptimal und irgendwie auch übergriffig, dass sofort die Google-Suche vom Browser benutzt wird. Ist nur die Frage was die Entscheidungsgrundlage ist. Ist es eine TLD Liste im Browser wonach dieser entscheidet?
Das ist finde ich ziemlich suboptimal und irgendwie auch übergriffig, dass sofort die Google-Suche vom Browser benutzt wird. Ist nur die Frage was die Entscheidungsgrundlage ist. Ist es eine TLD Liste im Browser wonach dieser entscheidet?
Spontan würde ich sagen, dass IANA hier die Grundlage ist:
https://www.iana.org/domains/root/db
Ich habe es mal mit ein paar exotischen TLDs ausprobiert, die haben alle nicht zur Google-Suche geführt.
Zitat von @redhorse:
Spontan würde ich sagen, dass IANA hier die Grundlage ist:
Zitat von @Siegfried36:
Das ist finde ich ziemlich suboptimal und irgendwie auch übergriffig, dass sofort die Google-Suche vom Browser benutzt wird. Ist nur die Frage was die Entscheidungsgrundlage ist. Ist es eine TLD Liste im Browser wonach dieser entscheidet?
Das ist finde ich ziemlich suboptimal und irgendwie auch übergriffig, dass sofort die Google-Suche vom Browser benutzt wird. Ist nur die Frage was die Entscheidungsgrundlage ist. Ist es eine TLD Liste im Browser wonach dieser entscheidet?
Spontan würde ich sagen, dass IANA hier die Grundlage ist:
Das ist aber dann vielleicht nicht die ganze Wahrheit, denn wenn ich keine TLD nehme, kommt ja auch die google-Suche.
Zitat von @Siegfried36:
Das ist aber dann vielleicht nicht die ganze Wahrheit, denn wenn ich keine TLD nehme, kommt ja auch die google-Suche.
Das ist aber dann vielleicht nicht die ganze Wahrheit, denn wenn ich keine TLD nehme, kommt ja auch die google-Suche.
Ja, ohne TLD und Protokoll sind wir ja weit weg von einer URL. Dann müsstest du im Zweifel die Suche abklemmen.
