DNS: Eine Einführung mit Bezug zu Univention Corporate Server

Dieser Artikel beschäftigt sich mit dem System der Domain Name System Server („DNS Server“) und beantwortet die Frage, wie das „Telefonbuch des Internets“ funktioniert. Neben den absolut grundlegenden Details der Namensauflösung im Internet kommen dabei auch Sonderthemen wie die Verwaltung von DNS-Einträgen in dynamischen Umgebungen und das Debugging von DNS-Setups im laufenden Betrieb zur Sprache. Den technischen Rahmen bildet der Univention Corporate Server – denn der hat nicht nur einen waschechten DNS-Server im Gepäck, sondern auch diverse Werkzeuge, die das Management von DNS-Einträgen erheblich erleichtern.

DNS: Eine grundlegende Einführung

Das System der Domain Name System Server, kurz DNS, ist ein absolut elementarer Bestandteil des Internets. Während viele Anwendende und die meisten Admins mit dem Begriff „DNS Server“ oder „Nameserver“ noch etwas anfangen können, ist ihnen die Struktur des DNS-Systems und seine grundsätzliche Funktionsweise oft unklar. Es schadet daher nicht, sich zunächst mit der den Kernaspekten des Themas DNS zu beschäftigen, bevor man sich im Detail mit den einzelnen Aspekten von DNS befasst.

Von Zahlen und Nummern

Was die meisten Menschen belanglos als „das Internet“ bezeichnen, ist in Wirklichkeit ein globaler Verbund vieler einzelner Computer. Natürlich hat nicht jeder Computer zu jedem anderen Computer eine direkte Verbindung. Die am Internet teilnehmenden Computer sind stattdessen in einzelne Netzwerksegmente aufgeteilt. Innerhalb ihrer eigenen Netzwerksegmente kommunizieren die Systeme direkt miteinander.

Will ein Server aus einem Netzwerksegment mit einem Server in einem anderen Segment kommunizieren, tut er das über einen Router. Woher weiß ein Server jedoch, wie er einen anderen, lokalen Server oder einen Server in einem anderen Netzwerksegment erreicht?

Hier kommen die so genannten IP-Adressen ins Spiel. Eine IP-Adresse ist eine Zahlenkolonne in 32-bit (IPv4) oder 128-bit-Notation (IPv6), die jeden Teilnehmer des Internets eindeutig kennzeichnet. „IP“ steht für „Internet Protocol“, was auf die allgemeine Gültigkeit dieses Prinzips hindeutet. Die IP-Adresse des Computers etwa, auf dem Univention dieses Blog betreibt, lautet 217.160.0.58 (IPv4) sowie 2001:8d8:100f:f000::219 (IPv6) (Abbildung 1).

Abbildung 1: Hostnames zeigen normalerweise auf einen A-Eintrag für IPv4 und/oder einen AAAA-Eintrag für IPv6.

Schnell wird klar: Wollten Leserinnen und Leser dieses Blog über seine IP-Adresse erreichen, müssten sie sich eine komplizierte Zahlenfolge merken. Das ist im Falle von IPv4 mühsam und im Falle von IPv6 fast unmöglich, zumal diese IPv6-Adresse nicht das Maximum an Komplexität enthält, das mit IPv6 theoretisch möglich wäre. Stellt man sich dann vor, dass man sich die Zahlenkolonnen für sämtliche Websites merken müsste, die man regelmäßig nutzt, stellt man fest: keine Chance.

Die Gründerväter des Internets hatten dieses Problem bereits auf dem sprichwörtlichen Schirm. Sie erdachten ein System, das die komplizierten IP-Adressen in leichter verständliche Texte („hosts“ oder „hostnames“) übersetzt – aus den oben genannten IP-Adressen wird auf diese Weise blog.univention.de. Und das wiederum lässt sich freilich sehr viel leichter in Erinnerung behalten als die eigentlichen IP-Adressen.

Allerdings wirft das System auch eine neue Frage auf: Woher weiß etwa der Webbrowser, dass er sich an den Server mit der IP-Adresse 217.160.0.58 wenden muss, wenn Nutzer*innen https://blog.univention.de/ in die Adresszeile eingeben? Hier kommt das System der „Domain Name System Server“, kurz DNS Server, ins Spiel – denn die funktionieren wie eine Art Telefonbuch und wissen, welche IP-Adresse zu welchem Namen gehört. Umgekehrt funktioniert das natürlich auch: Für einzelne IP-Adressen lassen sich ebenfalls Namen in Textform definieren.

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:

1. 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.
2. 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:

1. 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.
2. 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.
3. 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.
4. 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:

1. 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.
2. 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“).
3. 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.

Problem: DNS-Server nicht erreichbar

Falls das der Fall ist, haben die Admins noch mehr Debugging vor sich: dann ist es nämlich wahrscheinlich, dass der Client die konfigurierten Nameserver nicht erreichen kann. Im nächsten Schritt ist also die Netzwerkverbindung zwischen Client und Nameserver zu prüfen, idealerweise direkt vom System aus. Unter Linux hilft das Werkzeug dig, Probleme mit DNS-Servern sichtbar zu machen. Es ist selbst ein DNS-Client.

Steht in /etc/resolv.conf etwa als Nameserver 192.168.0.1, fragt das Kommando dig univention.de @192.168.0.1 den Eintrag für univention.de über diesen Nameserver ab. Wichtig ist in der Antwort die ANSWER SECTION, die einen entsprechenden A-Eintrag zutage fördern sollte. Sind Netzwerkprobleme ursächlich für den Fehler, quittiert das Tool mit einer entsprechenden Fehlermeldung den Dienst.

Problem: Rekursiver DNS-Server falsch konfiguriert

Kommt einer solche Fehlermeldung nicht, wird es spannend — etwa, wenn dig den Nameserver zwar erreichen kann, dieser jedoch eine leere Antwort liefert. Dann ist das Problem höchstwahrscheinlich ein falsch konfigurierter, rekursiver DNS-Server, der etwa seinen DNS-Forwarder nicht erreichen kann. Pauschal lässt sich ein Verdacht hier jedoch nicht formulieren. Fehlkonfigurierte Nameserver zwingen Admins dazu, sich im Detail mit deren Konfiguration zu beschäftigen und ihre Logmeldungen zu lesen.

Absichern lässt sich eine etwaige Diagnose ebenfalls mittels dig: Liefert der zuvor beschriebene dig-Befehl eine Fehlermeldung, wenn der lokale DNS-Server als Ziel angegeben ist, aber den korrekten Eintrag vom DNS-Server 8.8.8.8, ist das Problem der rekursive Server – denn wenn ein Nameserver explizit angegeben wird, ignoriert dig den Inhalt von /etc/resolv.conf.

Problem: DNS-Server antwortet, liefert aber (vermeintlich) falsche Werte

Das letzte Problem im Beispiel gehört zu den unangenehmsten Problemen im DNS-Kontext, weil Endanwender im blödesten Falle keine Möglichkeit haben, es zu lösen – außer durch Warten. Es gibt durchaus Fälle, in denen bestimmte Hostnamen tatsächlich auf IP-Adressen auflösen, die dann aber nicht erreichbar sind. Das passiert gern, wenn die Admins des autoritativen Nameservers, der für eine Domäne zuständig ist, deren Konfiguration ändern.

Dazu ist es wichtig zu wissen: DNS sieht intern eine Art eingebautes Verfallsdatum für DNS-Einträge vor, die so genannte Time-To-Live (kurz TTL). Die dient vor allem der Performance: Weiß ein rekursiver Nameserver, dass der TTL-Eintrag des Hostnamens blog.univention.de 24 Stunden gültig ist, braucht er die beschriebene Ochsentour über die Root-Server, die TLD-Server und den autoritativen Nameserver nur alle 24 Stunden einmal zu machen. Den Rest der Zeit speichert er das Ergebnis in seinem Cache. Fragt ein Client erneut nach der IP des Hostnamens, antwortet er mit dem Wert, der im Cache gespeichert ist. Das nimmt Last vom DNS-System insgesamt und führt zu schnelleren Antworten für Clients.

Der Nachteil: Ändert sich die autoritative DNS-Zone einer Domäne, kann erst nach Ablauf der TTL sicher davon ausgegangen werden, dass alle Clients auch wirklich die geänderte Zone nutzen. Und de facto noch nicht einmal das, denn manche Betriebssysteme implementieren auf eigene Faust zusätzlich ein lokales DNS-Caching.

Ändern lässt sich in solchen Situation nur bedingt etwas. Steht der rekursive Nameserver unter der eigenen Kontrolle, bewirkt ein Neustart des Dienstes üblicherweise die Leerung des Caches. Das hilft aber nur, wenn der rekursive DNS-Server die Auflösung tatsächlich selbst erledigt und keine Forwarding-Server nutzt. DNS-Caches der Betriebssysteme sind wie beschrieben ebenfalls ein Faktor – die Dokumentation des genutzten Systems enthält in den meisten Fällen Infos darüber, wie der DNS-Cache sich leeren lässt.

Übrigens: Die geltende TTL für einzelne DNS-Einträge lässt sich mittels dig abfragen. Sie ist die Zahl, die in der ANSWER SECTION einer Anfrage unmittelbar hinter dem abgefragten Hostnamen steht (Abbildung 5).

Abbildung 5: Der Eintrag unmittelbar nach dem Hostnamen im ANSWER-SECTION-Abschnitt einer Anfrage mit dig beschreibt die TTL.

Aus der Praxis: Debugging von autoritativem DNS

Deutlich komplexer als Probleme bei rekursivem DNS sind üblicherweise Probleme bei autoritativem DNS. Denn hier gibt es eine Vielzahl von Faktoren, die über Erfolg und Misserfolg von DNS-Anfragen bestimmen.

Problem: Primärer und sekundärer Nameserver divergieren

Ein im Alltag oft zu beobachtendes Problem ist etwa der Effekt, dass die Inhalte eines primären und eines sekundären Nameservers divergieren. Beide Server liefern dann zwar valide Antworten zurück, aber unterschiedliche solche. Das passiert regelmäßig, wenn die Synchronisierung von Einträgen zwischen den Nameservern nicht funktioniert. Die erste Anlaufstelle für den Administrator sind dabei die Logdateien die Server, die üblicherweise entsprechende Fehlermeldungen enthalten werden.

Problem: Einträge in den Zonen sind vorhanden, aber nicht abrufbar

Ebenfalls ein häufiges Problem sind vermeintlich vorhandene Einträge in DNS-Zonen, die aber nicht dazu führen, dass bestimmte Hostnamen tatsächlich auch auflösbar werden. Das hat vor allem etwas mit der Art und Weise zu tun, wie DNS-Einträge in Zonen zu hinterlegen sind – besonders weniger erfahrene Administratoren kommen hier bei der Syntax oft ins Straucheln. Ist ein eigentlich hinterlegter Eintrag in einer DNS-Zone also nicht verfügbar und scheidet eine mögliche Abweichung zwischen primärem und sekundärem Server aus, hilft also nur das Studium der Dokumentation der Server-Software, um des Problems Herr zu werden.

Problem: Falsche Nameserver hinterlegt

Gar nicht so selten kommt es vor, dass für eine Domäne bei den TLD-Servern ganz banal die falschen Nameserver hinterlegt sind. Grundsätzlich geben Administratoren bereits beim Registrieren einer Domäne deren Nameserver an, die zu diesem Zeitpunkt bereits grundlegend konfiguriert sein müssen. Die meisten Domain-Registrierer verweigern andernfalls die Registrierung von vornherein. Sollen Zonen von einem auf einen anderen autoritativen DNS-Server umziehen, sind folglich auch die beim Registrierer hinterlegten Nameserver für eben diese Domäne zu ändern. Es genügt nicht, nur die NS-Einträge auf den Nameservern selbst zu ändern. Denn andernfalls werden rekursive Nameserver von den TLD-Servern weiterhin zu den alten Nameservern umgeleitet.

DNS in UCS

Das letzte Kapitel dieses Artikels widmet sich schließlich der Frage, wie Univention Corporate Server das Thema DNS handhabt und welche Funktionalität ab Werk gegeben ist. Grundsätzlich betrachtet UCS DNS natürlich als das, was es ist: Ein elementarer Bestandteil von Netzwerken. Entsprechend versucht es, den größten Teil der DNS-Konfiguration automatisch abzuwickeln, ohne den Administrator zu behelligen.

Im Klartext bedeutet das, dass auf jedem UCS-Domaincontroller (Bezeichnung ab UCS 5.0: directory node) und eventuellen Sekundärcontrollern immer auch DNS-Server automatisch mitlaufen. Grundsätzlich erhalten die ihre Konfiguration aus OpenLDAP, also dem zentralen Verzeichnisdienst, der ebenfalls zu UCS gehört. Wenn UCS als Domänencontroller zum Einsatz kommt, spielt DNS eine besonders große Rolle: Wie bereits erwähnt, ist es in dann notwendig, korrekte DNS-Einträge für bestimmte Server und Dienste zu haben, weil sonst etwa die Authentifizierung von Benutzern und Single Sign On nicht mehr funktioniert. Auch Reverse Lookups, also das Auflösen von PTR-Einträgen, muss unbedingt funktionieren. Um diese Einträge kümmert UCS sich deshalb selbst nach Konfiguration durch die Administratoren. (Abbildung 6).

Abbildung 6: UCS verwaltet seine eigenen DNS-Einträge selbst und zeigt für andere Einträge auf externe Nameserver – oder wickelt sie selbst über die Root-Server ab.

In Active-Directory-kompatiblem Domänen unterstützt UCS außerdem die DNS-Komponente von Samba 4, die dann als Basis für die Nameserver anstelle von OpenLDAP auftritt. Ein eigenes Werkzeug kümmert sich in solchen Setups allerdings darum, dass die DNS-Einträge aus Samba in OpenLDAP landen und vice versa. Weil UCS auch einen DHCP-Server (der einiger Konfiguration bedarf, während DNS weitgehend automatisiert eingerichtet wird) selbst betreibt, ist in der Standardkonfiguration jedenfalls sichergestellt, dass Clients die richtigen DNS-Server kennen.

Ein Einsatz als allgemeiner, rekursiver oder autoritativer Nameserver für bestimmte Domänen ist hingegen nicht vorgesehen. Komplementär zu UCS werden entsprechende Nameserver idealerweise bereits vor der UCS-Installation eingerichtet, um sie in UCS anschließend als „Forwarding Server“ zu nutzen – stellen Clients dann DNS-Anfragen, die der in UCS integrierte Nameserver nicht selbst beantworten kann, leitet er sie an die extern konfigurierten Server weiter. Alternativ dazu lässt UCS sich so konfigurieren, dass es Verbindungen zu den DNS-Root-Servern selbst übernimmt.

Externe DNS-Server müssen Admins übrigens nicht zwingend selbst betreiben. Denkbar wäre etwa auch, auf die meist angebotenen Nameserver des eigenen Domain Registrars zurück zu greifen. Die lassen sich nämlich meist per komfortablem GUI steuern (Abbildung 7).

Abbildung 7: Externe Nameserver bieten die meisten Domain-Registrierer an. Sie sind leicht zu konfigurieren und komfortabel zu nutzen.

Wir hoffen, dass Ihnen diese Einführung in das Thema DNS gefallen und weitergeholfen hat. Haben Sie Fragen, Anregungen oder Ergänzungen? Wir freuen uns auf Ihre Kommentare!