Beschreibung: 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:
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.
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:
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:
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!
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.localKommentare 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.
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.