Grundlagen/Domain Name System

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Der Datenverkehr im Internet arbeitet mit auf dem Internet-Protocoll basierenden Diensten wie z.B. TCP, UDP, FTP, HTTP usw.

Hostrechner werden dabei über ihre IP-Adresse adressiert. Dabei gab es früher nur die 32 bit langen IPv4-Adressen, etwa 192.168.100.253. Seit einiger Zeit gehen bei IPv4 jedoch die Adressen aus. Daher wurde das neue IPv6 entworfen. Dieses arbeitet mit der 4-fachen Adresslänge, wodurch deutlich mehr Adressen möglich werden.

Da man diese Zahlen, und bei IPv6 dann auch noch Buchstaben, sich kaum merken kann, wurden eindeutige Hostnamen vergeben. Damit der PC aber weiß, welche Adresse hinter diesen Namen steckt, wird ein Telefonbuch für Domains benötigt: Das Domain Name System, kurz DNS.

Für technisch Interessierte:

  • IP gehört im OSI-Schichtenmodell zur Schicht 3 (Network).
  • Domains gehören hingegen zur Schicht 7 (Application).


Vorteile der Domains:

  • leichter zu Merken
  • aussagekräftiger z.b. www.selfhtml.org => Webseite bei der es um das erstellen von HTML-Dokumenten geht
  • langlebiger. Bei einem Providerwechsel ändert sich die IP, der Domainname bleibt jedoch identisch
  • Pro IP können viele Domains laufen

Hostnamen und DNS[Bearbeiten]

Zu Beginn der Vernetzung wurden die Namen der Rechner mit Zuordnung der IP in einer zentralen Datei gespeichert. Diese Datei ist auch heute noch auf allen Rechnern zu finden und im Betriebssystem verankert. Bei Linux ist es die /etc/hosts

;127.0.0.1 localhost
192.168.100.12 drucker1.selfhtml.org
192.168.100.13 drucker2.selfhtml.org

Dass diese Liste aber einer gewissen Anzahl an Hostrechnern im Netz nicht mehr kontrolliert gepflegt werden kann, ist heute selbst verständlich. (Wobei man hier vermerken muss, dass eine Zeit lang, solch eine Datei täglich aktualisiert wurde!)

Um dies aber einfach zu gestalten, wurde 1983 von Paul Mockaperris das Domain Name System entwickelt. Dabei hat die hosts-Datei ihre Bedeutung aber nicht vollständig verloren. Jeder Rechner fragt vor der Nachfrage im DNS erst die Hosts-Datei ab. Dadurch könnte man z.b. eine Anfrage für google.de auf den Server von selfhtml.org umleiten. Der Versuch dürfte aber mit einem "404 Dokument nicht gefunden" enden.

Vorteile der /etc/hosts gegenüber dem DNS[Bearbeiten]

  • funktioniert auch ohne Verbindung zum Netzwerk (wird teilweise beim Starten des Rechners benötigt)
  • schnelle Antwort auf Anfragen, da keine externe Quelle angefragt wird
  • einfacher Dateiaufbau und daher leicht zu konfigurieren

Namensauflösung auf einem Hostrechner, Name Resolver
[Bearbeiten]

DNS und die hosts-datei werden gemeinsam zur Auflösung der Domains verwendet. Dabei muss aber nicht jede Anwendung für sich Arbeiten, sondern greift auf Zwischenprogramme zurück. Diese Programme nennen sich "NameResolver" bzw. "Resolver". (Auf Unix-Systemen wurden diese in C programmiert)

Damit der Resolver fehlerfrei arbeitet, müssen die IP-Adressen der Nameserver bekannt sein. In modernen Systemen wird dies bereits automatisch übernommen. Auf Grund von dynamischen IP-Adressen, wäre dies anders auch nicht mehr möglich.

Unter Unix finden Sie diese Datei als /etc/resolv.conf

nameserver 8.8.4.4
nameserver 8.8.8.8
nameserver 192.168.100.1


DNS[Bearbeiten]

Struktur des DNS[Bearbeiten]

Der DNS-Raum gleicht der Struktur eines Baumes. Dabei kann man die Blätter mit den Hostnames gleich setzen.

Aufbau/Syntax von DNS-Namen[Bearbeiten]

Die Knoten des Baums werden Label genannt. Dabei gelten einige Regeln:

  1. der Stamm wird als Root-Domain bezeichnet und besteht aus einer leeren Zeichenkette
  2. ein Label besteht aus maximal 63 Zeichen, welche aus dem 7-bit ASCII-Zeichensatz stammen. (a-z, 0-9, -) Der Unterstrich ist dabei nicht erlaubt. Groß und Kleinbuchstaben werden gleich behandelt. Seit einiger Zeit sind nun auch Umlaute zugelassen.
  3. ein Label darf nicht mit dem Minuszeichen beginnen oder aufhören.
  4. Top-Level-Domains (TLDs) sind nicht frei vergeben (de, fr, ...) Seit 2012 werden auf Antrag aber auch spezifischere TLDs vergeben. Etwa ".post" Diese Anträge sind jedoch teuer und setzen den Bedarf sowie die technische Grundlage voraus
  5. Ein Full-Qualified-Domain-Name (kurz FQDN) gibt den kompletten Pfad (absolut) ab der root-Domain bis zur gewünschten Sub-Domäne an. Als Trennzeichen (Astgabelungen) werden die Punkte verwendet. Dabei ist die Schreibweise vom Blatt (Subdomain) bis zum Stamm (root). Beispiel: wiki.selfhtml.org. Beachten Sie den abschließenden Punkt. Dieser ist optional, wird in einigen Systemen z.b. Windows Server verlangt
  6. Der FQDN darf insgesammt nicht länger als 255 Zeichen sein. Dabei zählt der letzte Punkt mit.

Die Haupt-Server (Root-Server)[Bearbeiten]

Damit das System des DNS funktionieren kann, wird ein großes Inhaltsverzeichnis benötigt. Dabei schlüsselt man das Ziel von hinten her (also vom root aus) auf. Das Inhaltsverzeichnis für die TLDs ist dabei das wichtigste. Dieses Inhaltsverzeichnis wird auf den so genannten Root-Servern gespeichert. Davon gibt es auf der ganzen Welt nur 13 Stück. Diese bestehen natürlich aus großen Rechenzentren. Durch eine ausgeklügelte Verschaltung des Internets können dabei aber mehrere Rechenzentren hinter einem Root-Server versteckt sein. (Stichwort: Anycast)

Jeder dieser Root-Server hat eine feste Adresse und wurde auch mit einem DNS-Namen versehen:

<buchstabe a-k>.root-servers.net.

Die IP-Adressen dieser Root-Server müssen in den Nameservern (und in den meisten Betriebssystemen) fest hinterlegt werden. Dies ist vergleichbar mit dem Telefonbuch. Wenn ihr nicht wisst, wo es liegt, könnt ihr dort auch nicht nachschauen. Suchen geht zu lange!

Domäne und Zone[Bearbeiten]

Als Domäne bezeichnet man die Menge aller Rechner, die unter einem gemeinsamen Namen gruppiert werden. Übertragen auf die root-Domäne bedeutet dies, dass alle Rechner dort hin gehören. Bei selfhtml.org wäre das z.B. heimdall.selfhtml.org oder winnetou.selfhtml.org

Im Volksmund wird der Begriff der Domäne meist stellvertretend für die Second-Level-Domain (z.B. selfhtml.org) verwendet. Das www.selfhtml.org steht hier übrigens für die Third-Level-Domain.

Als Zone bezeichnet man die Menge aller Rechner, bei denen das „Telefonbuch“ also die Zuordnung von IP zu FQDN, in einer gemeinsamen Datenbank gespeichert ist. So werden z.B. die FQDNs "vm1.winnetou.selfhtml.org" nicht vom Nameserver des Rechenzentrums verwaltet, sondern von winnetou.selfhtml.org. Die FQDN "vm0.winnetou.selfhtml.org" kann wiederum aber vom Rechenzentrum verwaltet werden. Daher sind Zonen von außen nicht so leicht zu erkennen.

Nameserver[Bearbeiten]

Server, welche die Auflösung einer Domain zu einer IP herstellen können, bzw. als Vermittlungsstelle für genauere Informationen dienen, nennt man Nameserver (Bei DNS-Einträgen häufig mit NS abgekürzt). Für eine Second-Level-Domain werden meist 2 Nameserver hinterlegt, um Ausfälle zu vermeiden. Für eine TLD sind deutlich mehr Nameserver zu hinterlegen. Dabei holt sich der 2. Nameserver die Konfiguration, in regelmäßigen Abständen, vom Primary Nameserver.

Das Zonefile[Bearbeiten]

Diese Datei wird von Nameservern eingelesen und verarbeitet. Die Spezifikationen für den Aufbau findet man in der RFC-1035. Unter Linux kann das gerade aktive Zonefile ausgelesen werden. Bei Windows ist dies meist im Binärformat gespeichert und daher nicht zu lesen. Bei der Übertragung des Files zu einem anderen NS, spricht man von einem Zonetransfer.

In den Zonefiles wird häufig auch das @-Zeichen verwendet. Sonst für Konfigurationen doch recht unüblich, hat es hier die Bedeutung als Platzhalter für die aktuelle Zone, wenn die Variable $ORIGIN nicht neu gesetzt wurde.

So kann man in der Datei "db.selfhtml" den Wert selfhtml.org durch das @ ersetzen. Voraussetzung dafür ist ein Eintrag in der named.conf nach diesem Muster

zone "selfhtml.org"(
  type master;
  file "/etc/bind/db.selfhtml";
 );

Hier wurde im übrigen auf den weit verbreiteten Nameserver "BIND9" gesetzt. Bei dem @ gilt zu beachten, dass der Wert nur angehängt wird, wenn der Eintrag nicht mit einem Punkt endet. In dem unten gezeigten Beispiel wurde die Variable von Hand gesetzt. Dies ist bei vielen Zonen anzuraten, um die Übersicht innerhalb der Datei zu erhöhen. Pro Datei kann nur eine Zone definiert werden!

Beispiel
$ORIGIN . $TTL 3600 ; 1 hour selfhtml.org IN SOA winnetou.selfhtml.org. mail.selfhtml.org. ( 2004031298 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 38400 ; minimum (10 hours 40 minutes) ) NS winnetou.selfhtml.org. MX 10 winnetou.selfhtml.org. $ORIGIN selfhtml.org. $TTL 7200 ; 2 hours vm1 A 10.0.0.1 vm2 A 10.0.0.2 vm3 A 10.0.0.3 vm1.vm3 A 10.0.3.1
Die genannte TTL bedeutet Time-To-Live. Sie gibt also an, wie lange der Eintrag gültig ist und von anderen Servern gecached werden sollte. Achtung, leider werden diese Zeiten von großen Anbietern häufig auch ignoriert und durch andere Caching-Verfahren ersetzt. Dadurch kann ein Domain-Umzug für einzelne Internet-Benutzer bis zu 48 Stunden verzögert sein. Diese Tatsache ist bei einem Domain-Transfer auf eine neue IP zu beachten. Webseiten, über die Produkte verkauft werden, sollten daher nur an Tagen mit wenig Umsatz umgezogen werden. Für Webseiten wie amazon wäre ein Umzug natürlich ein großer wirtschaftlicher Schaden.

Die Resource-Record-Einträge in der db.selfhtml haben folgendes muster:

name [TTL in s] [class] type data

Dabei ist TTL und Class nur optional. Für Class wird fast immer der Wert IN (InterNet) angegeben.

Die wichtigsten Typen sind:

  • SOA - Start of Authority (Beginn der Zone)
  • NS - Nameserver dieser Zone bzw. einer Subzone
  • A - Domain-Zuordnung zu einer IP (nur IPv4)
  • AAAA - Domain-Zuordnung zu einer IP (nur IPv6)
  • CNAME - verweist auf einen weiteren CNAME oder A/AAAA Eintrag. Häufig wird dies z.b. für "www" genutzt. (Canonical Name)
  • MX - Steht für MailExchange: Dieser wird für Mail-Server verwendet.  Die meisten Server probieren die Emails bei fehlendem MX eintrag aber an den Hauptserver zu versenden.
  • TXT - Hier können Verifizierungen und sonnstige Daten hinterlegt werden. Früher wurde hier auch PTR eingetragen.
  • PTR - Hier werden IPs zu Namen aufgelöst.

Hinweis: PTRs können zwar häufig gesetzt werden, sind aber nur bei Zone-Files für IP-Subnetze gültig. Daher können PTRs häufig nicht direkt verwaltet werden, sondern nur über den Serverbetreiber bzw. das Rechenzentrum, dem das IP-Subnet zugewiesen wurde. Pro IP darf nur ein PTR eingetragen werden. Eine Abfrage für die IP 217.11.54.29 liefert den Hostname winnetou.selfhtml.org. Ein PTR eintrag auf die eigene Domain kann bei den meisten Hostern nicht realisiert werden, da man sich die IP mit anderen Kunden bzw. Domains teilt. Mit IPv6 ist dies jedoch kein Problem mehr. Hier kann jede Unterdomain eine eigene IP bekommen.

Eselsbrücke für A und AAAA: Da eine IPv6 insgesammt 4 mal soviele Stellen hat, wie eine IPv4 wurde dies im Typ mit dem AAAA wiedergegeben.

Wie werden Namen denn nun aufgelöst[Bearbeiten]

Hier unterscheidet man mehrere Varianten, welche aber meist als ein Verbund eingesetzt werden:

  1. iterative Suche - bei dieser Suche wird direkt im obersten Inhaltsverzeichnis (root-Server) angefragt. Dieser liefert den für die TLD zuständigen Nameserver. In einer 2. Abfrage, nun an den TLD-NS, wird der zuständige SLD-NS ermittelt. Mit einer 3. Abfrage kann nun beim SLD-NS eventuell das Ziel abgefragt werden. Würde man dies bei jedem Seitenaufruf machen, müsste man die Root-Server deutlich größer dimensionieren.
  2. rekursive Suche - bei dieser Suche wird nur der jeweils nächste, erreichbare NS angefragt. Das heißt, der Nameserver des jeweiligen Internet-Anbieters. Weiß dieser keine Antwort, oder ist sein Eintrag zu alt, so fragt er bei dem für ihn zuständigen NS an. Dies geht so bis zu den Root-Servern. Ab dort läuft dann die iterale Suche.

Vorteil für 1. = Nachteil für 2.

  • immer die aktuellen Daten verfügbar
  • Änderungen werden sofort wirksam

Nachteil für 1. = Vorteil für 2.

  • Traffic für die Root-Server entsteht durch jede einzelne Anfrage
  • Höherer Technischer Aufwand notwendig, um Lasten verteilen zu können.

Wie im 2. System bereits zu erkennen ist, funktioniert das Prinzip nur mit einem Zwischenspeicher. Das heißt, dass sich die Nameserver bestimmte Einträge merken, um so nicht immer nachfragen zu müssen. Häufig besuchte Seiten, wie z.b. bild.de werden meist länger gespeichert als selten besuchte Seiten. Dadurch wird der Cache auf das Wesentliche beschränkt, was deutliche Geschwindichkeitsvorteile bringt. Hier ist aber auch das bereits angesprochene Problem mit den veralteten Einträgen deutlich zu sehen. Ein Kompromiss, der für die große Struktur des Internets unbedingt notwendig ist.

Und die Auflösung der IPs?[Bearbeiten]

Auch hier greifen die oben genannten Methoden. Dabei kennen die Root-Server die jeweiligen IP-Subnet-Zone-Besitzer. Diese kennen dann die jeweiligen SubSubnet-Betreiber usw. Hier werden im gegensatz zum DNS, nicht die A bzw AAAA Einträge abgefragt, sondern nur die PTR (und teilweise die TXT) Einträge.

Unter Linux kann mit dem Befehl dig -x 8.8.4.4 ptr der Name zu der IP 8.8.4.4 ermittelt werden. Hinter der IP 8.8.4.4 versteckt sich übrigens ein OpenDNS-Server von google.

Für interessierte: Die Anweisung -x vereinfacht die Eingabe. Ohne diesen Parameter muss die Adresse im umgedrehten Format, kombiniert mit .in-addr.arpa. als 4.4.8.8.in-addr.arpa. eingegeben werden. Hier ist auch zu erkennen, dass der Suchlauf identisch mit dem der Domains laufen kann. Von hinten nach vorne!

Für Windows steht der befehl nslookup bereit.