1.12.5. Nameserver

Ein Nameserver (NS) beantwortet Anfragen von Resolvern und anderen NS nach Daten im DNS-Namensraum. Diese Anfragen erwartet er via UDP oder TCP auf dem vordefinierten Port 53.

Ein NS besitzt im allgemeinen vollständige Informationen für einen Teilbereich des DNS-Namensraumes, nämlich für eine Zone. Für diese Zone ist der NS autoritativ, d.h., er kann verbindliche Antworten geben - entweder die Daten oder eine negative Antwort. Dabei kann ein NS auch für mehrere Zonen autoritativ sein. Für eine Zone muß ein NS immer zuständig sein, und zwar für die umgekehrte Abbildung der lokalen Loopback-Adresse 127.x.x.x, wobei sehr häufig lediglich 127.0.0.1 genutzt und meist mit localhost bezeichnet wird, weswegen wir nachfolgend meist nur diese eine Adresse verwenden.

Dabei unterscheidet man zwischen Primary und Secondary NS. Ein Primary NS liest die Daten seiner Zone aus einer Datenbasis, bestehend aus Dateien in einem speziellen Format. Ein Secondary NS bezieht sein Wissen über die Zone vom Primary NS durch den sog. Zonentransfer über das Netz. Dabei werden die Zonendaten in regelmäßigen Intervallen vollständig über eine TCP-Verbindung vom Primary Server abgerufen. Durch die Verwendung von TCP statt UDP unterliegen die Nachrichten keiner Längenbeschränkung. Außerdem bietet TCP eine zuverlässige Kommunikation, d.h., evtl. auftretende Übertragungsfehler werden automatisch auf der Ebene der Transportschicht korrigiert (Details dazu erfahren Sie im Kapitel 2).

Pro Zone gibt es also genau einen Primary NS. Secondary NS richtet man ein, um die Last zu verteilen und um die Redundanz zu erhöhen. Der Ausfall eines Nameservers (Systemabsturz, Netzunterbrechung) wird damit weniger kritisch.

Es gibt Nameserver, die für keine (richtige) Zone zuständig sind, sondern nur über die Caching-Funktion verfügen. Solche Server heißen Caching-only Server. Sie sind sinnvoll für ein Subnetz mit langsamer Netzanbindung oder für einen Rechner, der besonders "nameserverintensive" Anwendungen hat (z.B. WWW-Server, der Reverse Lookups für sein Logging durchführt).

Daneben gibt es noch den Begriff des Slave Servers. Ein solcher richtet seine Anfragen immer an einen vordefinierten Nameserver (den sog. forwarder, wobei zur Ausfallsicherheit mehrere angebbar sind) und niemals an den eigentlich zuständigen NS in der weiten Welt. Damit kann man eine Hierarchie von Caches aufbauen, womit sich Netzverkehr minimieren läßt. Diese Konstruktion ist auch bei Firewall-Installationen notwendig.

Planung einer eigenen DNS-Domain

Wir werden sehen, daß der Betrieb eigener NS nicht ganz trivial ist. Wenn man jedoch ein heterogenes TCP/IP-Netz mit mehr als einer Handvoll Rechner betreibt und Internet-Zugang hat oder plant, kommt man nicht umhin, eine eigene DNS-Domain zu verwalten. Einige Hinweise zur Planung und Erfahrungen im Betrieb sind im folgenden zusammengefaßt.

Einteilung des Namensraumes:

Betrieb der Nameserver: Wenn man nur wenige DNS-Daten hat, die dazu noch sehr stabil sind (z.B. ein einziger WWW-Server in der Domain), kann man den NS-Betrieb natürlich auch ganz dem Provider überlassen. Man sollte die DNS-Verwaltung allerdings selbst übernehmen, sobald das Netz größer wird, sich die Änderungen häufen oder der Provider zu langsam bzw. mit höherer Rechnung auf Änderungswünsche reagiert .

Wenn man keine ständige Verbindung zum Internet hat (Wählverbindungen), ist folgende Variante denkbar: Als offizieller, im DNS verzeichneter autoritativer NS fungiert der NS des Providers. Der hat seinen NS jedoch als Secondary für unsere Domain konfiguriert und gleicht die Zonendaten regelmäßig mit unserem selbstverwalteten NS ab (evtl. zeitgesteuert, wenn die Verbindung garantiert steht). Unser NS fungiert dann als "stiller" Primary NS. Die Resolver der lokalen Domain benutzen diesen natürlich, während alle externen Anfragen an den NS des Providers gehen.


Diskussion 1.12.5.1:
Warum muß ein NS immer für das Reverse Mapping von 127.0.0.1 zuständig sein?

Diskussion 1.12.5.2:
Welche Probleme kann es mit Rechnern geben, die mehr als ein Netz-Interface haben? Wie kann ich einen Namen für genau ein Interface definieren?
© Frank Richter, Holger Trapp, 15.4.1998