Nachdem sich der erste Teil der Artikelserie grundlegend mit dem Aufbau eines Nameservers beschäftigt hat, widmet sich dieser Beitrag detaillierter der Konfiguration. Unter Linux und vielen anderen Unix-Systemen kommt als Nameserver das Paket BIND (Berkeley Internet Name Domain) zum Einsatz, das wir im Folgenden genauer betrachten werden.
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. BIND ist vergleichsweise alt, gut gepflegt und sehr stabil. Besonders für größere Server wird es gerne eingesetzt.
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.
|
Teil 1 |
|
|
Teil 2 |
Nameserver im Detail |
|
Teil 3 |
Betrieb eines Nameservers |
Start Of Authority (SOA)
Ein SOA-Satz (Start Of Authority) markiert den Beginn einer Zone. Der Name (@, das Origin) steht für den Namen der Zone. Hier werden die grundsätzlichen Informationen für eine Zone festgelegt. Das Origin ist der Name des Rechners, der die Daten bereitstellt. Ein Beispiel für einen SOA-Satz finden Sie in dem Listing auf der folgenden Seite. Es gibt höchstens einen SOA-Satz für eine Zone, für die Zone existiert ein NS-Satz in der übergeordneten Zone.
Die verantwortliche Person ist der Betreiber des Nameservers, der bei Problemen und Fragen angesprochen werden sollte. Hier wird die E-Mail-Adresse dieser Person angegeben. Dabei wird das at-Zeichen (@) durch einen Punkt ersetzt. Oft wird hierfür ein Mail-Aliasname wie mailto:hostmaster oder mailto:dnsadmin verwendet.
Als weitere Information wird eine Seriennummer verwaltet, die bei jeder Änderung erhöht werden sollte. Sinnvoll ist die Verwendung des Datums und einer Versionsnummer, falls an einem Tag mehrere Änderungen vorgenommen werden. Am 26. Februar 1996 wäre dann eine mögliche Seriennummer 1996022601. Anhand dieser Seriennummer erkennt ein Secondary-Server, dass neue Daten vorliegen und er einen Zonentransfer durchführen muss. Wenn Sie die Seriennummer versehentlich zu hoch gesetzt haben, dann ist es nicht einfach, dies wieder zu ändern – denn die Secondary-Server würden sich ja nicht mehr synchronisieren.
Der SOA-Satz
Der für Refresh angegebene Wert bestimmt die Anzahl Sekunden, nach denen die Slave-Server die Daten erneut prüfen und eventuell transportieren sollen. Retry gibt an, wie lange auf einen Zonentransfer gewartet wird, bevor ein Fehlschlag angenommen wird. Expire bestimmt, wie lange Daten maximal als gültig anerkannt werden. Die Minimum-TTL gibt den Standardwert für die Time-To-Live (TTL) der einzelnen Sätze an.
Lange Time-outs und Expire-Zeiten sorgen für wenig Netzlast beim Update der Daten, aber für längere Wartezeiten, bis Änderungen auf die sekundären Server übertragen wurden. Oft setzt man die Zeiten herab, wenn sich eine größere Änderung ankündigt. Nachdem alle sekundären Nameserver die Daten übernommen haben, kann man zu den alten Werten zurückkehren.
name {ttl} addr-class SOA Origin Veranwortlicher (
@ 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
Beachten Sie, dass der named an alle Namen, die nicht mit einem Punkt (.) abgeschlossen sind, das Origin anhängt. Da dies so ist, ist ein vergessener oder überflüssiger Punkt einer der häufigsten Fehler bei der DNS-Konfiguration.
Nameserver (NS)
Für jeden Nameserver in der Zone muss hier ein Eintrag existieren. Mit diesem Eintrag wird eine neue Zone erzeugt und delegiert. Der erste Eintrag ist der Name der Zone, die bearbeitet wird, der letzte Eintrag ist der Name des verantwortlichen Nameservers. Jede Zone sollte mindestens zwei Nameserver (je einen primären und sekundären) besitzen, damit beim Ausfall eines Rechners der Name-Service weiter funktioniert. Diese Rechner sollten außerdem in verschiedenen Subnetzen bzw. im Internet bei verschiedenen Providern angebunden sein. Damit ist auch ein Router- oder Leitungsausfall zu überstehen.
Für jede Zone gibt es zwei, hoffentlich zueinander passende Definitionen für Nameserver: in der übergeordneten Zone, in der die neu definierte Zone delegiert wird, und in der Zone selbst. Nur diese beiden Einträge gemeinsam machen eine vollständig und korrekt delegierte Zone aus.
Eine beliebte Fehlerkonstellation ist, dass ein Nameserver betrieben wird, der nicht autorisiert ist (für den also im übergeordneten Nameserver (Parent-Name-Server) kein NS-Record existiert), oder ein Rechner als (sekundärer) Nameserver eingetragen ist, obwohl dort kein named läuft. Wenn ein System im NS-Record eingetragen, aber selbst nicht zuständig ist (also keinen primary- oder secondary-Eintrag in der named.boot hat), so spricht man von einer „Lame Delegation“.
name {ttl} addr-class NS Name servers name
IN NS janus.jochen.org.
In den Quellen von BIND sind verschiedene Skripten enthalten, die die Zonen nach Fehlern und Inkonsistenzen durchsuchen. Leider sind diese Skripten nur selten bei Linux-Distributionen installiert. Bei kommerziellen Systemen sind sie in der Regel auch nicht vorhanden. Sie sollten in jedem Fall den Quellcode von BIND installieren, die mitgelieferte Dokumentation lesen und sich die Skripten ansehen. Außerdem gibt es externe Pakete wie dnslint, die ebenfalls erweiterte Prüfungen durchführen.
Address (A)
Ein A-Satz enthält für jeden Rechner die zugehörige IP-Adresse. Für Rechner mit mehreren IP-Adressen (multihomed Hosts), ist je IP-Adresse ein Satz erforderlich. Weitere Informationen, die in den im Folgenden erläuterten Satzarten gespeichert werden, sind für den Betrieb eines Nameservers nicht erforderlich und werden oft auch nicht gepflegt. Die einzige Ausnahme sind die PTR-Sätze, die für den „Reverse-Lookup“ erforderlich sind.
Für jede IP-Adresse, die in der Zone belegt ist, sollte genau ein A-Record existieren. Für Rechner, die mehrere IP-Adressen haben, sind also mehrere A-Records aufzunehmen. Dabei kann, wie im folgenden Listing gezeigt, derselbe Name verwendet werden. Es ist in manchen Fällen sinnvoll, einen zusätzlichen Namen einzurichten, der z. B. das betreffende Interface beschreibt.
Die Namen in der ersten Spalte werden hier ohne Domain angegeben. Da der Name auch nicht durch einen Punkt abgeschlossen wurde, wird vom Nameserver automatisch die Zone angehängt. Daher ist der Rechner unter seinem vollen Namen (FQDN) im Nameserver eingetragen. Der Client, d. h. die Resolver-Bibliothek, durchsucht den Nameserver nach einem Namen zunächst mit der angehängten Domain, so dass Benutzer im lokalen Netz diese in der Regel nicht angeben müssen.
{name} {ttl} addr-class A adress
jupiter IN A 192.168.30.202
typhon IN A 192.168.31.151
IN A 10.0.0.78
Für IPv6-Adressen verwenden Sie den Adresstyp A6. In älteren Versionen der IPv6-RFCs wurde der Adresstyp AAAA verwendet, diesen sollten Sie bei neuen Adressen jedoch nicht mehr einsetzen.
Well Known Services (SRV)
Im DNS ist es möglich, weitere Informationen zu Services, die ein Rechner anbietet, zu speichern. In der Regel werden diese Daten nicht gepflegt, so dass man sich auf diese Angaben nicht verlassen kann. Am besten probiert man den entsprechenden Service einfach aus. Wenn die Verbindung hergestellt werden kann, dann bietet der Rechner den entsprechenden Dienst an, andernfalls nicht. In früheren Versionen wurde statt SRV der Resource-Typ WKS verwendet.
Canonical Name (CNAME)
Ein Rechnername sollte nicht aufgrund der Funktion des Rechners vergeben werden. Dennoch ist es oft sinnvoll, einen Rechner auch unter einem passenden Namen erreichen zu können. Dies findet man z. B. bei ftp-Servern, die auch unter dem Alias-Namen ftp erreichbar sind. Weitere Dienste, für die häufig Aliasnamen (oder Nicknames) vergeben werden, sind www, pop3, smtp oder irc.
Übernimmt ein anderer Rechner diese Funktion, so muss nicht der Name des Rechners, sondern nur der entsprechende Nickname verändert werden. Damit bleibt den Benutzern verborgen, welcher Rechner tatsächlich den Dienst übernommen hat. Wird kein CNAME verwendet, sondern muss der Rechner umbenannt werden, so bedeutet das oft einiges an Konfigurationsaufwand und es ist relativ fehleranfällig.
aliases {ttl} addr-class CNAME Canonical name
jupiter IN CNAME ftp
Wird ein Rechner umbenannt, so ist es oft sinnvoll, den alten Namen eine Zeit lang als Nickname zusätzlich zu erlauben. Es sollte jedoch nie ein MX-Record (Mail Exchange) auf einen CNAME weisen, da ein Mail Transfer Agent dort nicht nachfragen muss (named gibt eine entsprechende Warnung aus). In aktuellen BIND-Versionen kann außerdem zu einem CNAME keine weitere Information, insbesondere kein MX-Record, eingetragen werden.
Domain Name Pointer (PTR)
Ein PTR-Satz (Domain Name Pointer) erlaubt es z. B. anhand einer IP-Adresse, auf den Host-Name zu schließen. Diese Funktion wird in der in-addr.arpa-Domain benutzt, also z. B. in der named.rev-Datei. Damit ist es möglich, auch wenn zunächst nur die IP-Adresse eines Rechners oder Gateways bekannt ist, einen Namen anzuzeigen. Diese Funktion wird z. B. von den Programmen netstat oder traceroute verwendet. Mehr zum Reverse-Lookup finden Sie Abschnitt Die Datei named.rev.
Die PTR-Sätze werden für die Funktion gethostbyaddr(3), die für die Umwandlung der IP-Adressen in Namen zuständig ist, benötigt. Jeder Name im PTR-Satz wird mit einem Punkt abgeschlossen, damit BIND nicht die Domain in-addr.arpa anhängt. Sie sollten alle Netzwerkteilnehmer, die eine IP-Adresse haben, in den Nameserver aufnehmen, damit Sie nicht auf einen Nameserver-Time-Out warten müssen, nur weil kein Nameserver-Eintrag für den Reverse-Lookup verfügbar ist.
name {ttl} addr-class PTR real name
155.31 IN PTR jupiter.jochen.org
151.31 IN PTR typhon.jochen.org
Bei IPv6 wird als Domain für den Reverse-Lookup ip6.arpa verwendet. Die IPv6-Adressen sind dabei im bekannten Format anzugeben. In älteren Applikationen kommt eventuell noch das „Nibble“-Format zum Einsatz, dann müssen Sie die Domain ip6.inet verwenden.
Mail Exchange (MX)
Im Internet wird Mail mit Hilfe des Simple Mail Transfer Protocol (SMTP) übertragen. Dabei wird zwischen dem sendenden und empfangenden Rechner eine TCP/IP-Verbindung aufgebaut.
Ist ein Rechner zum Zeitpunkt des Versendens der Mail nicht erreichbar (oder der Rechner nicht an das Internet, sondern mit UUCP angeschlossen), so kann hier ein anderer, verfügbarer Rechner eingetragen werden, der die Mail annimmt. Ist der Rechner dann wieder erreichbar, so wird die Mail weitergereicht. Niedrigere Werte für die Präferenz entsprechen geringeren „Kosten“.
Diese Funktion wird oft eingesetzt, damit nur auf einem oder zwei Rechnern im Netz Mail angenommen werden muss. Damit konzentriert man die Konfigurationsarbeit und die Verfügbarkeitsprobleme auf wenige Rechner. Sie sollten sich mit dem Administrator des Rechners abstimmen, wenn Sie einen MX-Satz auf einen fremden Rechner zeigen lassen. Andernfalls wird dieser mit unerwarteter Mail bombardiert und diese geht möglicherweise verloren.
name {ttl} addr-class MX preference mail exchange
jupiter.jochen.org IN MX 0 hermes
Ein weiterer Vorteil eines Mail-Exchangers ist, dass die Mail nicht auf Hunderten oder Tausenden von Rechnern weltweit gesammelt wird und möglicherweise unmittelbar nach dem Neustart des Mail-Servers diesen wieder zum Absturz bringt. Wird aufgelaufene Mail zentral gesammelt, dann liefert nur dieser Rechner massenweise Mail aus und im Problemfall kann man mit dem Administrator dieses Rechners einen langsameren Feed vereinbaren.
Prinzipiell ist es möglich, für alle Rechner einer Domain einen zentralen Mail-Hub vorzusehen. Dazu kann man den Eintrag * als MX verwenden. Beachten Sie, dass das nicht unbedingt den Effekt hat, den Sie erwarten: Der MX gilt für alle möglichen Namen, nicht nur für diejenigen, die in der named.data-Datei eingetragen sind. In den meisten Fällen ist es besser, den betreffenden Einträgen explizit einen MX-Eintrag zuzuordnen.
Mail-Exchanger dürfen nicht auf einen CNAME verweisen. named gibt hier eine entsprechende Warnung aus. Wenn Sie einen zusätzlichen Namen auf Ihrem Mail-Hub annehmen wollen, so müssen Sie bei sendmail mit Hilfe des Cw-Eintrags dafür sorgen, dass dieser Name als lokal erkannt wird. Andernfalls gibt sendmail die Fehlermeldung “local configuration error: mail loops back to myself” aus.
Text (TXT)
Als zusätzliche Information kann zu jedem Rechner ein beliebiger Text abgelegt werden. Außer, dass dieser Text in Anführungszeichen (") eingeschlossen werden muss, bestehen keine weiteren Einschränkungen. Dieser Typ ist nur selten gepflegt, Netzwerkverwalter bevorzugen es in der Regel, diese Informationen mit Hilfe von SNMP direkt vom betreffenden System auszulesen.
name {ttl} addr-class TXT string
jupiter.jochen.org IN TXT “Ein Text”
Responsible Person (RP)
Neben dem Verantwortlichen für den Nameserver kann zu jedem weiteren Eintrag ein Ansprechpartner für diesen Rechner hinterlegt werden. Hier wird wieder das at-Zeichen (@) in der Mail-Adresse durch einen Punkt ersetzt.
Verwalten Sie Ihre Rechner jedoch mit SNMP (Simple Network Management Protocol), so tragen Sie diese Information besser in die Management Information Base (MIB) ein.
owner {ttl} addr-class RP mbox-domain-name TXT-domain-name
jupiter IN RP jochen.jochen.org sysadmins.jochen.org
sysadmins.jochen.org IN TXT „Tel: 4711“
Die Datei named.local
Die Datei named.local (siehe folgendes Listing), die sich im Verzeichnis /var/named befindet, enthält die zum eigenen Rechner bzw. zum jeweiligen localhost gehörenden Daten. Die Datei besteht nur aus wenigen Einträgen, die wichtig sind, wenn Benutzer in ihren ~/.rhosts-Dateien auch den Eintrag localhost benutzen wollen und/oder der Rechner localhost nicht in der Datei /etc/hosts enthalten ist.
@ IN SOA janus.jochen.org. hostmaster.jochen.org. (
19860121101 ; Serial
3600 ; Refresh
300 ; Retry
3600000; Expire
14400) ; Minimum
IN NS janus.jochen.org
0 IN PTR loopback.
1 IN PTR localost.
Die Datei named.rev
Für den normalen DNS-Lookup wird die DNS-Domain verwendet. Mit deren Hilfe wird der zuständige Nameserver ermittelt und dann befragt. Für den Reverse-Lookup wurde eine spezielle Zone generiert, die in-addr.arpa. In diesem vom DNS verwalteten Baum sind die IP-Adressen nach den zugehörigen Subnetzen strukturiert. Bei der Delegation der Zonen werden die Bytes der Netzadresse in umgekehrter Reihenfolge verwendet.
In Listing 22.1 sind zwei Zonen eingetragen. Die Zone 0.0.127.in-addr.arpa wird in der Datei named.local verwaltet und repräsentiert das localnet, die Rechner mit den Adressen 127.0.0.x. Die Zone 168.192.in-addr.arpa steht für die IP-Adressen aus dem reservierten Bereich 192.168.x.y.
In der Datei named.rev wird zu einer IP-Adresse der zugehörige Rechnername vermerkt. Damit ist es relativ schnell und einfach möglich, einen Namen zu einer IP-Adresse zu finden. Diese Funktion nennt man auch Reverse-Lookup. Die Datei named.rev liegt im Masterfile-Format vor. Ein Beispiel finden Sie in folgendem Listing. In der ersten Spalte sind die Teile aus der IP-Adresse angegeben, die in der Zonendefinition nicht enthalten sind. Auch hier wird wieder die umgekehrte Reihenfolge verwendet.
Beachten Sie, dass Sie jeden Host-Namen mit einem Punkt abschließen müssen. Andernfalls würde stets die Domain in-addr.arpa angehängt. Achten Sie außerdem auf die Konsistenz der Dateien named.data und named.rev. Dabei kann Ihnen ein Tool wie dnslint helfen.
@ IN SOA janus.jochen.org. hostmaster.jochen.org. (
19860121101 ; Serial
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000; Expire 1000 hours
86400 ) ; Minimum 24 hours
IN NS janus.jochen.org
0.0 IN PTR jochen.org
IN A 255.255.255.0
151.31 IN PTR typhon.jochen.org
155.31 IN PTR jupiter.jochen.org
Bei IPv6 wird für den Reverse Lookup die Domain ip6.arpa verwendet, als Resource-Record wird weiterhin der Typ PTR verwendet. Noch ist IPv6 nicht weit verbreitet, aber das wird sich ändern.
Secondary Nameserver
Um die Ausfallsicherheit zu erhöhen, sollten in jeder Zone mindestens zwei Nameserver betrieben werden. Beim Ausfall eines Rechners kann der zweite Nameserver immer noch alle Anfragen beantworten. Damit die Daten stets konsistent sind, darf für jede Zone nur ein (autorisierter) Master-Server existieren.
Daneben können ein oder mehrere sekundäre Nameserver konfiguriert werden. Ein Secondary Nameserver holt seine Daten vom primären Server. Ist dieser nicht verfügbar, so werden die in Sicherheitskopien (*.bak) gespeicherten Daten verwendet. Ist die Time-to-Live der Daten abgelaufen, so wird versucht, diese Daten erneut vom Nameserver zu erhalten. In folgendem Listing finden Sie ein Beispiel für die Datei /etc/named.boot eines sekundären Nameservers.
# conf file excerpt for a secondary name server zone "jochen.org" {
type slave;
masters { 192.168.30.254; };
file "named.bak";
};
zone "168.192.in-addr.arpa" {
type slave;
masters { 192.168.30.254; };
file "named.rev.bak";
};
Anhand der in den SOA-Sätzen der Nameserver-Daten eingetragenen Seriennummern kann ein sekundärer Nameserver feststellen, ob er noch die aktuellen Daten einer Zone besitzt. Andernfalls kann eine Neuübertragung veranlasst werden. Wenn Sie in den primären Daten eine kleinere Seriennummer vergeben, wird der sekundäre Nameserver entsprechende Meldungen ausgeben. Sie sollten daher die System-Log-Einträge aller Nameserver im Auge behalten, um derartige Fehler möglichst auszuschließen. Ansonsten sind Secondary-Server vollkommen wartungsfrei.
Slave-Nameserver
Ein Slave-Server verwaltet keine zonenbezogenen Daten, sondern nur einen Cache und leitet Anfragen, die nicht aus dem Cache beantwortet werden können, an festgelegte Nameserver (forwarders) weiter. Damit kann dieser Rechner einen guten Cache aufbauen, von dem alle Nutzer profitieren können.
Prinzipiell kann jeder Nameserver für die Verwendung von forward konfiguriert werden. Dies ist zum Beispiel sinnvoll, wenn der Nameserver nicht direkt an das Internet angeschlossen ist. Wird als Forwarder der Router oder eine Firewall eingetragen, so kann dieser bzw. diese die Anfragen weiterleiten. Ein weiterer Vorteil ist die Ausbildung eines großen Cache, so dass insgesamt weniger Anfragen durch andere Nameserver beantwortet werden müssen.
Forwarder befragen die eingetragenen Server zusätzlich, z. B. zu den bekannten Root-Nameservern. Bei einem Slave-Server werden nur die Forwarder befragt. Können diese keine Antwort liefern, so kann der Host-Name nicht aufgelöst werden. Da diese Rechner die Daten möglicherweise selbst beschaffen müssen, sollten Sie die Adressen mehrfach in der Datei /etc/named.boot aufführen. Ein Beispiel dafür finden Sie in folgendem Listing.
# boot file for slave name server
options {
directory "/etc/named";
forward only;
# Alle unbekannten Anfragen an den DNS der uranus weitergeben
forwarders {
194.45.71.65;
194.45.71.65;
194.45.71.65;
};
};
zone "." {
type hint;
file "named.root";
};
Mit der Option forward-only wird dafür gesorgt, dass nur die angegebenen Forwarder befragt werden. Wenn Sie eine Firewall haben, so kann es sein, dass Sie diese als Forwarder eintragen müssen, wenn die Nameserver keinen Zugang zum Internet haben. Als Vorteil kommt hinzu, dass wiederum die Forwarder einen guten Cache ausbilden k!nnen. In alten Versionen von named wurde slave anstelle der Option forward only verwendet.
Sie sollten an erster Stelle den schnellsten (und stabilsten) Nameserver eintragen. Da es möglich (und sogar wahrscheinlich) ist, dass dieser Rechner die Daten zunächst selbst beschaffen muss, sollten Sie den Eintrag für diesen Rechner zwischen die weiteren Forwarder ein- oder zweimal erneut einstreuen.
Ausblick
Der dritte und letzte Teil der beschäftigt sich eingehend mit den Optionen der Datei named.boot. Darüber hinaus widmet sich der nächste Teil der Serie der Steuerung des named-Prozesses und dem Betrieb eines Nameservers.
Dazu gehören beispielsweise das dynamische DNS-Update. Ebenso ist das Thema Sicherheit und DNS ein entscheidender Faktor beim Betrieb eines Nameservers. (mje)