zurück zu Linux Zertifizierungen LPIC
1.113.5 – Einrichtung und Konfiguration grundlegender DNS-Dienste
Prüfungskandidaten sollten in der Lage sein, Namensauflösung zu konfigurieren und Probleme mit lokalen caching-only Nameservern zu lösen. Dies benötigt ein Verständnis der Prozesse der Domainregistrierung und der DNS-Auflösung. Ebenfalls erforderlich ist ein Verständnis der wichtigsten Unterschiede der Konfigurationsdateien von BIND und BIND 8.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /etc/hosts
* /etc/resolv.conf
* /etc/nsswitch.conf
* /etc/named.boot (v.4) oder /etc/named.conf (v.8)

Adressen in einem IP-Netzwerk sind immer nummerische Adressen. Diese Adressen sind zwar logisch aufgebaut, jedoch nicht unbedingt dafür geeignet, daß man sich davon 500 verschiedene merkt. Menschen erinnern sich einfach lieber an Namen als an Nummern.

Um dieser Tatsache Rechnung zu tragen bietet Linux ein System an, wie IP-Adressen mit Namen verknüpft werden können.

Die Bibliotheksfunktionen gethostbyname und gethostbyaddr sind für die Verwaltung der Hostnamen und IP-Adressen zuständig. Jedes Programm, das mit IP-Adressen oder Hostnamen umgeht, benützt diese Funktionen.

Es existieren mehrere Informationsquellen, die von diesen beiden Funktionen benutzt werden, um einen Namen mit einer Adresse zu verknüpfen.

* Die Datei /etc/hosts
Diese Datei enthält IP-Adressen und dazu passende Namen (Siehe auch Abschnitt 1.112.3). Sie dient dazu, die Namen der Rechner im lokalen Netz zu verwalten und eventuell noch häufig benutzte Namen fremder Rechner mit Adressen zu versehen. Diese Technik ist aber sehr statisch. In einem lokalen Netz können wir uns darauf verlassen, daß sich Adressen nicht dauernd ändern, aber in einem fremden Netz gibt es dafür keine Garantie.
* Das Domain Name System (DNS)
Dieses System teilt das gesamte Internet in Verwaltungseinheiten (domains) auf, die autonom administriert werden. Jede Domain betreibt sogenannte Nameserver, die die Adressen und Hostnamen ihres Verwaltungsgebietes kennen. Die Nameserver sind über eine Art Baumstruktur miteinander verbunden, so daß man die Summe aller Nameserver als globale und verteilte Datenbank betrachten kann. Jeder Nameserver kann über die Informationen über die über ihm liegenden Nameserver jede beliebige Adresse im Internet herausfinden. Welche Nameserver benutzt werden sollen, wird in der Datei /etc/resolv.conf eingestellt.

In welcher Reihenfolge diese Informationsquellen herangezogen werden, kann in den Dateien /etc/host.conf und /etc/nsswitch.conf festgelegt werden. All diese Zusammenhänge sind bereits im Abschnitt 1.112.3 besprochen worden.

Die Technik der Nameserver bedingt natürlich eine zentrale Verwaltung. Diese Verwaltung wird von einer Organisation mit Namen IANA (Internet Assigned Numbers Authority) abgewickelt. Die Struktur des gesamten DNS-Systems wird über eine überschaubare Menge von Toplevel-Domains gesteuert.

Es gibt zwei unterschiedliche Arten von Toplevel-Domains. Die sogenannten generischen und die länderspezifischen Toplevel-Domains. Die generischen Domains sind 14 festgelegte Domains, die alle eine bestimmte Bedeutung haben:

* .aero
neu, reserviert für Mitglieder der Luftfahrtindustrie.
* .biz
eine neu angelegte Toplevel-Domain nur für Unternehmen (businesses).
* .com
die alte Toplevel-Domain für kommerzielle Unternehmen.
* .coop
eine neue Domain für Kooperativen.
* .edu
reserviert für Bildungseinrichtungen, die bei einer der sechs US-amerikanischen Agenturen akkreditiert sind.
* .gov
reserviert für Einrichtungen der US-amerikanischen Regierung.
* .info
eine neue Domain für informative Einrichtungen.
* .int
eine neue Domain, reserviert für Organisationen, die aufgrund internationaler Verträge zwischen Regierungen zustande kamen.
* .mil
reserviert für Einrichtungen des US-amerikanischen Militärs.
* .museum
eine neue Domain nur für Museen.
* .name
eine neue Domain, für die Verwendung im Privatbereich.
* .net
ursprünglich für die Netzverwaltung gedachte Domain, die heute frei verfügbar ist.
* .org
eine Domain für nicht kommerzielle Organisationen.
* .pro
Eine im Aufbau befindliche Domain, reserviert für Berufsverbände.

Neben diesen generischen Toplevel-Domains existieren für jedes Land der Erde eine länderspezifische Domain. Diese Domain trägt als Namen die zwei Buchstaben ISO-Länderkennung. Eine vollständige Liste der existierenden Länderdomains erhalten Sie bei der IANA selbst unter www.iana.org/cctld/cctld-whois.htm.

Jede Toplevel-Domain wird von einer bestimmten Organisation verwaltet, die wiederum Domains unterhalb ihres Verwaltungsgebietes vergeben kann. So kann etwa die Verwaltung der deutschen Topleveldomain .de der Firma foo die Domain foo.de überlassen. Wichtig ist dabei, daß jede echte Domain – egal ob Toplevel oder nicht – einen oder mehrere Nameserver betreiben muß, die ihren jeweiligen Zuständigkeitsbereich abdeckt.

Auf der Wurzel des Baums des DNS arbeiten noch die sogenannten root-server, Nameserver, die die Namen aller Toplevel-Domains kennen und die Information über die von ihnen verwendeten Nameserver bereithalten.

Jeder Nameserver, egal ob der einer Toplevel-Domain oder einer gewöhnlichen, kennt die Liste aller root-server. Wenn jetzt ein Nameserver nach einer bestimmten Adresse sucht, so fragt er zunächst einmal einen root-server nach dem Nameserver der Toplevel-Domain dieser Adresse. Der wiederum kennt den Nameserver der Subdomain und der kennt – hoffentlich – die Adresse, die gesucht wurde.

Das gesamte Domain-System des Internets kann als eine große, weltweit verteilte Datenbank verstanden werden. Die einzelnen Knoten der Datenbank sind die Nameserver der verschiedenen Domains, die über die root-Server miteinander verbunden sind. Wie jede andere Datenbank auch, so hat auch die DNS-Datenbank eine vorgegebene Struktur und vorgegebene Feldeinträge.

Jeder Datensatz einer DNS-Datenbank besteht aus folgenden Elementen:

Domain-name
Der Name der Domain, auf den sich der Datensatz bezieht.
Time-to-live
Dieser Wert ist optional und bezeichnet die Stabilität eines Eintrags, also die Frage, wie lange er gültig sein soll. Wird häufig weggelassen.
Type
Gibt an, um was für einen Typ Datensatz es sich handelt. Eine genaue Beschreibung der möglichen Typen finden Sie weiter unten.
Class
Die Informationsklasse. Für Internet Informationen steht hier immer der Begriff IN.
Value
Der eigentliche Wert des Datensatzes. Abhängig vom genannten Typ.

Die Datenbank besteht also aus Einträgen, die sich alle an dieses Format halten. Für den Typ der Information (Type) stehen folgende Werte zur Verfügung:

Typ Bedeutung Eintrag
SOA Start Of Authority Verschiedene Parameter für die Zone, die der Nameserver verwalten soll.
A Address Die Adresse eines Internet Hosts.
MX Mail Exchange Die Priorität und Name des Mailservers der Domain.
NS Name Server Name eines Nameservers der Domain.
CNAME Canonical Name Domainname eines Rechners (Aliasfunktion)
PTR Pointer Alias für eine numerische IP-Adresse
HINFO Host Information ASCII Beschreibung des Hosts (CPU, OS, …)
TXT Text Nicht verwertbarer Text – Kommentar

Die einzelnen Einträge werden in Konfigurationsdateien geschrieben, die jeweils für eine sogenannte Zone gelten. Eine Zone entspricht entweder einem physikalischem Netz oder einer Domain selbst.

Für jede Zone existieren zwei solcher Konfigurationsdateien, eine für die Auflösung von Namen in Adressen und eine für die Auflösung von Adressen in Namen (reverse lookup).

Eine zentrale Konfigurationsdatei (natürlich im Verzeichnis /etc) sorgt für die Information, für welche Zonen der Nameserver verantwortlich ist und gibt die Positionen der Zoneninformationsdateien im Dateisystem an. Meist liegen diese Dateien unter /var/named.

Zuletzt existiert noch eine Datei root.hint, die nicht selbst editiert wird und die die Informationen über die root-Server im Internet enthält. Diese Information ist nötig, damit unser Nameserver in den weltweiten Verbund des DNS eingebunden ist.

Ein lokales Netz, das nicht permanent ans Internet angeschlossen ist und das vor allem nicht mit echten IP-Adressen arbeitet, muß natürlich keinen kompletten Nameserver unterhalten. In den meisten Fällen genügt es, einen sogenannten caching only nameserver bereitzustellen, der die Abfragen an andere Nameserver weiterleitet, aber selbst keine Informationen zur Verfügung stellt. Der Nameserver kann die Informationen über die bereits gefundenen Adressen zwischenspeichern (caching) und muß so nicht für jede Adresse erneut eine Anfrage starten.

Ein solcher Nameserver muß also keine Informationen über das lokale Netz beinhalten, sondern nur die Liste der root-server kennen. Diese Liste ist im Internet frei erhältlich und liegt bei der Installation eines Nameservers gewöhnlich bei. Meist heißt diese Datei root.hint (ab Version 8.0) oder named.ca, named.root (Version 4.x) und wird ins Verzeichnis /var/named installiert.

Es existieren heute zwei Generationen von Nameservern. Die erste benutzt den Berkley Internet Name Daemon bind Version 4, die zweite benutzt bind Version 8.0 (oder später). Dieser Generationsunterschied spielt eine große Rolle hinsichtlich der Syntax der Konfigurationsdateien. Moderne Installationen sollten heute alle mit Versionen ab 8.0 arbeiten. Die alten Versionen sind sehr unsicher!

Für den Prüfungsinhalt der LPI102 Prüfung ist noch das Wissen über beide dieser Versionen und vor allem über den Unterschied in den Konfigurationsdateien gefragt. Also werden wir beide Installationen durchspielen. Nochmal die Aufforderung: Es sollten nur noch Versionen ab 8.0 verwendet werden!

Konfiguration eines caching-only Nameservers unter bind Version 4.0
Die zentrale Konfigurationsdatei der älteren bind-Version liegt im Verzeichnis /etc und heißt named.boot. Diese Datei enthält die grundlegenden Informationen über folgende Einstellungen:

* In welchem Verzeichnis liegen die Informationsdateien des Nameservers.
* Welche Zonen werden von diesem Server verwaltet und in welchen Dateien liegen die entsprechenden Informationen.
* Ist dieser Nameserver der primäre Server einer Domain oder ein sekundärer.
* Welche Nameserver sollen gefragt werden, wenn dieser Nameserver nicht in der Lage ist, eine Adresse aufzulösen (forwarders).
* Soll der Nameserver selbst Anfragen starten, oder nur einen anderen Nameserver fragen.

Nachdem unser Nameserver nur als caching only Server betrieben werden soll, sind nur die wenigsten dieser Einstellungen für uns relevant. Eine einfache /etc/named.boot Datei könnte folgendermaßen aussehen:

;
; /etc/named.boot Datei fuer einen caching only Server
;
directory /var/named
;
; domain file
;—————————————————
cache . named.root
primary 0.0.127.in-addr.arpa named.local

Kommentare in dieser Datei werden durch einen Strichpunkt (;) eingeleitet. Die erste Anweisung, die kein Kommentar ist, gibt an, in welchem Verzeichnis alle Dateien gefunden werden, auf die wir uns im weiteren Verlauf der Datei beziehen. In unserem Fall ist das das Verzeichnis /var/named.

Die nächste (nicht-Kommentar) Zeile gibt die Datei an, die für den caching-only Server die wichtigste ist. Die Datei named.root wird – dank der letzten Anweisung – im Verzeichnis /var/named gesucht. Sie enthält die Informationen über die root-server im Internet und sollte nicht selbst verändert werden. Die Datei kann – falls sie nicht bei der Installation bereits vorhanden war – im Internet über anonymes FTP bezogen werden: Dateiname /domain/named.root auf dem Rechner FTP.RS.INTERNIC.NET.

Über diese Datei hat unser Nameserver jetzt Kontakt zum weltweiten DNS. Er kennt jetzt alle root-Server und kann somit jede Adresse im Internet auflösen. Er wird sich auch gerade aufgelöste Adressen merken, so daß nicht für jede Adresse erneut ein Lookup stattfinden muß.

Die letzte Zeile unserer Konfigurationsdatei verweist auf die Datei /var/named/named.local, die ausschließlich die Information zum localhost (127.0.0.1) also zu unserem eigenen Rechner enthält. Diese Datei entspricht vom Aufbau her der Form, die auch „echte“ Informationsdateien des Nameservers hätten, wenn sie verantwortlich für eine Domain wären:

;
; /var/named/named.local Reverse mapping of 127.0.0
;
@ IN SOA ns.mydomain.de. (
root.mydomain.de.
1 ; serial
360000 ; refresh: 100 Std
3600 ; retry: 1 Std
3600000 ; expire: 42 Tage
360000 ; minimum: 100 Std
)
IN NS ns.mydomain.de.
1 IN PTR localhost.

Diese Datei enthält 3 Datensätze. Der erste ist der sogenannte Start of Authority (SOA) Eintrag. Er definiert den Namen unseres Nameservers (ns.mydomain.de), die E-Mail Adresse des Verwalters, wobei statt dem @ Zeichen ein normaler Punkt verwendet wird (root.mydomain.de) und eine zusammengesetzte Seriennummer, die festlegt, wie lange Einträge des Nameservers gültig sein sollen.

Der zweite Eintrag definiert den Nameserver (NS) der verwendet werden soll – in unserem Fall ist das der Rechner ns.mydomain.de selbst.

Der dritte und letzte Eintrag ist die Angabe, daß die Adresse, die auf 1 endet (bei 127.0.0.1 immer der Localhost) eben der localhost ist.

Wenn diese Einträge jetzt existieren, kann der Nameserver gestartet werden. Normalerweise wird das über ein Init-Script (z.B. /etc/init.d/named start) erledigt. Bei den bind4 Nameservern existierten meist auch noch zwei Hilfsprogramme named.restart und named.reload, mit denen ein Nameserver neu gestartet werden kann, oder gezwungen werden kann, die Konfigurationsdateien neu einzulesen.

Konfiguration eines caching-only Nameservers unter bind Version 8.0
Der wesentliche Unterschied bei den Konfigurationsdateien der beiden Nameserver-Generationen liegt in der zentralen Konfigurationsdatei. Diese Datei enthält auch bei bind8 die selbe Information, wie bei bind4, jedoch heißt die Datei anders und hat einen völlig anderen Aufbau.

Die zentrale Konfigurationsdatei der modernen Nameserver heißt /etc/named.conf und ist ähnlich aufgebaut, wie ein C-Programm. Logische Blöcke werden in geschweifte Klammern zusammengefasst. Nach einer geschlossenen Klammer folgt – wie auch nach jeder Anweisung – ein Strichpunkt. Die Konfigurationsdate eines caching only Servers könnte folgendermaßen aussehen:

// Konfigurationsdatei für einen caching-only Nameserver
// /etc/named.conf

options {
directory „/var/named“;
};

zone „.“ {
type hint;
file „root.hints“;
};

zone „0.0.127.in-addr.arpa“ {
type master;
file „local.zone“;
};

Der erste Block (options) definiert globale Optionen. In unserem einfachen Beispiel findet sich hier nur die Information, in welchem Verzeichnis die Nameserver-Dateien zu finden sind, auf die sich der Rest der Einträge hier bezieht. Der Eintrag entspricht also genau der entsprechenden Angabe der alten Konfigurationsdatei.

Die einzelnen Zonen werden jetzt auch als Blöcke verwaltet, nicht mehr in einer Zeile, wie oben. Jede Zone hat mindestens einen Typ und eine Angabe einer Datei, die die Informationen über diese Zone beinhaltet. Wie oben haben wir wieder zwei Einträge, einmal für die Zone „.“ (die Wurzel des DNS-Baums) und einmal für unsere lokale Zone, das lokale Netz. Wie oben schon wird diese Angabe umgekehrt geschrieben, also statt 127.0.0 steht hier 0.0.127.in-addr.arpa.

Die einzelnen Dateien in /var/named unterscheiden sich nicht, außer in ihrem Namen. Und der wäre prinzipiell frei wählbar. Immerhin können wir zumindest bei der Zonendatei local.zone den SOA-Eintrag etwas verständlicher gestalten:

; Zonendatei für den localhost
@ IN SOA ns.mydomain.de. root.mydomain.de. (
1 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS ns.mydomain.de.
1 PTR localhost.

Die Angaben über die Zeiten können hier mit Prefixen versehen werden, die die Zeiteinheiten bezeichnen, statt sie immer in Sekunden angeben zu müssen. Die Prefixe H, D, W stehen für Stunde (hour), Tag (day) und Woche.

Auch hier wird der Nameserver über ein Init-Script gestartet, allerdings existieren die beiden Programme named.restart und named.reload nicht mehr. Stattdessen kann dem Nameserverprozeß ein HUP-Signal geschickt werden, das ihn zwingt, seine Konfigurationsdatei neu einzulesen.

Beide Nameserver-Versionen geben Diagnosemeldungen an den Syslog Daemon weiter. Ein Studium der Datei /var/log/messages sollte also im Fehlerfall immer der erste Schritt zur Problemlösung sein.