Login
Newsletter
Werbung

Do, 26. Mai 2011, 15:00

Webzugriff

Was passiert dabei im Detail?

Finden des DNS-Servers

Da wir nun wissen, wie die Namensauflösung erfolgt, gehen wir nun davon aus, dass ein DNS-Server involviert ist und wir nicht über /etc/hosts-Auflösungen surfen. Jetzt kommen wir in den Netzwerkbereich: Wie wird der DNS-Server im Internet gefunden?

Zur kurzen Erinnerung an TCP/IP: Das Protokoll besteht aus mehreren, unabhängigen Schichten, jede Schicht hat ihr eigenes Protokoll und ihre eigene Aufgabe. Oft wird dafür auch das OSI-Modell mit seinen sieben Schichten herangezogen. TCP/IP hält sich aber nur für die ersten Schichten daran. Relevant sind hier die ersten vier Schichten:

  1. Physikalische Schicht, z.B. das Netzwerkkabel
  2. Datenverbindungsschicht, oft Ethernet
  3. Netzwerkschicht, IP
  4. Transportschicht, oft TCP oder UDP

Die erste Schicht betrifft nur die Art der Verkabelung oder die Art des Funks. Relevant wird es mit der zweiten Schicht, das ist in aller Regel Ethernet. Früher war hier auch noch Token Ring verbreitet, das kommt aber wohl nur noch selten zum Einsatz. Aber das zeigt den klaren Vorteil des Schichtenmodells. Die höheren Schichten brauchen nicht zu wissen, ob Ethernet, WLAN oder gar der Tote Ring zum Einsatz kommen. Ebenso brauchen TCP/UDP nicht zu wissen, ob darunter ein IPv4 oder ein IPv6 verwendet wird. Das macht es so leicht, hier andere Protokolle zu verwenden.

Für das weitere gehen wir einfach von Ethernet aus. IP ist das Protokoll, das die Internetsysteme miteinander verbindet, das ist die Adressierung der Systeme an Hand der IP-Adressen. Für das lokale Netzwerk, also bis zum direkt angeschlossenen System oder dem Router/Gateway, ist aber Ethernet zuständig.

Wie wird denn nun der DNS-Server gefunden? Dazu muss man wissen, wie er erreicht werden kann. Ein Blick in die Routing-Tabelle offenbart dann, ob der DNS-Server lokal angeschlossen ist, also im gleichen Subnetz steht, oder ob er über einen Router erreicht werden muss.

Die logische Adressierung erfolgt über die IP-Adresse. Der Versand zum nächsten angeschlossenen System, also dem Server oder Router, erfolgt aber über Ethernet. Wir müssen also erst einmal die Ethernetadresse des Systems finden, alles was wir haben ist aber eine IP-Adresse.

Das erfolgt nun mit dem Address-Resolution-Protocol. Dabei sendet das suchende System, also der eigene PC, ein spezielles Ethernetpaket an alle angeschlossenen Systeme, und fragt nach der Hardware-Adresse zu der gewünschten IP-Adresse, also entweder der des DNS-Servers, wenn er direkt im Subnetz steht, oder die des Routers.

Die Hardware-Ethernet-Adresse besteht bei Ethernet aus sechs Bytes, und die sind für alle Ethernetkarten eindeutig. Sie werden auch MAC-Adresse genannt. Die ersten drei Bytes identifizieren dabei den Hersteller der Ethernetkarte, die restlichen drei sind eine einmalige Adresse bei diesem Hersteller. Diese Adressen werden in der Regel als Hexadezimalzahlen, getrennt durch Doppelpunkte dargestellt, z.B.:

00:1a:70:63:16:f5

Die ersten drei Bytes liefern dann über die offizielle Liste den Hersteller der Karte:

00-1A-70   (hex)                Cisco-Linksys, LLC

Es gibt auch spezielle Adressen, wie z.B. die Broadcast-Adresse. Bei dieser sind alle Bits gesetzt:

ff:ff:ff:ff:ff:ff

Da die Zieladresse zuerst im Ethernet-Header steht, können alle Ethernet-Karten leicht erkennen, ob das Paket für sie bestimmt ist, sie kennen ja die eigene MAC-Adresse. Bei Broadcast-Adressen wissen die Karten dann durch die spezielle Adresse auch gleich, dass sie das Paket entgegennehmen sollen. Derartige Pakete nimmt also jede direkt angeschlossene Ethernetkarte an und leitet es an das Betriebssystem weiter.

Bei einem ARP-Request steht dann in den Nutzdaten, dass das eigene System die MAC-Adresse zu der angegebenen IP-Adresse sucht. Da alle Systeme diese sehen, sollte das System antworten, das die IP-Adresse besitzt. Das ist der ARP-Response. Mit anderen Worten:

  • Man hat die IP-Adresse.
  • Die Adressierung im LAN-Segement erfolgt über Ethernetadresse.
  • Man ruft in die Runde: Wer hat die Ethernetadresse zu der IP-Adresse?
  • Das System mit der IP-Adresse antwortet und sendet die MAC-Adresse, also die Ethernet-Hardware-Adresse mit.

Wer einen Blick auf das Bild oben wirft, der sieht nun, dass wir die MAC-Adresse vom DNS-Server mit der IP-Adresse 10.0.0.2 suchen. Das ist in der Datei lug.pcap der erste Eintrag:

00:13:77:5b:25:ad > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 10.0.0.2 tell 10.0.0.1

Das ist der Broadcast, zu erkennen an dem Ziel ff:ff:ff:ff:ff:ff. Die erste Adresse ist die eigene MAC-Adresse für Antworten. Diese Nachricht wird an alle Ethernetkarten gesendet, die im gleichen Segment stecken. Die Karten nimmt dieses Paket dann entgegen und reicht es an den Kernel weiter. Dieser antwortet dann, wenn er die IP-Adresse hat:

00:1e:68:ef:be:63 > 00:13:77:5b:25:ad, ethertype ARP (0x0806), length 60: arp reply 10.0.0.2 is-at 00:1e:68:ef:be:63

Hier sieht man noch mehr. Im ARP-Request steht neben der gesuchten Adresse auch die eigene. Damit kann das System, das gesucht wird, sich schon einmal die IP-Adresse und MAC-Adresse des Anfragenden merken (ARP-Cache), denn es gibt wohl eine hohe Wahrscheinlichkeit, dass da gleich noch mehr Traffic kommen wird.

Die Antwort wird auch direkt an die MAC-Adresse des Fragenden gesendet, der Absender ist die MAC-Adresse des gesuchten Systems.

Übrigens: Bei DHCP wird in der Regel auch erst ein ARP-Request für die frisch vergebene IP-Adresse vom System selber versendet. Damit wird getestet, ob sie nicht schon existiert, also jemand diese z.B. von Hand konfiguriert hatte.

Das war ein kurzer Ausflug in die DL-Schicht, wer es genauer wissen will, kann in diesem Vortrag zu Netzwerkgrundlagen noch mehr Infos finden.

Kommentare (Insgesamt: 6 || Alle anzeigen )
Java != JavaScript (Weinzierl Stefan, Mi, 1. Juni 2011)
Re: HTTP ueber UDP... (LSD-Derivat, Fr, 27. Mai 2011)
Tippfehler? (elGuerrillero, Fr, 27. Mai 2011)
Re: "Nur wird wohl keiner jemals UDP für HTTP verwenden." (frinky, Do, 26. Mai 2011)
"Nur wird wohl keiner jemals UDP für HTTP verwenden." (cweiske, Do, 26. Mai 2011)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung