© oleksandr parkhomovskyy, Fotolia.com

Erst wenn der DNS sich ausschweigt, merkt der Admin, wie essenziell der Auskunftsdienst ist. Das LPI verhindert, dass er nur bei einem Crash über Namensauflösung und Bind-Konfiguration nachdenkt.

Plötzlich geht nichts mehr, das Telefon klingelt unablässig: “Das Internet geht nicht”, ist sicherlich eine der von Systemadministratoren häufig gehörten Problembeschreibungen. Nachdem der Admin ohne Erfolg die Netzanbindung überprüft hat (siehe Folgen 14 und 15 der LPI-Reihe, [1], [2]), ist das Domain Name System (DNS) oft ein Kandidat für die Ursache [3]. Diese Folge des LPI-Kurses erklärt das Wichtigste, das ein Systemverantwortlicher zum DNS bei der LPI-Prüfung wissen muss.

Web- und Mailserver nutzen im Internet als Transportprotokolle TCP und UDP, sind technisch also nur über ihre IP-Adresse erreichbar. IP-Adressen können sich Menschen nur schlecht merken. Bei Namen ist dies einfacher. Einen Mechanismus, um von einem Namen zu einer IP-Adresse zu gelangen, ist also nötig. Er nennt sich Namensauflösung, Nameserver setzen ihn um.

Die Grundlagen von DNS legen RFC 1034 und RFC 1035 [4] fest. Sie beschreiben unter anderem, wie ein DNS-Name aufgebaut ist. Folgen von bis zu 63 Buchstaben, Ziffern und dem Bindestrich bilden jeweils ein Label. Das DNS unterscheidet nicht zwischen Groß- und Kleinschreibung. Durch einen Punkt getrennt bilden die Labels einen Baum, die höher stehenden Elemente stehen rechts.

Baumstrukturen

Eine DNS-Domain ist ein Teilbaum dieser Struktur. Registraturen verwalten die an oberster Stelle stehenden Top Level Domains (TLDs, [5]). Ursprünglich hatten die einzelnen TLDs inhaltliche Bedeutungen, beispielsweise ».com« für Unternehmen oder ».de« für Deutschland. Heute kann aber effektiv jeder bei einem Registrar oder einem lizenzierten Dienstleister eine Domain zu jeder TLD beantragen. Die Domäne »linux-magazin.de« ist Teil der TLD »de« und beim deutschen Registrar DENIC verzeichnet. In einer Domäne können entweder Namen wie »www.linux-magazin.de« oder weitere Subdomains liegen. Große Unternehmen oder Universitäten strukturieren so ihre Netze weiter: »informatik.uni-kl.de« ist ein solches Beispiel.

Rollenspiele

Admins stehen dem nach dem Client-Server-Prinzip operierenden Domain Name System in zwei Rollen gegenüber. Als Clients wollen sie es ihren Benutzern ermöglichen, Namen aufzulösen. Umgekehrt bieten sie für die von ihnen betreuten Systeme selbst einen Namensdienst an, damit andere Benutzer deren Namen in IP-Adressen wandeln können.

Die Konfiguration der Namensauflösung als Client ist schnell erledigt. Die Datei »/etc/hosts« dient der Umsetzung von Rechnernamen in IP-Adressen ohne DNS. Sie enthält eine Liste mit den IP-Adressen auf der linken und den zugehörigen Namen auf der rechten Seite:

192.168.2.20    alpha.example.com alpha

Da sich im Internet viele Einträge ändern und immer weitere hinzukommen, ist die Pflege einer großen Datei »/etc/hosts« nicht praktikabel. Bis Anfang der 1980er Jahre haben aber die Pioniere des Internets so Namensauflösung betrieben. Dazu tauschten sie die immer größer werdenden Hosts-Dateien per Filetransfer aus. Eine neue Lösung musste her. Als verteilte Datenbank kam schließlich das DNS zum Einsatz.

Welche Methode angewendet werden soll, legt der Admin in »/etc/nsswitch.conf« fest. Steht dort

hosts:     files dns

so befragt der Resolver der Standardbibliothek Libc zunächst die Dateien, danach das DNS. Wer die Reihenfolge umkehren möchte, vertauscht die Schlüsselwörter »files« und »dns«.

Namensauflösung

Die Hauptaufgabe eines DNS-Resolvers besteht also darin, den Namen zu einer IP-Adresse aufzulösen. Tatsächlich kann er auch eine Reihe weiterer Angaben abfragen, beispielsweise den Namen zu einer IP-Adresse ermitteln, einen so genannten Reverse-Lookup. Der Resolver befragt dazu einen Nameserver, der in der Datei »/etc/resolv.conf« eingetragen ist. Nach dem Schlüsselwort »nameserver« steht dessen IP-Adresse:

nameserver 192.168.2.20
nameserver 192.168.1.1

Eine Änderung erfolgt entweder manuell durch den Administrator oder automatisch per DHCP. Bis zu drei Nameserver können hier stehen, aber nur einer pro Schlüsselwort. Fehlt der Eintrag »nameserver«, erhält per Default ein Nameserver auf »localhost« alle Anfragen.

In Unternehmensnetzen finden sich oft Nameserver, die sich das Leben einfach machen. Sie sammeln praktisch nur alle Anfragen und reichen sie an einen weiteren Nameserver weiter, beispielsweise bei einem Provider. Dabei speichern sie die erhaltenen Antworten eine Weile, um nicht immer wieder die gleichen Anfragen stellen zu müssen. So ein Server ist ein Caching Forwarder.

Die tatsächliche Auflösung von Namen über das verteilte DNS kann nach verschiedenen Mustern ablaufen, die in den jeweiligen Nameservern konfiguriert sind. Ist ein befragter Nameserver selbst für die angefragte Domain zuständig, löst er den Namen sofort auf.

Verwaltet er die Domain nicht, kann er entweder wieder einen weiteren Forwarder befragen oder er wendet sich direkt an einen der gegenwärtig 13 bestehenden Root-Nameserver im Internet. Jeder Nameserver hat die IP-Adressen der Root-Server fest konfiguriert. Die Root-Server geben ihrerseits Hinweise, wo ein zuständiger (authoritative) Nameserver zu finden ist. Eine Übersicht des Ablaufs illustriert Abbildung 1.

Abbildung 1: Von der Browsereingabe bis zur erhaltenen IP-Adresse ist eine Reihe von Schritten zu durchlaufen. Das Domain Name System übernimmt für den Benutzer diese Aufgabe.

Für jede Domain gibt es mindestens einen Server, der für ihre Verwaltung zuständig ist. Ein Nameserver kann auch mehrere Domains verwalten. Es ist sogar möglich, ein unabhängiges DNS zu verwalten, beispielsweise zu Testzwecken. Es ist dann selbstverständlich nicht mit dem weltweiten DNS verbunden. Größere Unternehmen machen dies gelegentlich, um ihre internen Strukturen vor Externen zu verbergen.

Bind als Caching Forwarder

Es gibt verschiedene Implementationen für Nameserver. Verbreitet unter Linux ist Bind (Berkeley Internet Name Domain, [6]). Aktuell ist die Version 9, aber auch die Version 8 ist noch in Betrieb. Diese Implementationen sind auch Gegenstand der LPI-Prüfung.

Der Bind-Server »named« liest seine Konfiguration aus der Datei »/etc/named.conf«. Er ist bereits mit den mitgelieferten Einträgen ohne eine Änderung als Caching-only-Nameserver lauffähig. Er ist dann aber für keine Domain verantwortlich. Listing 1 zeigt eine minimale Konfiguration. Sie besteht aus einer Folge von Blöcken, die ein Semikolon abschließt. Zeilen mit einem führenden »#« leiten einen Kommentar ein. Der Block »options« enthält globale Einstellungen. Der Eintrag »directory« legt ein Verzeichnis fest, aus dem Bind später weitere Dateien einbindet.

01 options {
02   directory "/var/lib/named";
03   forwarders { 192.0.2.1; 192.0.2.2; };
04   forward first;
05 }
06 
07 zone "." IN
08     { type hint;   file "root.hint"; };
09 zone "localhost" IN 
10     { type master; file "localhost.zone"; };
11 zone "0.0.127.in-addr.arpa" IN
12     { type master; file "127.0.0.zone"; };

Immer der Reihe nach

Anfragen können entweder von einem Forwarder, der in der Regel beim Provider steht, oder von den Root-Servern beantwortet werden. Um die Belastung der Root-Server zu verringern, sollten Admins dem Forwarder den Vorzug geben. Diese Reihenfolge legt die Einstellung »forward first« fest. Niemals fragt der Nameserver bei den Root-Servern an, wenn »forward only« in der Konfiguration steht. Der Eintrag »forwarders« bestimmt die Server dafür. Es sind in diesem Block etliche weitere Optionen möglich, die aber für die Prüfung LPI 102 nicht relevant sind.

Die Konfiguration enthält am Ende die Verweise auf Zone-Files. Eine Zone fasst alle Einträge einer Domain zusammen, solange sie keine Subdomains hat. Letztere bilden wieder eine eigene Zone. Selbst ein reiner Cache muss einige Zonen definieren, mindestens die im Beispiel aufgeführten Einträge sind nötig. Die erste Zonenbeschreibung enthält Verweise zu den Root-Nameservern (in der Datei »root.hint«), die als Anlaufstelle bei Anfragen zu unbekannten Domains dienen. Der nächste Eintrag ist für die Auflösung des Namens »localhost« und der dritte für dessen Rückwärtsauflösung zuständig.

Zonen

Direkt hinter dem Schlüsselwort »zone« steht in doppelten Anführungszeichen der Name der Domain, so wie er im Internet bekannt sein soll. Das Schlüsselwort »IN« symbolisiert die Klasse Internet. Das Schlüsselwort »type master« legt fest, dass der Nameserver für die Zone verantwortlich zeichnet. Den Dateinamen der Zone legt »file« fest.

Alle Dateien müssen von dem Benutzer »named« lesbar sein. Eventuell erkannte Fehler legt der Nameserver über den Syslog-Mechanismus in »/var/ log/messages« ab. Das Kommando »named-checkconf -z« prüft die Syntax der Konfiguration und lädt dabei auch die einzelnen Zonen.

Soll nur ein Caching-Nameserver laufen, reichen die bei Bind mitgelieferten Zonendateien aus. Soll der Nameserver jedoch für eine Domain oder Subdomain zuständig sein, muss der Admin eigene Zonendateien anlegen und diese in die Konfiguration einbinden:

zone "example.com" IN { type master; file "example.zone"; };

Die Zonendefinition für die Domäne »example.com« befindet sich so in der Datei »example.zone«. Solche Dateien bestehen aus einer Liste von so genannten Ressource-Records, die Daten zu einer Domain speichern. Jeder Record hat die in Tabelle 1 beschriebenen Elemente.

Ein Beispiel für zwei Einträge, die dem Namen »www« und dem Domänennamen selbst (per Platzhalter »@«) innerhalb der Zone die IP-Adresse 192.0.2.66 zuordnen:

www  1D IN     A    192.0.2.66
@    1D IN     A    192.0.2.66

Die verschiedenen Angaben zu der Domain legt der Administrator durch entsprechende Record-Typen fest (siehe Tabelle 2). Jede Zone benötigt einen SOA-Record (Start of Authentication) mit Verwaltungsinformationen der Domain. Den genauen Aufbau dieses Record zeigt Tabelle 3. Angaben zu Name- und Mailservern (NS-Record respektive MX-Record) und natürlich zu den IP-Adressen der verwalteten Namen (A-Record) sollten nicht fehlen.

Alle anderen Records sind optional in einer Zonendefinition. Kommentare beginnen in Zonendateien mit einem Semikolon oder mit einem doppelten Slash, aber nicht mit einem Doppelkreuz.

Resource-Records

Listing 2 zeigt als Beispiel den Inhalt von »example.zone«. Zu Beginn wird ein TTL-Wert für die Lebensdauer der Einträge gesetzt, der für alle nachfolgenden Records gilt. Zeiteinträge ohne Suffix haben die Einheit Sekunden. Als Suffixe bedeuten »M« Minute, »H« Stunde (Hour), »D« Tag (Day) und »W« Woche (Week). Der Platzhalter »@« steht für den Domain-Namen, wie er in der Datei »/etc/named.conf« im Verweis auf diese Zonendatei eingetragen ist.

01 $TTL 1D
02 @ IN  SOA  ns.example.com. max.example.com. (
03            2007120601   ; serial number
04            3H           ; refresh
05            30M          ; retry
06            1W           ; expire
07            1D           ; ttl )
08            IN  NS     ns.example.com.
09            IN  MX 10  mail.example.com.
10 
11 @          IN  A      192.168.1.1
12 ns         IN  A      192.168.1.2
13 www        IN  CNAME  ns
14 mail       IN  A      192.168.1.3

Wer es Benutzern ermöglichen will, IP-Adressen in DNS-Namen aufzulösen (Reverse-Lookup), muss eine eigene Zone unterhalb von »in-addr.arpa« anlegen, die mit Hilfe von PTR-Records die Abbildung von IP-Adressen auf Namen erledigt. Diese Definition muss jedoch der Besitzer der IP-Adressen vornehmen, der nicht immer identisch mit dem Besitzer der Domain sein muss.

Der »named« sollte möglichst in einer »chroot«-Umgebung und unter einem gesonderten Account ohne Root-Rechte laufen. Um den Nameserver zu starten oder zu stoppen, kommen die bekannten Initskripte zur Anwendung: »/etc/init.d/named start« beziehungsweise »/etc/init.d/named stop« erledigen diese Aufgabe. Damit der Dienst »named« auch nach einem Neustart des Rechners aktiv ist, muss er in den gewünschten Runlevels (meist 3 und 5) eingetragen sein.

Starten, Steuern, Stoppen

Um weitere Befehle an den Server zu schicken, stellt Bind 8 das Programm »ndc« bereit. Es kommuniziert mit dem Server über den Socket »/var/run/ndc«. Ab Version 9 ist das Programm »rndc« dafür zuständig. Es steuert den Nameserver über das Netz per TCP-Port 953. Mit der Option »-h« aufgerufen gibt es eine kurze Hilfe über alle verfügbaren Kommandos aus. Damit nicht jeder von anderen Rechnern her Kommandos absetzt, benötigt das Programm einen Schlüssel, der in der Datei »/etc/rndc.key« liegt. Mittels

# rndc reload

kann nun beispielsweise der Admin den Server dazu anweisen, seine Konfiguration und die Zonenbeschreibungen neu einzulesen.

Kontakt mit der Außenwelt

Um mit der Außenwelt zu kommunizieren, nutzt der Nameserver den Syslog-Dienst. Meldungen erscheinen so in der Datei »/var/log/messages«. Es ist ratsam, diese laufend zu überwachen, wie zum Beispiel als Root mit »tail -f /var/log/messages« in einer Konsole. Gerade bei Änderungen an der Konfiguration oder bei neuen Zonendateien zahlt sich genaues Hinschauen aus.