Domainname vs DNS vs shared hosting Verständnisproblem

[dexter]

Moin, ich hätte mal gern ein Verständnisproblem. Die Funktionsweise vom DNS ist mir im Groben klar, aber...

geileseite.tld liegt auf der IP 111.111.222.222
scheissseite.tld liegt aber auf der selben IP, so wie bei shared Hosting üblich, dass um die 100 oder mehr Domains auf einer IP rumliegen.

Woher weiss jetzt das DNS, dass ich auf geileseite.tld will und nicht auf scheissseite.tld?

 

[Fetzi]

Tatsächlich eine interessante Frage die mich auch interessieren würde.
Auch nach längerer Recherche steige ich nicht zu 100% durch.
Machen das die internen nameserver in Kombination mit den Webservern die halt nur auf bestimmte Adressen antworten?

 

[one]

Das wird serverseitig gesplittet, anders geht es ja nicht. Wie das genau funktioniert steht im Groben zum Beispiel dort:

Eine IP Adresse und mehrere WEB Domains

Nun möchte diesen Server für mehrere WEB-Domains nutzen. Dabei sollten alle WEB-Domains über den Port 80 laufen, damit die Benutzer wie gewohnt die ...

administrator.de

Entweder über virtuelle Hosts mit entsprechenden Angaben, in welchem Verzeichnis das Ziel welcher Domain liegt oder über einen Reverse Proxy. Das eigentliche DNS-Verzeichnis kennt nur die IP. Wie so ein Telefonbuch, wo hinter jedem Namen eine Nummer steht.

 

[dexter]

Das wird serverseitig gesplittet, anders geht es ja nicht. Wie das genau funktioniert steht im Groben zum Beispiel dort:

Irgendwie nicht. Dort steht grob, ob und wie man das an 'nem Webserver einstellt.

Das eigentliche DNS-Verzeichnis kennt nur die IP.

Genau da ist mein Verständnisproblem. Woher weiss die IP 111.111.222.222 dass ich auf geileseite.tld will?

 

[Mäxchen]

Wenn ich es richtig verstehe, weiß der DNS das nicht.
Ich stelle es mir ungefähr so vor: Wenn dein Rechner beim DNS nach der IP gefragt hat und diese auch bekommen hat, stellt dein Rechner an diese IP eine Anfrage, in der dann drin steht, was denn bitte angezeigt werden soll. Die IP sagt nur wohin diese Anfrage geht, aber nicht, was in der Anfrage steht. Ansonsten könnte eine Domain ja auch keine Unterseiten haben.

 

[one]

Genau da ist mein Verständnisproblem. Woher weiss die IP 111.111.222.222 dass ich auf geileseite.tld will?

Genau das hatte ich beschrieben. Der Server verteilt das. Er erkennt von welcher Domain die Anfrage kommt und verteilt sie entsprechend. Die Domain wird also unabhängig vom DNS durchgereicht.

 

[dexter]

Ich stelle es mir ungefähr so vor: Wenn dein Rechner beim DNS nach der IP gefragt hat und diese auch bekommen hat, stellt dein Rechner an diese IP eine Anfrage, in der dann drin steht, was denn bitte angezeigt werden soll.

Ah, das klingt sinnvoll.

 

[Fetzi]

Hier ist einiges erklärt:

How to Host Multiple Websites on One Server

This tutorial covers how to host multiple websites on one server using Apache & NGINX.

www.cloudpanel.io

Wenn ich das richtig verstanden habe, dann hat das nichts mit dem DNS zu tun, sondern wird einfach in der config des Webservers geregelt.
D.h. Domain1.de und Domain2.de zeigen auf ein und den selben Server der Server selbst "verteilt" die Anfragen entsprechend der Domains und gibt die Seiten aus.
Korrigiert mich bitte wenn das nicht stimmt.
Ob und wie es mit unterschiedlichen Webservern gehen würde weiß ich nicht.

 

[one]

Das ist genau das, was ich schrob und so funktioniert das.

Bei verschiedenen Webservern mit der gleiche IP wird das in der Regel dann immer per Reserve-Proxy erledigt.

Stellt euch einfach einen Paketboten vor. Der kennt auch nur Euren Namen, die Straße und die Hausnummer. Wo genau er hin muss, erfährt er durch das Drücken der Klingel und (!) dass daraufhin auch jemand öffnet.

Würden Domains so funktionieren wie heute die Paketzustellung, wären 90% der Seiten nicht erreichbar, weil der Bote nur klingelt und das Paket dann vor die Tür schmeißt.

 

[drfuture]

@one, hat das schon sehr schön und richtig erklärt.

Eventuell noch einmal auf andere Art:

Der Webbrowser stellt eine Anfrage was er sehen möchte. Also die Seite x von Internetseite y. Das (http Header) sieht gekürzt so aus:

GET /beispielseite.html HTTP/1.1
HOST: beispieldomain.tld
Accept-Language: de
User-Agent: Mozilla/5.0 (iPhone; CPU .......

Die IP hilft nun dabei im weltweiten Netzwerk den richtigen Computer zu finden an den obige Anfrage geht.
Kommt diese Anfrage dann am Computer von Beispieldomain.tld an kümmert sich das Programm, das diese Anfrage entgegen nimmt (Webserver) darum diese Anfrage korrekt zu beantworten.

Dabei ist es dann technisch gesehen egal ob auf dem Server 1 Webpräsenz einer Domain liegt oder 100 Domains.
1 Webpräsenz kann ja auch unter 4 Adressen erreichbar sein....
Ich kann unter 1 "Seite" wie hier im ngb die index.php ein ganzes Forum zur Verfügung stellen da sich Programme darum kümmern dass in der index.php am Ende immer andere Inhalt steht / bzw. Eben richtiger bei der Anfrage an den Webserver an die Adresse ngb.to/index.php Antwort der Webserver mit dem Text z.b. dieses Beitrags inklusiv der restlichen Seite.

Die Infos den ersten 2 Zeilen im http Header werden (ebenso wie ein paar andere Infos) nur dazu verwendet die richtige Antwort zu liefern.

 

[dexter]

Die Beschreibung von Mäxchen hat mir schon geholfen, da genau mir nicht klar war, dass (grob verallgemeinert) der DNS nur den Server findet und meine "echte" Abfrage dann "nochmal" an den Server geschickt wird (und nicht nur IP-XY).

Ob da jetzt ein reverse proxy oder was auch immer für ein Hokuspokus im Spiel ist, wo ich dann wieder schauen muss, was der macht und/oder was das ist...

 

[alter_Bekannter]

Genau da ist mein Verständnisproblem. Woher weiss die IP 111.111.222.222 dass ich auf geileseite.tld will?

Vom http header, siehe Post von drfuture.

Einer von vielen Gründen warum ssl so wichtig ist, keine andere Schicht enthält wirklich security. Beim Shared hosting muss man halt dem Anbieter vertrauen.

Ich will damit nochmal mit Nachdruck betonen, das alles was daran etwas dumm und unsicher klingt wirklich so unsicher ist. Bei IP verlässt sich auch jeder im Netzwerk nur blind darauf, das alle anderen ehrlich sind. jeder kann ARP Pakete mit beliebigem Inhalt verschicken und der default ist diese einfach zu akzeptieren. Hier ist die Konvention diese nicht zu routen

 

[one]

SSL ist ja nicht das Thema. Aber wenn ich immer wieder lese, was die Leute so als Virenscanner einsetzen, fällt mir gar nichts ein. Es gibt ja nicht nur ein Schlangenöl, welches auf SSL-Inspection setzt. Da wird dann anschließend ein eigenes (vom Scanner) und selbst erstelltes Zertifikat untergeschoben und die Welt ist in Ordnung.

Das ist hier aber wie gesagt am Thema vorbei.

Ein interessantes Thema ist es aber dennoch. Daher mein "thumbup" für den Beitrag. Könnte man mal in einem separatem Thread behandeln. 👍Ich befürchte nur leider, dass direkt auf der ersten Seite Linux empfohlen wird und dann wäre das Thema für mich tot.

 

[dexter]

Vom http header, siehe Post von drfuture.

Uhm. Langsam dämmert's wirklich.
Um das DAU-kompatibel zu formulieren; verstehe ich das nun SO halbwegs verallgemeinert richtig:

• Ich rufe im Browser geileseite.tld auf
• der Browser schickt die URL an 'nen DNS, der sagt, die Seite liegt auf 111.111.222.222 und incl. der http-Header-daten geht die Anfrage weiter nach 111.111.222.222
• dort wird dann anhand der http-header sortiert WO auf 111.111.222.222 die geileseite rumliegt.
• und mir meine angeforderten Daten zurückgeschickt

(Betonung liegt auf Daukompatibel, evtl. semifalsche oder semikorrekte Feinheiten bitte übersehen)

 

[alter_Bekannter]

Richtig, DNS macht nur Auflösung Name zu IP.

Wenn dann die Anfrage am Webserver ankommt. Dieser legt fest auf welche IP-Addressen und Ports er hört, letzteres ist ein free for all, wer zuerst kommt gewinnt. Alle anderen bekommen die Meldung der Port (von der IP) ist schon in Gebrauch vom Betriebssystem. Weil auch mehrere IPs auf einem Rechner liegen können. IPs werden nach MAC Adressen gemappt über das ARP Protokoll dessen einzige Sicherheit ist das Netzwerke üblicherweise so konfiguriert sind das sie keine Ansagen außerhalb des Netzes entgegen nehmen.

Was danach kommt entscheidet das Programm bei dem die Pakete dann ankommen. Was hier im Beispiel dann üblicherweise Port 443 von 111.111.222.222 worauf ein Webserver lauscht und der antwortet dann abhängig davon was seine vhost configs sagen. Da kann man übrigens auch den Port festlegen.

Beispiele ohne SSL:

VirtualHost Examples - Apache HTTP Server Version 2.4

Auf dem non ssl default port 80.

 

[GoPro]

Moin Leude!

Ich bin gerade auf den Weg ins Bett und kann das jetzt nicht auf die Schnelle erklären. Ist auch schon 20 Jahre her.
Es gibt ja nicht nur einfach IP-Adressen und Ports, sondern es gibt ja auch Netzwerke, bzw. die IP-Adresse hat einen Netz- und einen Hostanteil.
Also mal kurz in den Raum geworfen: SUPERNETTING. Als Gegenteil zum Subnetting.

 

[drfuture]

Hat mit dem Thema hier 0 zu tun, bitte nicht verwirren

@dexter list sich sehr gut. Außer (kann aber auch so gemeint sein) das das http Datenpaket nicht zum dns wandert. Erst wird der dns angefragt und dann geht die Anfrage an IP xxxx

 

[Fetzi]

Mit den Ports ist auch verwirrend, da natürlich beim shared hosting via einer IP und einem Port auf einem Webserver mehrere Seiten und damit domains gehostet werden.
Ich würde das so verstehen:
Anfrage Webbrowser (erstmal geht es nur um die Domain Auflösung, damit die Verbindung mit dem richtigen Server aufgebaut wird)
DNS löst IP auf (hier zeigen mehrere Domains auf eine IP mit dem gleichen Port), damit die Verbindung mit dem richtigen Server auf dem der Webserver läuft aufgebaut wird
Browser fragt eine Seite ab. Der webserver liefert die Seite, hierbei liegen die Webseiten mehrerer Domains auf einem Webserver. Welche Seite geschickt wird entscheidet der Webserver.

Mir ist noch nicht so ganz klar ob und wie es funktioniert wenn auf einem Server mehrere Webserver laufen z.B. NGINX, Apache, IIS.
Wahrscheinlich gehen dann aber auch alle Anfragen auf alle webserver und die Software selbst erkennt von welcher Domain sie die Seiten hat.

 

[KingJamez]

Mir ist noch nicht so ganz klar ob und wie es funktioniert wenn auf einem Server mehrere Webserver laufen z.B. NGINX, Apache, IIS.
Wahrscheinlich gehen dann aber auch alle Anfragen auf alle webserver und die Software selbst erkennt von welcher Domain sie die Seiten hat.

Hier ein praktisches beispiel einer Konfiguration.

# höre auf eintrittspunkt (http/ https)
- "traefik.http.routers.frontend-abc.entrypoints=web_secured"
# wenn die domain in der anfrage
- "traefik.http.routers.frontend-abc.rule=HostRegexp(`deinedomain.com`)"

In dem fall nutze ich traefik als reverse-proxy der auf verschiedene docker-container (alle port 80) verteilt. Die konfiguration wird in den einzelnen containern eingetragen, der container registriert sich am reverse proxy.
Der RP kennt also alle domains "hinter sich" und gibt die anfrage dann auf den entsprechenden Container weiter.

 

[drfuture]

Die Kombination aus IP:Port kann immer nur von 1 Anwendung verwendet werden.
Insofern man nun auf die Idee kommt mehrere Webserver auf einem System betreiben zu wollen hat man im Grunde 2,5 Möglichkeiten:

Nun könnte man zwar den Webserver auf einen beliebigen Port horchen lassen - in der Realität versucht es zumindest ein Webbrowser aber nur auf Port 80 für http und 442 für https.
insofern der Webserver für irgend eine interne Anwendung da ist kann man den Port natürlich frei vergeben.

Daher:

1) mehrere IPs auf einen Host zuweisen und den jeweiligen Diensten sagen welche IP er verwenden soll.
2) 1 Webserver / Dienst horcht auf die externe IP und der zweite Webserver lauscht auf "localhost" - die interne loopback IP des Clients. Dann kann ich Anfragen vom Webserver der auf die Externe IP horcht je nach Anfrage an den 2. Webserver in Folge weiterleiten
2.5) Die Weitere Option ist dann im Grunde das was KingJamez genannt hat - wobei das eben keine ganze Lösung ist. Eine Docker-Instanz / ein Container ist im Grunde eine Art PC im PC (Ja ist in diesem Fall grob Falsch vereinfacht) und die Instanz bekommt eine eigene interne IP auf dem Computer. Dabei sind wir wieder bei Lösung 2