Grundlagen/Namensauflösung im Domain Name System
- leicht
- 15min
Im vorhergehenden Kapitel wurde erklärt, wie die paketweise Datenübertragung im Internet organisiert wird. In diesem Kapitel soll die Namensauflösung im Domain Name System unter die Lupe genommen werden.
Für Menschen sind Namen wie beispielsweise „www.selfhtml.org“ einfacher zu merken und zu verwenden als numerische Adressen. Für Computer und Netzwerkkomponenten sind Zeichenketten hingegen unhandlich beziehungsweise ineffizient verarbeitbar. Die Namensauflösung vermittelt zwischen diesen beiden Anforderungen, indem sie Namen in Adressen und unter Umständen auch zurück übersetzen kann. Im Fall von Web-Adressen (URLs) wird die enthaltene Domain (zum Beispiel „www.selfhtml.org“) mit dem Domain Name System in eine IP-Adresse (zum Beispiel „89.238.67.49“) konvertiert.
Inhaltsverzeichnis
Hostnamen und DNS
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 ab einer gewissen Anzahl an Hostrechnern im Netz nicht mehr kontrolliert gepflegt werden kann, ist heute selbstverstä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
- 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
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".
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
Domain Name System
In der Adresszeile des Browsers finden sich die URLs der Webseiten. Der Uniform Resource Locator (URL) ist eine "einheitliche Angabeform für Ressourcen" in Netzwerken. Er zeigt einerseits die Seitenstruktur der Webseite, andererseits aber den Domainnamen. Dieser besteht aus mehreren Abschnitten, die durch einen Punkt getrennt werden:
| Host oder Dienst | Second-Level-Domain (SLD) | Top-Level-Domain (TLD) |
|---|---|---|
| www | selfhtml | org |
| ftp | selfhtml | org |
| https | example | com |
DNS-Adressen werden von rechts nach links gelesen:
- Top Level Domains (TLDs) sind eine Landes- oder Typenkennung wie
de= Deutschlandat= Österreichch= Schweiz
aber auchcom= kommerziell orientierte Namensinhaberorg= Organisation
- Die Second-Level-Domain (SLD) ist der eigentliche Domain-Name
- Die Angabe von WWW sollte ursprünglich dazu dienen Webseiten klar von anderen Diensten wie FTP oder E-Mail unterscheiden zu können. Hier hat sich mittlerweile durchgesetzt, dass Webserver so eingestellt sind, dass diese Angabe nicht mehr nötig ist.
Das HTTP-Protokoll gibt weiterhin das System von Anfrage und Response vor, ist aber durch HTTPS ergänzt worden.
Größere Webauftritte verwenden vor der Second-Level-Domain (SLD) eine Sub-Level-Domain (Subdomain):
| Host oder Dienst | Sub-Level-Domain | Second-Level-Domain (SLD) | Top-Level-Domain (TLD) |
|---|---|---|---|
| http | wiki | selfhtml | org |
| http | forum | selfhtml | org |
| http | irgendeinname | wordpress | com |
Dadurch können verschiedene Server angesprochen, aber auch eine logische Gliederung in verschiedene Bereiche unternommen werden. Das letzte Beispiel ergab sich aus einer Frage im Forum: Hier wird dem Domain-Namen wordpress.com eine Sub-Level-Domain mit einem Privatnamen vorangestellt.
Aufbau/Syntax von DNS-Namen
Für den Aufbau von Domains gelten einige Regeln:
- Die einzelnen Abschnitte (Domain und Subdomain) dürfen maximal 63 Zeichen enthalten. Die Gesamtlänge des Full-Qualified-Domain-Name (kurz FQDN) darf jedoch 255 Zeichen nicht überschreiten.
- Bis 2004 waren keine Umlaute erlaubt. Deshalb heißt die Auskunft der Telekom https://www.dasoertliche.de . Mittlerweile sind sogar chinesische Zeichen möglich.
- Als Sonderzeichen ist ein Minuszeichen
-erlaubt, jedoch nicht zu Anfang oder Ende des Namens. - Groß- und Kleinschreibung spielen keine Rolle –
selfhtml.orgundSELFHTML.orglösen also zur gleichen IP-Adresse auf.
Die Haupt-Server (Root-Server)
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!
Domain und Zone
Als Domain bezeichnet man die Menge aller Rechner, die unter einem gemeinsamen Namen gruppiert werden. Übertragen auf die root-Domain 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 Domain 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
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
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!
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 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
Hier unterscheidet man mehrere Varianten, welche aber meist als ein Verbund eingesetzt werden:
- 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.
- 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 iterative 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 Geschwindigkeitsvorteile 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?
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.
