Wenn ich z.B. ne TCP Verbindung zu example.com aufbaue, wird zuerst über das DNS die IP von example.com ermittelt. Aber wenn ich nun eine Verbindung zu test.example.com aufbaue, kann ja dies ja die selbe IP-Adresse haben (ist ja z.B. bei den meisten Webservern so). Aber woher weiß der Server nun, dass ich auf test.example.com und nicht example.com zugreife? Weder im IP noch im TCP Header steht der Domainname drin, nur die IP, die ja gleich ist ... Danke schon mal :)
Jonathan K. schrieb: > Wenn ich z.B. ne TCP Verbindung zu example.com aufbaue, wird zuerst über > das DNS die IP von example.com ermittelt. Aber wenn ich nun eine > Verbindung zu test.example.com aufbaue, kann ja dies ja die selbe > IP-Adresse haben (ist ja z.B. bei den meisten Webservern so). Aber woher > weiß der Server nun, dass ich auf test.example.com und nicht example.com > zugreife? Weder im IP noch im TCP Header steht der Domainname drin, nur > die IP, die ja gleich ist ... > Genau - und Tcp 'interessiert' auch nur die IP, DNS ist in diesem Fall nur eine optionale Merkhilfe. Falls es um HTTP geht - was über Tcp sitzt - da gibt's dann den HOST-Header, der dem HTTP-Server den Zielhost mitteilt...
Auf dem Server laufen unter Apache verschiedene Virtuelle Server. Kommt eine Anfrage über einen DNS Server rein wird vom DNS Server mitgeteilt welche URL angefragt wurde. Gibt es nun einen Virtuellen Server der auf diese Adresse hört wird die Anfrage entsprechend behandelt. Dazu gibt es noch einen Standard Server, dieser behandelt alle Anfragen die nicht von einem virtuellen behandelt werden. Gruß René
René S. schrieb: > Auf dem Server laufen unter Apache verschiedene Virtuelle Server. Kommt > eine Anfrage über einen DNS Server rein wird vom DNS Server mitgeteilt > welche URL angefragt wurde. Gibt es nun einen Virtuellen Server der auf > diese Adresse hört wird die Anfrage entsprechend behandelt. Dazu gibt es > noch einen Standard Server, dieser behandelt alle Anfragen die nicht von > einem virtuellen behandelt werden. das ist absoluter Blödsinn. apache ist http und da gibts nen host header feld. dns und apache haben nichts miteinander zu tun.
Jan L. schrieb: > Genau - und Tcp 'interessiert' auch nur die IP Also, gibt es sozusagen keine Subdomains, wenn der DNS-Server mit der gleichen IP antwortet? Jan L. schrieb: > HOST-Header Also wenn ich ne HTTP Verbindung zu test.example.com aufbaue ohne das Host-Feld zu senden, weiß der Server nicht, dass ich test.example.com haben möchte? René S. schrieb: > wird vom DNS Server mitgeteilt > welche URL angefragt wurde Ich weiß nicht, wie ich mir das vorstellen muss. Bei vielen Hostern ist ja der DNS vom Webserver getrennt. D.h. ich "frage" zuerst beim DNS-Server von example.com, welche IP test.example.com hat. Dieser "sagt" mir die IP sei z.B. 1.2.3.4. Hier sende ich die URL ja nicht mit, die steht nur im HTTP Header. Wenn ich dich richtig verstehe, teilt der DNS Server dem Webserver mit, dass einer mit der IP 3.2.5.9 wissen wollte, welche IP test.example.com hat. Wenn ich nun mit meiner IP 3.2.5.9 auf den Webserver (1.2.3.4) zugreife, weiß dieser nun, dass ich auf test.example.com zugreife. Richtig so? Wenn ja wäre dies aber nicht sehr klug das so zu machen, oder? Denn die IP-Adressen werden ja gecached, also nicht jedes mal neu beim DNS Server erfragt. Außerdem könnte es ja zu Verwechselungen bei parallelen Anfragen kommen ..
Das stichwort dazu ist der SNI (ServerNameIdentifier). Es laufen verschiedne Vhosts auf einem Server mit verschiedenen Namen (ServerName bei apache) und durch schon genannte header weiß der Apache, welcher Vhost der richtige ist. Nicht verwirren lassen. SNI ist nur mit TLS verfügbar. Es funktioniert aber auch ohne durch die Header.
Jonathan K. schrieb: > Wenn ich dich richtig verstehe, teilt der DNS Server dem Webserver mit, > dass einer mit der IP 3.2.5.9 wissen wollte, welche IP test.example.com > hat. Nein, das verstehst Du nicht richtig. Der DNS-Server weiß nichts vom Webserver und teilt dem auch nichts mit. Der DNS-Server teilt Deinem Webbrowser mit, wie die IP-Adresse des Webservers lautet. Und wenn Du (bzw. Dein Webbrowser) das http-Protokoll nicht richtig implementierst, bekommst Du nicht das zu sehen, was Du erwartest.
Den unterschied der subdomains (test. bla. usw.) macht z.B. ein Apache Server über vhosts. oder falls als reverseproxy verwendet als redirector zum entsprechendem Webserver bei .example.com Beim hoster musst du auch die subdomains anlegen sonst werden die nicht vom DNS aufgelöst.
Der DNS-Server sagt nicht nur dem anfragenden Rechner die IP mit sondern leitet die Anfrage direkt an den angefragten Server weiter. Dabei teilt der DNS Server dem angefragten Server auch die eigentlich angefragte URL mit. Der DNS Server selbst kennt die zu den URL's gehörenden IP's. Dafür wird in der Domainzonenverwaltung des Providers ein entsprechnender A Record für jede Domain angelegt, heißt also zu einer IP Adresse kann es viele Domains geben. Gruß René
René S. schrieb: > Der DNS-Server sagt nicht nur dem anfragenden Rechner die IP mit sondern > leitet die Anfrage direkt an den angefragten Server weiter. Dabei teilt > der DNS Server dem angefragten Server auch die eigentlich angefragte URL > mit. Kannst du ein Beispiel dafür bringen? Ich kenne kein DNS Server der sich gleich zu dem angefragten Server verbindet oder irgendetwas weiterleitet.. Das ist Quatsch
Also nochmal von vorne Im Browser gebe ich "sub.domain.de" ein. in dem Moment wo ich enter drücke wird versucht die Domain aufzulösen Ich frage jedem mir bekannten DNS Server nach der Domain "sub.domain.de" Also frage ich beim Root DNS nach . .de. / den zuständigen server erfahre ich vom RootDNS der Antwortet z.b. mit einem NS Record 1.1.1.1 Dann frage ich bei der DENIC nach "sub.domain.de" die antwortet keine Ahnung ich habe aber ein NS-Record für domain.de - 1.1.1.2 Dann frage ich bei diesen Server nach "sub.domain.de" Der Antwortet Ja! "sub.domain.de" kenn ich A-Record 1.1.1.3 Jetzt Baut mein Browser ein Http/TCP was auch immer mit 1.1.1.3 Auf wenn das Routing stimmt kommen die Pakete da an wo sie sollen Erst jetzt kommt der Webserver ins spiel, der auch fragt wie die aufgerufene URL war, dann wird der Inhalt aus dem Jeweiligem vHost verarbeitet und als Content rausgeschickt, der rest ist selbst erklärend
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Der DNS-Server weiß nichts vom > Webserver und teilt dem auch nichts mit. Ja sonst wäre das ganze System ein bissl undurchdacht. Aber wie muss dann Renes Antwort verstehen? Oder ist diese, wie Marc geschrieben hat, einfach nur falsch? Finn S. schrieb: > SNI ist nur mit TLS verfügbar. Es funktioniert > aber auch ohne durch die Header. Also am Ende läuft es bei HTTP immer auf das Host-Field oder bei TLS auf SNI hinaus .. ? Simon K. schrieb: > Im Browser gebe ich "sub.domain.de" ein. > in dem Moment wo ich enter drücke wird versucht die Domain aufzulösen > > Ich frage jedem mir bekannten DNS Server nach der Domain "sub.domain.de" > Also frage ich beim Root DNS nach . > > .de. / den zuständigen server erfahre ich vom RootDNS der Antwortet z.b. > mit einem NS Record 1.1.1.1 > > Dann frage ich bei der DENIC nach "sub.domain.de" die antwortet keine > Ahnung ich habe aber ein NS-Record für domain.de - 1.1.1.2 > > Dann frage ich bei diesen Server nach "sub.domain.de" > > Der Antwortet Ja! "sub.domain.de" kenn ich A-Record 1.1.1.3 > > Jetzt Baut mein Browser ein Http/TCP was auch immer mit 1.1.1.3 Auf wenn > das Routing stimmt kommen die Pakete da an wo sie sollen Ja genau wenn ich jetzt aber 1.1.1.2 frage, wo ist denn "sub2.domain.de", dann sagt dieser ebenfalls 1.1.1.3 In beiden Fällen baue ich dann eine TCP-Verbindung zu 1.1.1.3 auf, ohne dass dieser Server weiß, auf welche Subdomain ich zugreife (bis zum TCP Header) ..
ServerName Eigenschaft: http://httpd.apache.org/docs/2.2/de/vhosts/name-based.html Oder falls SSL/TLS verwendet wird (ist aber ähnlich): https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI Oder hier: http://stackoverflow.com/questions/758351/virtualhost-for-wildcard-subdomain-and-static-subdomain Auf jeden Fall haben diese Subdomains nichts mehr mit DNS zutun.
:
Bearbeitet durch User
Finn S. schrieb: > Kannst du ein Beispiel dafür bringen? Ich kenne kein DNS Server der sich > gleich zu dem angefragten Server verbindet oder irgendetwas > weiterleitet.. > Das ist Quatsch Gut sagen wir nicht Weiterleiten. Der DNS verkoppelt mehr oder weniger die abgefragte URL mit der dazugehörigen IP und veranlasst mit dem rückgesendeten Paket das anfragende Rechner die Ip kontaktiert. Es Kann aber z.B. bei Nutzunmg von ENUM eine Anwahl eines über Telefon erreichbaren Netzteilnehmer durchgeführt werden, dann vermittelt der DNS tatsächlich die Daten. In lokalen Netzen kann der DNS aber auch mithelfen von Intern kommende Anfragen an Interne Server die aber auch von außen erreichbar sind ins lokale Netz umzuleiten. Das macht der DNS Server allerdings nicht allein. Dazu braucht's einen Proxy der mit dem DNS Server zusammenarbeitet. Gruß René
Simon K. schrieb: > Ich frage jedem Simon K. schrieb: > Dann frage ich Simon K. schrieb: > Dann frage ich bei Simon K. schrieb: > fragt wie die > aufgerufene URL Bei der ganzen Fragerei buckelt es mir die Zehennägel hoch, da weiß ich nicht wo ich anfangen soll :/ René S. schrieb: > DNS verkoppelt René S. schrieb: > weniger genau, ein DNS tut nichts weiter als Auskunft zu erteilen "zu der von dir gefragten serveradresse gehört die IP bla" sonst Garnichts, evtl. sagt er dir noch die Adresse kenn ich nicht, ende kein gekoppel oder sonst was.
René hör bitte auf mit diesem unfug, alles was du hier schreibst ist schlicht falsch.
@Rene Nein Alles was du über DNS zu wissen glaubst spiegelt nicht die technischen Begebenheiten wieder. DNS kann man sich als Laie am ehesten als Wörterbuch vorstellen. NAME <--> IP Die einzigste Aufgabe des DSN Systems besteht darin "Name" in IPs zu verwandeln.(oder auch Ip in Namen). Es wird nichts weitergeleitet, vermittelt oder verknüpft mit dem Ziel der Anfrage. Das einzigste was DNS Server machen ist andere DNS Server zu fragen die ggf. besser geeignet sind die richtige Antwort zu liefern. @Jonathan bei HTTP Anfragen steht im headder dieser Anfrage drinnen was angefragt wird. Damit kann bei gleichen Ip der Webserver verschiedene Domain oder auch Subdomains auseinander halten wenn sie die gleiche IP haben. ein Einstieg: https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Funktionsweise Die Unterscheidbarkeit ist also teil des HTTP Protokolls.
Marc D. schrieb: > Die Unterscheidbarkeit ist also teil des HTTP Protokolls. Ahh alles klar, für Mitleser also zusammengefasst: - der Client muss dem Server mitteilen, auf welche Domain zugegriffen wird - bei HTTP über das Host-Feld - bei TLS über SNI - ansonsten muss man die geforderte Domain selbst dem Server mitteilen
:
Bearbeitet durch User
Marc S. schrieb: > René hör bitte auf mit diesem unfug, alles was du hier schreibst ist > schlicht falsch. Bevor du hier was von Unfug schreibst informiere dich bitte mal ausführlich über das Domain Name System. DNS kann weit mehr als reine Namensauflösung und vor allem in großen lokalen Netzen sowie bei IP Telefonie Providern erledigen die DNS Server Aufgaben die mit der Ursprungsidee des Namensauflösung eigentlich nichts mehr zu tun haben. Ein Anfang wäre mal bei Wikipedia den Bereich Erweiterung der Seite über da Domain Name System incl. der RFC's zu lesen Gruß René
Jonathan K. schrieb: > Ahh alles klar, für Mitleser also zusammengefasst: > > - der Client muss dem Server mitteilen, auf welche Domain zugegriffen > wird > - bei HTTP über das Host-Feld > - bei TLS über SNI um genau zu sein, wird bei https erst der Name über SNI übertragen und dann noch einmal im Host-Feld vom http. Das SNI wurde später eingeführt, wo man gemerkt hat das es gar nicht möglich ist für verschiedene Domains Verschiedene Zertifikate an den Client zu schicken.
> mit der
Ursprungsidee des Namensauflösung eigentlich nichts mehr zu tun haben.
Also das Wikipedia, das ich benutze sagt, die Erweiterungen haben aber
mit dem beschriebenen Scenario "Browser ruft Webserver" auch nichts zu
tun. Ok, DNS liefert heute auch andere "Services", aber eben immer noch
DNS.
Der DNS liefert lediglich die IP der physikalischen Maschine, auf der der Webserver läuft, der die Domain beherbergt. Im GET-Statement des HTTP-Requests, den der Browser an diese IP richtet, steht die (Sub-) Domain, aus der ein Dokument geladen werden soll. Ruft man z.B. einen Apache mit mehreren VHosts lediglich per IP (also ohne Angabe einer Domain), erhält man immer die Startseite des zuerst eingerichteten VHost - selber gerde vor einigen Tagen ausprobiert.
:
Bearbeitet durch User
René S. schrieb: > Marc S. schrieb: >> René hör bitte auf mit diesem unfug, alles was du hier schreibst ist >> schlicht falsch. > > Bevor du hier was von Unfug schreibst informiere dich bitte mal > ausführlich über das Domain Name System. DNS kann weit mehr als reine > Namensauflösung und vor allem in großen lokalen Netzen sowie bei IP > Telefonie Providern erledigen die DNS Server Aufgaben die mit der > Ursprungsidee des Namensauflösung eigentlich nichts mehr zu tun haben. > Ein Anfang wäre mal bei Wikipedia den Bereich Erweiterung der Seite über > da Domain Name System incl. der RFC's zu lesen > > Gruß René Nichts desto Trotz sind deine Aussagen allesamt falsch. Auch mit allen Erweiterungen ist ein DNS Server Dienst eine Art Verzeichnisdienst, welcher auf eine Anfrage eine entsprechende Antwort liefert. Mehr nicht. Man kann sehr wohl einen erweiterten DNS Server mit einer Telefonnummer füttern. Der Server wird höchstens mit einer URI antworten, vermitteln wird er nichts. Wenn ich im Telefonbuch nach einer Telefonnummer suche und gefunden habe, brauche ich dennoch einen weiteren Dienst (Telefon, Handy) um den Anruf zu tätigen. Vielleicht solltest du dich zuerst selbst mal über DNS informieren und die von dir vorgeschlagenen RFCs mal lesen und verstehen...
Frank E. schrieb: > Im GET-Statement des HTTP-Requests, den der Browser an diese IP richtet, > steht die (Sub-) Domain, aus der ein Dokument geladen werden soll. Nein, sofern mit dem GET-Statement nur die erste Zeile gemeint ist, also
1 | GET /index.html HTTP/1.1 |
Erst danach wird die Domain im Host-Feld gesendet, im ganzen sieht es dann z.B. so aus:
1 | POST / HTTP/1.1 |
2 | Host: google.de |
3 | Cookie: irgend=was; |
4 | |
5 | hallo=2&id=82&bla=bla |
Jonathan K. schrieb: > Nein, sofern mit dem GET-Statement nur die erste Zeile gemeint ist, also Ok, ich korrigiere: "Im HTTP-Header" steht der Host bzw. VHost also die Domain bzw. Subdomain. Beim DNS sind alle Subdomains (sofern sie auf der gleichen Maschine liegen) mit der gleichen IP hinterlegt.
Muss man denn alles immer so schwer erklären? Du willst die Seite abc.example.com aufrufen: DNS: 1. Anfrage für .com PC → Root-Server: Wer verwaltet .com? PC ← DNS-Server: .com verwaltet der DNS-Server 1.2.3.4 2. Anfrage für example.com PC → DNS-Server von .com: Wer verwaltet example.com? PC ← DNS-Server: example.com verwaltet 4.3.2.1 3. Anfrage für abc.example.com PC → DNS-Server von example.com: IP von abc.example.com? PC ← DNS-Server: abc.example.com liegt auf 5.6.7.8 eigentliche Seite: 4. Anfrage für die Seite PC → 5.6.7.8 (abc.example.com) Ahoi! gib mir mal die Seite index.html PC ← 5.6.7.8 OK: ... Schritte 2 und 3 macht normal der gleiche DNS-Server (üblich der vom Registrar), andere sind aber durchaus möglich. Wenn der Server mehrere Subdomains ausliefern soll, muss man ihm das vorher einfach sagen → "Hallo Server, du bist ab sofort für die Subdomains abc.example.com, def.example.com und fail.example.com zuständig. Das schreibt man in seine Konfiguration und bei Anfragen (Host: im HTTP-Header) schaut er einfach da nach (genauer im RAM) ob er die Subdomain kennt.
Marc D. schrieb: > DNS kann man sich als Laie am ehesten als Wörterbuch vorstellen. > NAME <--> IP Früher hätte man den Vergleich mit einem Telefonbuch gemacht :-) Im Telefonbuch nach K. suchen Nummer anrufen und sagen: "Ich möchte Jonathan K. sprechen."
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.