Konfiguration und Betrieb eines Nameservers, Teil 1

Die folgende Artikelserie beschäftigt sich eingehend mit Aufbau und Betrieb eines Nameservers. In der Anfangszeit des Internets wurde an zentraler Stelle die Datei hosts.txt gepflegt, die dann von den Administratoren auf die lokalen Rechner kopiert wurde. Dieses Verfahren ist jedoch nur für relativ kleine Netze praktikabel, so dass ein neuer Service, nämlich der Domain Name Service (DNS), entwickelt wurde. Heute ist die Client-Seite dieses Services Bestandteil aller verbreiteten TCP/IP-Implementationen.

Viele Betriebssysteme werden bereits mit den passenden Server-Programmen geliefert oder diese sind separat erhältlich. Das Internet wäre ohne DNS heute gar nicht denkbar, da die Strukturen viel zu groß, komplex und dynamisch geworden sind. DNS ist heute vermutlich die größte, real existierende und funktionierende verteilte Datenbank.

Die Artikelserie basiert auf dem Kapitel 22 des Standardwerks „Linux Systemadministration, Einrichtung, Verwaltung, Netzwerkbetrieb“ von Jochen Hein aus dem Verlag Addison-Wesley. Sie können dieses über 600 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.

Serie: Konfiguration und Betrieb eines Nameservers

Teil 1	Aufbau eines Nameservers
Teil 2	Nameserver im Detail
Teil 3	Betrieb eines Nameservers

Nameserver für lokale Netz

Auch lokale Netze ab einer gewissen Größe profitieren vom Einsatz eines Nameservers, auch wenn dieses Netz nicht mit dem Internet verbunden ist. Der Verwaltungsaufwand, der durch viele (verschiedene) hosts-Dateien entsteht, und Probleme durch inkonsistente Einträge werden vermieden. Unter Linux und vielen anderen Unix-Systemen kommt als Nameserver das Paket BIND (Berkeley Internet Name Domain) zum Einsatz.

Von dieser Implementierung gibt es auch eine Windows-Portierung. Ausführliche Informationen zur Konfiguration und zum stabilen Betrieb eines Nameservers finden Sie in den Quellen zu BIND. Das Programm, das die Datenbasis verwaltet und Anfragen der Clients beantwortet, heißt named. Auf der Client-Seite wird die Resolver-Bibliothek verwendet, die mit dem Nameserver kommuniziert.

Das Konzept des Domain Name Service

Die Namensverwaltung im Internet ist hierarchisch aufgebaut. Ganz oben in der Hierarchie stehen die so genannten Root-Nameserver. Diese Rechner sind zunächst für die Auflösung aller Namen zuständig. Bei diesen Rechnern wird ein getragen, dass für einzelne Zonen jeweils ein anderer Nameserver zuständig (authority) ist. Man sagt, dass diese Zone delegiert wurde. Eine Domain, wie man sie aus dem Host-Namen kennt, ist nicht in jedem Fall mit einer DNS-Zone identisch.

Die oberste Zone, die hier nicht näher betrachtet wird, ist .org. Hier wurden die Zonen example.org, example.com und xpilot.org an andere Nameserver delegiert. In unserer Beispiel-Domain betreibt die Abteilung Einkauf einen eigenen Nameserver. Daher ist die Sub-Domain einkauf.example.com nicht Bestandteil der Zone example.com. Diese Zone ist in der Abbildung durch die gestrichelte Linie markiert.

Eine Zone wird technisch durch einen NS-Datensatz im übergeordneten Nameserver bestimmt. Eine Zone kann identisch mit einer Domain sein, es können aber auch für Sub-Domains weitere Nameserver als zuständig definiert sein, die dann wieder eine eigene Zone verwalten. Diese Trennung ergibt sich oft aus organisatorischen Gegebenheiten, seien es andere Verantwortlichkeiten für die Netzverwaltung oder die räumliche Trennung zwischen einzelnen Abteilungen oder Zweigstellen.

Anwender verwenden in der Regel nur Rechnernamen und keine IP-Adressen, weil gut gewählte Namen leichter zu merken sind. Daher ist der Ausfall des Nameservers oft gleichbedeutend mit dem Ausfall des Netzes. In jeder Zone sollten daher mehrere Nameserver aktiv sein, wobei einer der primäre Nameserver (primary name server) und alle anderen sekundäre Nameserver (secondary name server) sein sollten. Es ist sinnvoll, diese Rechner auf verschiedene Netzsegmente zu verteilen, damit auch beim Ausfall eines Routers oder Hubs immer noch ein Nameserver erreichbar ist. Im Internet sollten der primary und der secondary Nameserver in verschiedenen Netzen liegen und über verschiedene Provider erreichbar sein. Ein Secondary-Server ist praktisch wartungsfrei, da er seine Daten automatisch vom Primary-Server holt. Sie sollten nur gelegentlich einen Blick in die Log-Dateien werfen.

Auswahl eines DNS-Servers

Auch beim DNS-Server haben Sie die Wahl unter verschiedenen Programmen. Das wohl am häufigsten eingesetzte Programm ist BIND, das wir im Folgenden genauer betrachten werden. BIND ist vergleichsweise alt, gut gepflegt und sehr stabil. Besonders für größere Server wird es gerne eingesetzt.

Am anderen Ende der Skala finden Sie dnrd. Dies ist ein kleiner und handlicher Nameserver für kleine Netze. Das Besondere an ihm ist, dass er die Datei /etc/hosts liest und daraus dynamisch die benötigten Zonen generiert. Mit der Option -s können Sie Nameserver angeben, die als Forwarder verwendet werden sollen. Damit ist dnrd eine interessante Alternative für per Wählverbindung ans Internet angebundene Netze.

Ein weiterer Nameserver ist djbdns, der von Prof. Bernstein mit Blick auf Sicherheitsaspekte entwickelt wurde. Der Einsatz dieses Programms gilt als Geschmackssache. Wie auch immer, in den folgenden Abschnitten beschäftigen wir uns mit BIND.

Allgemeines zur Konfiguration eines Nameservers

Die Datei /etc/resolv.conf kann im Vergleich zu einem einfachen DNS-Client unverändert bleiben. In diesem Fall ist der Server auch sein eigener Client, was in den meisten Fällen gewollt sein dürfte (das ist auch der Standardwert, falls keine /etc/resolv.conf existiert). Es ist aber auch möglich, einen anderen Nameserver zu verwenden, als denjenigen auf dem lokalen Rechner.

Ab der Version 8 des BIND erfolgt die Konfiguration mit Hilfe der Datei /etc/named.conf. Sollten Sie bereits eine lauffähige Konfiguration einer älteren BIND-Version haben, dann können Sie die Datei /etc/named.boot mit Hilfe des Skripts named-bootconf.sh in das neue Format konvertieren. Anschließend sollten Sie aber die erstellte Datei prüfen und eventuell weitere Anpassungen vornehmen.

Ein Beispiel für einen primären Nameserver finden Sie in Listing unter Vorteile eines Nameservers. In dieser Datei werden die Domain und andere globale Daten, wie beispielsweise. das Arbeitsverzeichnis des named, festgelegt. Außerdem werden die Namen der zugrunde liegenden Dateien bestimmt. Nach dem Ändern der Datenbasis muss der named die Daten neu lesen. Dazu kann man dem Dämon das Signal SIGHUP schicken (z. B. mit kill -HUP $(cat/var/run/named.pid)) oder das Kommando rndc reload verwenden. Mit dem Kommando rndc restart kann der Dämon beendet und neu gestartet werden. Ein weiteres wichtiges Signal ist SIGINT, das den Dämon veranlasst, seine Datenbank in die Datei /var/tmp/named_dump.db auszugeben. Dies ist für die Fehlersuche manchmal notwendig. Zur Steuerung des Dämons existieren noch diverse weitere Signale, die in der Manpage dokumentiert sind.

Primary Nameserver

Es existieren eine Reihe von Nameserver-Typen. In jeder Zone muss es einen Primary Nameserver geben, der die maßgeblichen (authoritative) Daten für die Zone verwaltet. Aus Gründen der Ausfallsicherheit sollte es in einer Zone mindestens einen weiteren Nameserver geben, der dann als Secondary Server betrieben wird. Die notwendigen Konfigurationen für einen Secondary Server finden Sie im zweiten Teil der Artikelserie. Für Rechner oder Netze, die nur temporär, z. B. mittels PPP, mit dem Internet verbunden sind, kann es sinnvoll sein, einen Caching-Only-Nameserver einzurichten. Der Betrieb eines Nameservers erfordert sowohl zusätzliche Rechenleistung und mehr Speicher auf dem entsprechenden Rechner als auch zunächst einen höheren Administrationsaufwand im Vergleich zum einfachen Editieren der Datei /etc/hosts.

Im Wesentlichen gibt es zwei (zwingende) Gründe dafür, einen eigenen Nameserver zu installieren:

• Sie beantragen eine neue Domain. Besprechen Sie mit Ihrem Provider, wer den Nameserver für diese Domain betreibt. Wollen Sie den Nameserver selbst betreiben, so muss Ihr Provider dies bei sich entsprechend konfigurieren. Oft wird Ihr Provider den Nameserver zunächst für Sie betreiben.

• Sie wollen innerhalb einer bereits bestehenden Domain für einen organisatorischen Bereich einen neuen Nameserver einrichten. Dies müssen Sie mit Ihrem Netzverwalter besprechen, sonst wird Ihr neuer Server nicht als autorisiert anerkannt.

Vorteile eines Nameservers

Ein eigener Nameserver hat aber auch Vorteile, egal ob Sie an das Internet angeschlossen sind oder nicht:

• In einem lokalen Netz sind auf jedem Rechner alle anderen Rechnernamen immer bekannt.

• Die Datenbasis ist immer auf allen Rechnern aktuell und konsistent. Die andernfalls auf den verschiedenen Rechnern notwendigen hosts-Dateien veralten schnell und widersprechen sich möglicherweise.

• Die Namensvergabe und IP-Adresszuordnung ist konsistent.

• Wenn Sie den Nameserver selbst betreiben, können Sie die Daten ändern, ohne Ihren Provider einschalten zu müssen.

Im folgenden Listing finden Sie ein Beispiel für die Datei /etc/named.conf auf einem primären Nameserver. Mit directory im Abschnitt options wird das Verzeichnis bestimmt, in dem die Dateien dieses Nameservers abgelegt werden.

# Konfig-File für den Name-Server options {directory "/etc/named";};
# Root Name-Server
zone "." {type hint; file "named.root"; };
zone "jochen.org" {type master; file "named.hosts";};
zone "0.0.127.in-addr.arpa" {type master; file "named.local";};
zone "168.192.in-addr.arpa" {type master; file "named.rev";};

Ein Rechner kann für mehrere Zonen der primäre und/oder sekundäre Nameserver sein. Für jede Zone ist ein Abschnitt zone einzufügen und die entsprechenden Daten müssen verfügbar sein.

Nameserver und Cache

Jeder Nameserver sollte einen Cache der Anfragen und Antworten anlegen. Dies wird mit dem Schlüsselwort cache bewirkt. Beim Start des Nameservers werden alle noch korrekten Daten aus named.root erneut in den Cache geladen. Ein Nameserver wird zum Cache-Only-Server, wenn in der Datei named.boot keine primary oder secondary Schlüsselwörter vorhanden sind.

Der Nameserver muss wissen, wo er den maßgeblichen Name-Server für die Root-Domain des Netzwerks findet. Diese Information ist in der Datei named.root gespeichert. In vielen Dokumentationen heißt diese Datei auch root.cache, was aber deren Verwendung nicht beschreibt. Diese Datei liegt, wie alle anderen Datendateien auch, im Standard Resource Record Format oder auch im Masterfile-Format vor. Eine ausführliche Beschreibung dieses Formats finden Sie im BIND-Operators Guide, eine Einführung in den folgenden Abschnitten.

Der Nameserver im oben angeführten Listing ist primärer (primary) Nameserver für die Zone jochen.org. Die Datenbasis befindet sich in der Datei named.hosts im Verzeichnis /var/named. Außerdem ist er der primäre Server für die Zonen 0.0.127.in-addr.arpa und 168.192.in-addr.arpa, die zum „Reverse-Lookup“ dienen. Mehr Informationen zum Reverse-Lookup finden Sie im zweiten Teil der Artikelserie. Im nächsten Schritt müssen die Daten der einzelnen Rechner in die entsprechenden Dateien, deren Namen in der Datei /etc/named.boot festgelegt wurden, eingetragen werden. Das Format dieser Dateien und die wichtigsten Einträge werden auf den folgenden Seiten genauer erläutert.

Die Datei named.hosts

In der Datei named.hosts werden die Daten für alle Rechner in der Zone gespeichert. Das Format und die einzelnen Einträge werden im folgenden Abschnitt beschrieben, da sie auch in den anderen Dateien zur Konfiguration eines Nameservers verwendet werden. In diese Datei tragen Sie alle Hosts der Zone ein, für die Sie autorisierter Nameserver sind. Im folgenden Listing finden Sie ein Beispiel:

@ IN SOA janus.jochen.org. hostmaster.jochen.org. (
1997040101 ; Serial
28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ) ; Minimum TTL 1 day
IN MX 10 hermes
IN NS janus.jochen.org.
karotte IN A 192.168.3.150
mais IN A 192.168.3.151
kohlrabi IN A 192.168.3.152
bohne IN A 192.168.3.154
erbse IN A 192.168.3.155
HINFO IBM-PC/AT UNIX-PC
IN TXT "Test mit Text"


Wenn Sie auf Ihrem Nameserver viele Zonen eingerichtet haben, dann werden Sie den Dateinamen sicher sprechend wählen, also den Namen der Zone verwenden. Wenn Sie sehr viele Zonen haben oder Nameserver für verschiedene Kunden betreiben, dann kann es sinnvoll sein, die Zonen in verschiedene Verzeichnisse zu sortieren.

Das Masterfile-Format

Eine Datendatei für den Nameserver besteht aus einzelnen Sätzen, Resource Records (RR), und wird Masterfile-Format genannt. Ein Datensatz besteht aus den im folgenden Listing dargestellten Teilen.

{name} {ttl} addr-class Record Type Record Specific data

Im Feld name finden Sie den zum Eintrag gehörenden Namen des Rechners oder der Domain. Das Feld ttl enthält die Time To Live, die bestimmt, wie lange diese Daten in der Datenbank gespeichert werden. Wird kein Wert angegeben, so ist der Standardwert der im SOA-Satz angegebene. Außerdem kann der Standardwert für die TTL mit dem Schlüsselwort $TTL am Anfang der Datei eingestellt werden. Im Internet wird als Adressklasse IN verwendet. Das vierte Feld enthält die Satzart, danach folgen die für die Satzart notwendigen Daten.

In den Dateien im Masterfile-Format haben eine Reihe von Zeichen eine besondere Bedeutung:

• Der Punkt (.) steht für die aktuelle Domain, für die die Daten gelten sollen.

• Das at-Zeichen (@) steht für das Origin, das ist die Zone, für die der Nameserver zuständig ist.

• Die Zeichen .. im Feld Name stehen für die Null-Domain.

• Die Zeichenfolge \X, wobei X eines der speziellen Zeichen ist, maskiert diese Sonderbedeutung und steht für das Zeichen selbst.

• Die Zeichenfolge \DDD mit D als Ziffern steht für das Zeichen mit dem ASCII-Code DDD.

• Ein Datensatz kann sich über mehrere Zeilen erstrecken, wenn die Daten in runde Klammern () eingeschlossen werden.

• Ein Semikolon (;) leitet einen Kommentar ein, der bis zum Zeilenende geht.

• Der Stern (*) wird im Feld Name bei einigen RR-Typen (z. B. MX) speziell interpretiert. Diese spezielle Bedeutung gilt nicht im Datenbereich.

Ausblick

Der zweite Teil der Artikelserie „Konfiguration und Betrieb eines Nameservers“ beschäftigt sich detailliert mit den Zonen. Es folgen darüber hinaus ausführliche Informationen zum Secondary und Slave Nameserver.

Im dritten und letzten Teil der Artikelserie beschäftigen wir uns mit dem Betrieb eines Nameservers. Dazu gehört beispielsweise das dynamische DNS-Update. Ebenso ist das Thema Sicherheit und DNS ein entscheidender Faktor beim Betrieb eines Nameservers. (mje)