Wie DNS wurde, was es heute ist
Bevor es im Detail um DNS geht, schadet ein kurzer historischer Abriss nicht. Denn DNS ist keine neue Erfindung, sondern gehört zu den ältesten Prinzipien des Internets. Es geht auf den US-Amerikaner Paul Mockapetris zurück und entstand im Jahre 1983. Und zwar aus purer Notwendigkeit: Der Vorgänger dessen, was heute als „Internet“ firmiert, war ein reines Forschungsnetzwerk namens ARPANET. Hier setzte in den 70er-Jahren ein rasantes Wachstum ein.
Die Idee, IP-Adressen mit besser merkbaren Hostnamen zu kombinieren, gab es bereits vor der Existenz des DNS-Systems. Man konfigurierte die Host-Einträge einfach auf den Computern statisch in einer Datei namens HOSTS
(oder HOSTS.TXT
). Das jedoch setzte voraus, dass es eine zentrale Instanz gab, die diese Datei pflegen konnte, weil sie alle Computer und deren IP-Adressen kannte.
Das ARPANET wuchs In den 70ern allerdings so schnell, dass das praktisch nicht mehr umsetzbar war. Mockapetris erdachte daraufhin die Grundlagen von DNS und schrieb sie in den RFC 882 und 883 nieder, die später durch 1034 und 1035 ersetzt wurden. Besonders spannend daran: Im Wesentlichen hat DNS sich bis heute nicht geändert. Zwar sind über die Jahre immer wieder neue Funktionen hinzu gekommen, die grundlegenden Prinzipien der Idee sind allerdings dieselben wie vor fast 40 Jahren. Denn fast alle Updates an DNS in den vergangenen Jahren dienten vorrangig dazu, die Administration von Nameservern und ihre Nutzung komfortabler zu gestalten.
Andere Verbesserungen bezogen sich auf das Thema Sicherheit. Die Möglichkeit, DNS-Einträge zwischen Servern mittels IXFR-Befehl auszutauschen, war anfangs in DNS etwa nicht vorgesehen. Und auch digitale Signaturen auf DNS-Einträgen (DNSSEC), die Missbrauch vorbeugen sollen, waren im Jahre 1983 noch kein Thema. Heute sind beide Funktionen Standard und erfreuen sich großer Beliebtheit.
Zwei Arten von Servern
Fest steht: Ohne Nameserver wäre das Internet heute praktisch unbenutzbar. Dass nicht ein einzelner Nameserver alle Anfragen des gesamten Internets beantworten kann, liegt aber auf der Hand. Denn die Last wäre für einen einzelnen Server viel zu hoch. Die Erfinder des DNS-Systems um Paul Mockapetris haben sich deshalb einen Mechanismus ausgedacht, der die anliegende Last auf möglichst viele Server verteilt.
Das Schema sieht vor, dass einzelne DNS-Server für bestimmte Domänen oder IP-Adressen verantwortlich sind und andere DNS-Server für andere Domänen und IP-Adressen. Wichtig ist dabei die Erkenntnis, dass Admins im Alltag des Betriebs von DNS-Servern heute zwischen zwei Arten von DNS-Servern unterscheiden:
- Rekursive DNS-Server („recursive DNS“, oft „rDNS“ oder auch „resolving servers“) finden in den meisten Fällen die IP-Adressen hinter bestimmten Namen heraus – der Webbrowser, der die IP von blog.univention.de herausfinden möchte, stellt also eine Anfrage an einen rekursiven DNS-Server.
- Autoritative DNS-Server enthalten die kanonischen DNS-Einträge für einzelne Domänen oder IP-Adressen. Sie sind mithin implizit die Anlaufstelle für rekursive DNS-Server als letzter Schritt in deren Anfragen.
Autoritative DNS-Server können für lokale Clients zeitgleich rekursive DNS-Server sein, müssen es aber nicht. Am Markt etablierte DNS-Server teilen sich zudem in solche auf, bei denen ein monolithisches Programm für rekursives und autoritatives DNS zuständig ist (zum Beispiel Bind) und solche, bei denen getrennte Komponenten diese Aufgaben wahrnehmen (zum Beispiel PowerDNS).
Übrigens: Im administrativen Alltag sind sowohl rekursive als auch autoritative Nameserver meistens redundant ausgelegt. Ein Client kennt also üblicherweise mehrere rekursive Nameserver, damit er auch dann Anfragen stellen kann, wenn einer davon nicht funktioniert.
Pro Domäne sehen die meisten Domain-Registrierer mindestens zwei DNS-Server vor, so dass die Auflösbarkeit von Einträgen der Domäne stattfinden kann. Praktisch relevante Limits gibt es hier nicht: In Linux lassen sich beinahe beliebig viele rekursive DNS-Server konfigurieren und die Anzahl der autoritativen DNS-Server pro Domäne ist ebenfalls nicht beschränkt.
Die Anatomie einer DNS-Anfrage
Aus der Erklärung eingangs ergibt sich, dass es auch für die Domäne univention.de einen autoritativen DNS-Server geben muss, der weiß, welche IP zu blog.univention.de gehört. Woher aber weiß ein Client, der diese Website aufrufen möchte, welcher DNS-Server für die Domäne univention.de zuständig ist? Das lässt sich am besten nachvollziehen, indem man sich die Anatomie einer DNS-Anfrage im Detail anschaut. Denn daraus ergibt sich auch, dass an der Beantwortung einer Frage mehrere DNS-Server beteiligt sind. Das System der autoritativen DNS-Server unterteilt sich in drei Ebenen:

Abbildung 2: Die Root-Server sind die zentrale Instanz des DNS-Systems und die erste Anlaufstelle für Clients, die Hostnamen auflösen möchten.
- Die erste Schicht bilden die Root server (Abbildung 2). Jeder DNS-Server im Internet, der an der Auflösung öffentlicher Hostnamen beteiligt ist, hat eine Liste der existierenden Root-Server statisch konfiguriert. Von den Root-Servern erfährt der Client jedoch nichts über die Zuständigkeit für spezifische Domänen. Sie enthalten lediglich die „Root Zone“ (Abbildung 3), also die Information, welche Nameserver für spezifische Top-Level Domains („TLD“) zuständig sind. Die Top-Level-Domäne bezeichnet den letzten Teil eines Hostnamens, etwa .de, .com oder .info.
- Hat der Client erfahren, welcher Nameserver für die jeweilige Top-Level-Domäne zuständig ist (Grafik 1, „TLD server“), wendet er sich unmittelbar an diesen und fragt, welcher der autoritative DNS-Server für eine bestimmte Domäne ist. Kennt der Client den zuständigen autoritativen Server für eine Domäne, fragt er bei diesem nach der IP des jeweiligen Hostnames . Die DNS-Abfrage ist damit erfolgreich abgeschlossen.

Abbildung 3: Die Root-Server verwalten die Root-Zone des gesamten Internets, in der hinterlegt ist, welche Nameserver für welche Top-Level-Domains (wie hier .com) verantwortlich sind.
Die TLD-Server betreiben üblicherweise die für das jeweilige Land zuständigen Domain-Registrierer, in Deutschland etwa die DeNIC für .de. Damit ist auch klar: Bis der eigene Browser eine Website tatsächlich öffnen kann, geschehen im Hintergrund mehrere DNS-Anfragen hin zu unterschiedlichen Servern in Sekundenbruchteilen.

Bis ein Client die IP-Adresse des Hostnamens kennt, den er auflösen möchte, hat er einige Schritte zu erledigen
Einsatzszenarien für DNS
Die beschriebene DNS-Funktionalität deckt das Standard-Beispiel der Alltags-IT ab, bei dem ein Client mit einem bestimmten Server über dessen Hostnamen kommunizieren möchte. In der Praxis gibt es allerdings eine Vielzahl weiterer Stellen, an denen DNS zum Einsatz kommt – und in Zukunft wird die Anzahl der Gelegenheiten dafür wohl noch größer werden. Einige klassische Einsatzszenarien der Gegenwart umfassen:
• Das Auflösen von Hostnamen des World Wide Webs in Webbrowsern
• Die Zustellung von E-Mails für Domänen und Sub-Domänen
• Das dynamische Auffinden von bestimmten Diensten (Kerberos, LDAP…) in verteilten Umgebungen oder innerhalb moderner, Container-basierter Anwendungen
• Das Auflösen von Hostnamen auch in lokalen Umgebungen für interne Zwecke, etwa innerhalb von Firmen unter einer Pseudo-Top-Level-Domain wie .internal
• Das dynamische Auffinden von bestimmten Diensten oder Geräten in Umgebungen, in denen Protokolle wie Bonjour oder UPnP zum Einsatz kommen
• Transportverschlüsselung für Verbindungen, die stets auf dem aufgerufenen Hostnamen basiert und einen Fehler ausgibt, falls Hostname und Zertifikatsname voneinander abweichen
Diverse Service-Anbieter nutzen das DNS-Protokoll mittlerweile zudem, um globale Lösungen wie Content Delivery Networks (CDN) oder geographisches Routing zu implementieren. DNS-Server geben für die Anfragen einzelner Clients dann etwa Rückgabewerte aus, die geographisch dem Client besonders nahe sind. So erreichen CDNs beispielsweise, dass Clients in Europa ihre Inhalte aus europäischen Rechenzentren beziehen und Clients in Asien aus Rechenzentren in Asien.
Rekursive Nameserver in der Praxis
Rekursive und autoritative Nameserver stellen deutlich unterschiedliche Anforderungen an die Admins, die sie betreiben. Rekursive Nameserver sind dabei merklich weniger aufwendig im Hinblick auf ihre Administration. Unabhängig von der genutzten Software sind die Arbeitsschritte beim Setup eines rekursiven Nameservers stets dieselben:
- Zunächst installieren ausführende Administratoren die Nameserver-Software auf mehreren Systemen und sorgen dafür, dass sie die korrekten IP-Adressen nutzen und von außen erreichbar sind. Dazu ist es notwendig, in einer eventuell vorhandenen Firewall zumindest den Port 53 für das UDP-Protokoll freizuschalten.
- Wer seinen Nameserver auf einer gängigen Linux-Distribution oder unter Windows betreibt, bekommt die nötige Konfiguration für rekursives DNS in aller Regel vom Anbieter mit dem Nameserver selbst geliefert. Wichtig ist lediglich, dass die Einträge für die Root Server passen.
- Alternativ lassen die meisten DNS-Server-Programme sich auch so konfigurieren, dass sie nicht unmittelbar mit den Root Servern kommunizieren, sondern eingehende Anfragen von Clients lediglich an andere rekursive Nameserver weiterleiten (DNS request forwarding). Ist das gewünscht, hinterlegen die Admins in der Konfiguration ihrer Nameserver die IP-Adressen der Server, an die Requests zu schicken sind.
- Es empfiehlt sich obendrein, den Zugriff auf die DNS-Server für Rekursion zu begrenzen. Nur die wenigsten Unternehmen werden einen öffentlichen Nameserver für die Namensauflösung betreiben wollen, den jeder im Internet nutzen kann. Je nach genutzter Software kann die Art, wie Beschränkungen zu implementieren sind, aber abweichen. Nahezu alle DNS-Server-Programme bieten die Option, die Beantwortung von Anfragen auf bestimmte Quellen-IP-Bereiche zu begrenzen. Alternativ sind auch Firewalls eine valide Option.
Haben Admins sich durch diese Liste gearbeitet, haben sie üblicherweise einen oder zwei lokale DNS-Server, die für rekursives DNS zur Verfügung stehen. Diese lassen sich auf den Client-Systemen dann per IP-Adresse eintragen und so ansprechen.
Autoritative Nameserver in der Praxis
Merklich komplexer ist die Sache, wenn es um das Setup autoritativer DNS-Server geht. Hier gibt es mehrere Punkte zu beachten, auf die dieses Kapitel im Detail eingeht. Dabei spielen auch verschiedene Begriffe eine Rolle, die möglicherweise nicht allen Admins geläufig sind oder deren Definition nicht eindeutig sind. Zunächst geht es deshalb um die Klärung eben jener Begriffe.
Von Zonen und Einträgen
Wer es mit dem Setup eines autoritativen DNS-Servers zu tun bekommt, wird regelmäßig über den Begriff „Zone“ stolpern. Was komplex klingt, ist eigentlich ganz einfach: Von „Zone“ ist im DNS-Kontext die Rede, wenn es um die Konfiguration eines Nameservers für eine spezifische Domäne geht. Der Begriff entspringt aus der Geschichte von BIND, dem ersten und lange am weitesten verbreiteten DNS-Server der Internet-Geschichte. Der speichert die Konfiguration von einzelnen Domänen in „Zone Files“.
- Eine Zone zeichnet sich durch verschiedene Details aus. So muss jede Zone einen SOA-Eintrag haben. Die Abkürzung steht für „Start of Authority“ und definiert, für welche Domäne die Zone gültig ist, wie die aktuelle Seriennummer lautet und was die „TTL“, also die „Time To Live“ einzelner Einträge ist (der Artikel geht auf diese Bezeichnung später noch im Detail ein).
- Der zweite regelmäßig genutzte Begriff ist der des „Records“, also des Eintrags. Dazu gilt es zu wissen: Die Zonen für Domänen in DNS-Servern haben neben dem SOA-Eintrag üblicherweise auch eine Reihe von Einträgen verschiedener Art. Die Information etwa, dass
blog.univention.de
auf die IP-Adresse 217.160.0.58
auflöst, ist ein A record. Weil IPv6 die Weiterentwicklung von IPv4 ist und einen vierfach so großen Adressraum hat, heißen Einträge für IPv6-Einträge in Zonendateien AAAA records.
- Weder A-Einträge noch AAAA-Einträge sind in einer Zone allerdings notwendig. Vorhanden sein muss hingegen zumindest ein NS-Eintrag. NS steht für Nameserver; ein NS-Eintrag in jeder Zone muss bei jedem autoritativen Nameserver zumindest auf diesen selbst zeigen. Denn andernfalls wird der DNS-Server sich für die Domäne nicht zuständig fühlen und Anfragen ignorieren. Praktischen Nutzen haben die NS-Einträge beim Transfer von Zonen zwischen Servern. Wer etwa einen autoritativen Primärserver hat und einen sekundären autoritativen Nameserver dazu bauen möchte, trägt im primären Server NS-Einträge für beide Systeme ein. Ist der sekundäre Nameserver richtig konfiguriert, synchronisiert der primäre Nameserver die Inhalte der Zonendatei auf diesen automatisch.
- Weitere Einträge haben im Alltag große Relevanz. MX-Einträge etwa definieren den „Mail Exchange“ für Domänen. Sie legen also fest, wo die Mails einer Domäne hingehen und können wie NS-Einträge vielfach vorhandenen sein. Während NS-Einträge und A/AAAA-Einträge aber nur den eigentlichen Hostnamen und die IP definieren, legen Admins bei MX-Einträgen auch eine Reihenfolge fest, in der Mailserver durchzuprobieren sind. Nicht unter den Tisch fallen sollen außerdem PTR-Einträge, TXT-Einträge und SRV-Einträge.
- PTR-Einträge sind das Gegenstück für A/AAAA-Einträge, aber für IP-Adressen. Der Vorgang, bei dem eine IP-Adresse zu einem vorgegebenen Domainnamen aufgelöst wird, nennt sich Forward DNS-Lookup bzw. schlicht DNS-Lookup. Eine Abfrage nach PTR-Einträgen heißt im Fachjargon meist „Reverse DNS-Lookup““. Mittels PTR-Eintrag legen Admins also fest, auf welchen Hostnamen eine IP-Adresse auflösen soll.
- TXT-Einträge ermöglichen das beliebige Hinterlegen von Textnachrichten im DNS-System. Das ist beispielsweise nützlich, um nachzuweisen, dass man die Kontrolle über eine bestimmte Domäne tatsächlich innehat.
- SRV-Einträge schließlich dienen in modernen, dynamischen Umgebungen dem Auffinden von bestimmten Diensten. Will ein Kerberos-Client in einem Active-Directory-Network wissen, wo er den Active Directory Server erreicht, schaut er beim entsprechenden SRV-Eintrag in der jeweiligen Domäne nach.
Keine unüberwindliche Hürde
Die gute Nachricht ist: Wer die Anatomie einer Zone im DNS-System grundlegend verstanden hat, hat beim Betrieb eines autoritativen DNS-Servers keine größeren Probleme mehr zu befürchten. Folgende Arbeitsschritte fallen an:
- Zuerst installieren Admins die gewünschte Nameserver-Software und richten sie basal ein. Sie definieren per Konfiguration, welche Clients Zugriff haben, auf welchen IP-Adressen der DNS-Server eingehende Anfragen beantworten soll und für welche Zonen der Nameserver zuständig ist.
- Für die definierten Domänen legen die Admins danach die Zonen im Nameserver an. Pro Zone muss ein SOA-Eintrag sowie ein NS-Eintrag vorhanden sein. Es empfiehlt sich jedoch, auch A-Einträge, AAAA-Einträge und MX-Einträge von Anfang an sorgsam zu pflegen. Das geht übrigens auch für Subdomänen: blog.univention.de könnte etwa andere MX-Einträge haben als univention.de. Ein A- oder AAAA-Eintrag kann zudem auf mehrere IP-Adressen zeigen – der jeweilige Nameserver gibt dann eine zufällig ausgewählte IP-Adresse auf Anfrage aus („DNS-basiertes Round Robin“).
- Dann folgt die Konfiguration weiterer autoritativer Nameserver, die als sekundäre Server agieren. Hinterlegen Admins die Konfiguration korrekt, übermittelt der primäre Nameserver die Konfiguration einer Zone automatisch an die sekundären Server mittels AXFR- (Asynchronus Xfer Full Range) oder IXFR (Incremental Zone Transfer)-Transfer.
Aus der Praxis: Debugging bei rekursivem DNS
Nun, da die grundlegende Arbeitsweise von DNS erläutert ist, stellt sich die Frage, mit welchen Problemen Admins es im Alltag üblicherweise zu tun bekommen und wie sie darauf passend reagieren. Sowohl falsch konfigurierte autoritative Nameserver als auch nicht eingetragene oder fehlkonfigurierte rekursive Nameserver führen im Alltag der IT-Gegenwart immer wieder zu großen und kleinen Problemen. Doch keine Panik: Wer das passende Werkzeug zur Verfügung hat, kommt den gängigen Fehlern schnell auf die Schliche.
Dieses Kapitel befasst sich zunächst mit Problemen bei rekursivem DNS. Und die sind besonders tückisch – denn der gerade von eher unerfahrenen Anwendern reklamierte Umstand, dass „das Internet nicht funktioniert“, ist oft genug auf DNS-Probleme zurückzuführen. Im Falle eines Falles gilt es das jedoch zunächst zu klären.
Das ist mittels eines Tricks möglich: Startet der Anwender unter Linux eine Konsole oder unter Windows cmd.exe, verrät ihm dort der Befehl ping 8.8.8.8, ob die Verbindung ins Internet grundsätzlich klappt. 8.8.8.8 ist Googles zentraler, öffentlicher Nameserver, der auf ICMP-Anfragen (also ping) zuverlässig reagiert. Kommt schon hier eine Fehlermeldung liegt das Problem nicht auf der DNS-Ebene.
Liefert das Ping-Kommando hingegen Antwortpakete zurück, lässt sich im nächsten Schritt mittels ping univention.de herausfinden, ob auch die Namensauflösung klappt. Kommt hier eine Fehlermeldung wie Host not found zurück, ist etwas grundlegend falsch (Abbildung 4).

Abbildung 4: Funktioniert das ping-Kommando mit einer IP-Adresse als Ziel, nicht jedoch mit einem Hostnamen, stimmt etwas mit dem DNS-Setup nicht.
Problem: Keine Nameserver eingetragen
Wenn auf einem System keine Nameserver hinterlegt sind, schlägt die Namensauflösung für sämtliche Programme freilich fehl. Das Problem betrifft vorrangig Client-Computer im privaten wie im professionellen Umfeld. Wenn das Öffnen von Websites auf einem System fehlschlägt, ist es jedenfalls eine gute Idee, die aktuellen Nameserver-Einträge zu überprüfen.
Auf Linux-Systemen findet der Nutzer diese immer in /etc/resolv.conf. Finden sich in dieser Datei keine Einträge des Schemas „nameserver IP-Adresse“, kann die Auflösung von DNS-Einträgen nicht funktionieren. Windows-Clients zeigen die DNS-Konfiguration in den TCP/IP-Eigenschaften des jeweiligen Netzwerkadapters an.
Die Gründe dafür, dass Clients keinen Nameserver konfiguriert haben, sind vielfältig – freilich unter der Prämisse, dass die Internetanbindung des Clients grundsätzlich funktioniert. Die banalste Option ist, dass das jeweilige System über einen statisch konfigurierten TCP/IP-Stack verfügt und der einrichtende Administrator das Hinterlegen von Nameservern vergessen hat. Dann sind in der TCP/IP-Konfiguration die nötigen Nameserver händisch zu hinterlegen.
Weit häufiger werden Client-Systeme heute allerdings dynamisch per DHCP konfiguriert. Und DHCP sieht ein eigenes Feld für Nameserver vor, konfiguriert diese also automatisch. Ein Blick in die Konfiguration des DHCP-Servers verrät, ob dieser auch Nameserver ausliefert.