Konfiguration und Betrieb von DNS-Servern

Gelbe Seiten

Stephan Lichtenauer 


Dokumentation zum Betrieb und den vielen Konfigurationsdateien von BIND, dem Quasi-Standard-Nameserver unter Unix und Linux ist leider sehr spärlich gesät; die mitgelieferten Manpages sind bestenfalls als Referenz verwendbar. Dennoch sind sauber gewartete Namensdienste unbedingte Grundlage für zufriedene Nutzer all der Internetdienste wie EMail, WWW, FTP etc. einer Organisation, wollen wir also etwas Licht in die Sache bringen... 


Namensvergabe und -auflösung im Internet und anderen IP basierten Netzwerken hat eine lange Geschichte. Da die 32-Bit Adressen, über die die Netzknoten eigentlich adressiert werden, kaum zu merken sind, hat man relativ bald angefangen, den Computern Namen zu geben. Anfänglich hat man sich damit beholfen, eine Datei HOSTS.TXT anzulegen, die jeder IP-Adresse im Netzwerk einen Namen zugeordnet hat.

Listing 1: HOSTS.TXT-Beispieldatei
192.168.1.1     poseidon.qdrei.de    mysql      
192.168.1.2     venus.qdrei.de       ftp mail www       
192.168.1.3     client1.qdrei.de                
192.168.1.4     client2.qdrei.de                

Diese Datei, die auch heute noch benutzt wird (betrachten Sie doch einfach /etc/hosts), enthält eine IP-Adresse, einen zugeordneten Hostnamen sowie optional alternative Aliasnamen, über die dieser Rechner ebenfalls erreichbar ist. War diese Lösung in den Frühzeiten des ARPANET mit einigen Dutzend Computern oder heute in überschaubaren Intranets noch administrierbar, so ist klar, daß das in der modernen hierarchischen Struktur des Internet (des Nachfolgers des ARPANET) nicht mehr so ist. Man hat also ziemlich bald nach einer Lösung gesucht, die einerseits die Vorteile dieser Hierarchie nutzt und andererseits die Unmöglichkeit beseitigt, auf jedem Rechner getrennte aber trotzdem konsistente HOSTS.TXT Dateien zu warten. Das Ergebnis kam bald in der Form mehrerer Requests For Comments (RFCs), darunter RFC 1035 (Domain Names - Implementation and Specification) sowie 1034 (Domain Names - Concepts and Facilities).

Das Domain Name System des Internets

Um die Millionen von Rechnern des Internet organisieren zu können, hat man eine hierarchische Namensstruktur eingeführt. Die Wurzel dieser Namen ist ein ".", danach kommt eine der von IANA (Internet Assigned Numbers Authority) festgelegten globalen Toplevel-Domains, z. B. com, edu, org, de, is. Für jeden dieser Namensräume wiederum vergeben verschiedene Organisationen untergeordnete Domains, so ist beispielsweise DENIC zuständig für alle Namen im de-Bereich. Hat man nun einen Namen registrieren lassen, so kann man selbst eine Hierarchie mit beliebig vielen weiteren Subdomains, also untergeordneten Namen, einrichten. Der ".", der die Wurzel spezifiziert, wird im Alltagsgebrauch weggelassen, und so lokalisiert beispielsweise penguin.produktion.bmw.de einen Rechner namens penguin, der zu der Subdomain produktion gehört, die wiederum bmw und der Topleveldomain de untergeordnet sind.

Abb. 1: Die Position von penguin.produktion.bmw.de in der Namenshierarchie des Internet

Wenn auf einem Rechner das TCP/IP-Subsystem installiert ist (und das ist wohl bei allen Unix/Linux-Rechnern der Fall), so muß mindestens ein Nameserver spezifiziert werden, der die Auflösung von Hostnamen in IP-Adressen vornimmt. Dies kann mittlerweile dynamisch geschehen, falls Dial-Up Verbindungen via PPP genutzt werden, auf alle Fälle genügt hier aber natürlich nicht die Angabe eines Hostnamens, hier muß die IP-Adresse vorgegeben werden (da ja erst dieser Server Namen in IP-Adressen umsetzen kann). Falls nun eine Anwendung einen Hostnamen auflösen, d. h. die zugehörige Adresse ermitteln will, so wird zunächst die Datei /etc/hosts durchsucht und danach, falls dort kein Computer gefunden wurde, der Nameserver kontaktiert. Dieser bearbeitet die Anfrage entweder selbst, falls in seiner Datenbank die Daten für den gefragten Namensbereich vorhanden sind, oder reicht sie weiter an den nächsten in der Hierarchie über ihm stehenden Dienst. Angenommen der für bmw.de zuständige Server bekommt eine Anfrage für nathan.audi.de, so wird er die Anfrage an den Server für die ganze Topleveldomain de weiterreichen, venus.produktion.bmw.de könnte er dagegen selbst auflösen. Der de-Server kennt die Adresse des audi.de Nameservers und liefert diese an den Anfrager, der nun seine Frage an sie wiederholt.

Das IP-Nameserverpaket BIND8

Der Server für das neue Domain Name System, der bis heute praktisch den Standard setzt, wurde vom Internet Software Consortium (ISC) in Form von BIND (Berkeley Internet Demon) implementiert. Auch wenn Berkeley eigentlich BSD als Betriebssystem impliziert, so ist es doch mittlerweile auf praktisch alle wichtigen Plattformen portiert und in nahezu allen Unix oder Linux Systemen bzw Distributionen inbegriffen. Mit dem Wechsel von BIND4 nach BIND8, der aktuellen Version, war auch eine tiefgreifende Änderung (und gewisse Vereinfachung) der Konfiguration verbunden.

Im BIND-Slang wird eine Domain als Zone bezeichnet. Der für die Zone verantwortliche Server hat die Datenbank mit den master-Informationen, vorhandene sekundäre Server, die bei Ausfall oder Überlastung des Primary Master-Servers einspringen, haben eine Kopie dieser Daten (die Slave-Zone), und werden bei Konfigurationsänderung der Zone automatisch vom Master mit den neuen Domaininformationen versorgt.

Der Server besteht aus einem Dämonprozeß named, der gewöhnlich bei Konfiguration im System V-Stil von einem Bootskript (meist /sbin/init.d/named) gestartet oder gestoppt wird. Falls die Konfiguration geändert wird, so muß der Prozeß mit einem kill -HUP Befehl zum Neueinlesen der Dateien überredet werden. Eventuelle Fehlermeldungen und der folgende Ablauf der Kommunikation mit den anderen Nameservern, die über die Änderungen informiert werden müssen, wird im Systemlog festgehalten. Damit man diese Nachrichten nicht übersieht, empfiehlt es sich, diese Datei in einem Terminal immer mit dem Befehl tail -f /var/log/messages im Auge zu behalten.

Konfiguration von named - named.conf

BIND8 hat eine zentrale Konfigurationsdatei /etc/named.conf, die neben allgemeinen Parametern die verwalteten Zonen sowie die zugehörigen Zonenkonfigurationsdateien festlegt.

Listing 2: Beispiel einer /etc/named.conf-Datei
/* Beispielkonfiguration für BIND 8.1 oder neuer
 * Als /etc/named.conf installieren
 *
 * Autor: Stephan Lichtenauer
 * Anmerkung: Alle IP-Adressen/Hostnamen sind erfunden
 */

#
# Allgemeine Serverparameter
#
options {
        # Verzeichnis in dem die Zonendatenbanken gespeichert sind
        directory "/var/named";
        # per default wird der Server bei Fehlern in den 
        # Masterzonendateien gestoppt
        check-names master warn;

        pid-file "/var/named/slave/named.pid";

        datasize default;
        stacksize default;
        coresize default;
        files unlimited;
        recursion yes;
        multiple-cnames no;

        # per Default wird an Port 53 auf allen verfügbaren 
        # Interfaces gelauscht, folgende Befehle könnten 
        # das genauer spezifizieren:
        #listen-on { 5.6.7.8; };
        #listen-on port 1234 { !1.2.3.4; 1.2/16; };
        query-source port 53;
};

#
# Logging-Optionen für verschiedene Probleme:
#
logging {
        category lame-servers { null; };
        category cname { null; };
};

#
# Vordefinierte "Access Control Lists" (ACL):
# "any"         Läßt alle Hosts zu
# "none"                Verbietet alle Hosts
# "localhost"   Erlaubt Verbindungen von diesem Rechner
# "localnets"   Erlaubt Verbindungen aus den LANs (192.168.0.0/16)
#
# Eigene ACL festlegen:
acl secondaries { 193.158.2.17; 152.133.12.18; };


#
# Mit der "server"-Anweisung können anderen Servern bestimmte Eigenschaften
# zugeordnet werden.
#
# Ein als "bogus" ("Lügner") markierter Server wird nie befragt
server 193.158.24.28 { bogus yes; }
# Falls der andere Server auch mindestens BIND 8.1 installiert hat,
# kann man Zonen kompakter übertragen lassen.
server 193.158.24.29 { transfer-format many-answers; }

#
# Festlegen der root-Zone
#
zone "." IN {
        type hint;
        file "root.hint";
};

#
# Festlegen der Zone "localhost"
#
zone "localhost" IN {
        type master;
        file "localhost.zone";
        check-names fail;       // Fehler hier wären fatal
        allow-update { none; }; // nur von lokalem Interesse
};

#
# Festlegen der Rückwärtsauflösung für localhost (Adressen in Namen)
#
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "0.0.127.zone";
        check-names fail;
        allow-update { none; };
};

#
# Festlegen der Rückwärtsauflösung für einen Adressraum
#
zone "36.158.193.in-addr.arpa" IN {
        type master;
        file "36.158.193.zone";
        check-names fail;
        allow-update { none; };
        allow-query { any; };
        allow-transfer { secondaries; };
        notify yes;
};

#
# Eine Masterzone
#
zone "bmw.de" IN {
        type master;
        file "bmw.de.zone";
        # Einschränken der Zonentransfers, um Spionen die Arbeit zu
        # erschweren
        allow-transfer { secondaries; };
        allow-update { none; };
        allow-query { any; };
        notify yes;
};

#
# Eine Slave-Zone
#
zone "audi.de" IN {
        type slave;
        file "slave/db.audi.de";
        masters { 194.238.99.128; };
};

Slavezonen

Das Betreiben eines sekundären Nameservers, also das Verwalten einer Slave-Zone, ist mit wenig Aufwand verbunden. Außer der kurzen Zonendefinition in /etc/named.conf, die den Master-Server und einen Dateinamen festlegt, in dem BIND die Informationen speichern soll, braucht nichts weiter angegeben werden. Alle nötigen Datenbankupdates holt sich named automatisch, vorausgesetzt der zugehörige Primary Server wird korrekt konfiguriert.

Zonendateien

Für die Domänen, für die Ihr Nameserver als Primary Server konfiguriert ist, ist dagegen mehr Sorgfalt erforderlich. Speziell die verteilte, hierarchische Architektur des Internet-Domänenkonzepts läßt öffentliche Trial-and-Error Methoden zur Konfiguration nicht zu. Sie müssen bedenken, daß Sie auf die meisten Server gar keinen Zugriff haben, die von Ihnen festgelegte Zoneninformationen besitzen, entweder als sekundäre Server (beispielsweise bei Ihrem ISP), oder einfach nur weil sie nach einer Anfrage Ihre Daten in ihrem Cache zwischenspeichern. Die Dauer der Existenz solcher ungültiger Angaben bestimmen Sie über die von Ihnen festgelegte Lebensdauer der Records zu einem großen Teil selbst (wie erfahren Sie etwas weiter unten).

Gewöhnlich werden Sie die root-Zone und mindestens zwei Masterzonen definieren. Für jede der Masterzonen gibt es zwei Datenbankdateien; eine für die Auflösung von Namen in Adressen sowie eine für die umgekehrte Prozedur von Adressen in zugehörige Namen (Reversal Lookup). Daneben existiert eine Datei mit den Adressen der Root-Nameserver, die als letzte Instanz kontaktiert werden und die die Informationen über die Toplevel-Domains verwalten. Diese Datei sollte regelmäßig auf ihre Aktualität überprüft werden, sie kann von ftp://rs.internic.net/domain/named.root bezogen werden. Kopieren Sie diese Datei in das Verzeichnis mit Ihren Zonendateien (gewöhnlich - und wie in der Beispielkonfigurationsdatei angegeben - ist dies /var/named) und geben Sie ihr den Namen, den Sie auch in named.conf spezifiziert haben (hier root.hint).

Als Ausgangspunkt für eigene Zonendateien kann unter Umständen bei großen /etc/hosts-Dateien das Tool h2n benutzt werden, das /etc/hosts Dateien in BIND Zonendatenbanken umwandelt. Dieses Programm können Sie, entsprechend konfiguriert, auch regelmäßig ausführen, falls Ihre /etc/hosts-Datei immer die aktuellen Daten enthält. Gewöhnlich verwaltet man aber eher die Zonendatenbanken von Hand.

Masterzonen

Legen wir zunächst einmal die Datei für die Domain bmw.de an. Entsprechend unseren Angaben in /etc/named.conf muß sie unter /var/named/bmw.de.zone gespeichert werden.

Listing 3: Die Zonendatei /var/named/bmw.de.zone
bmw.de.         IN SOA poseidon.bmw.de. root.poseidon
                                        ( 20000107      ; serial
                                          36000         ; refresh
                                          1800          ; retry
                                          3600000       ; expire
                                          86400 )       ; time to live
bmw.de.                 IN      NS      poseidon.bmw.de.
                        IN      NS      pns.dtag.de.

bmw.de.                 IN      MX 1    193.158.36.59
                        IN      MX 2    193.158.36.60

localhost               IN      A       127.0.0.1
poseidon                IN      A       193.158.36.58
phoenix                 IN      A       193.158.36.59
venus                   IN      A       193.158.36.60

ftp                     IN      CNAME   phoenix.bmw.de.
www                     IN      CNAME   poseidon.bmw.de.
ns                      IN      CNAME   poseidon.bmw.de.
news                    IN      CNAME   venus.bmw.de.
irc                     IN      CNAME   venus.bmw.de.

bmw.de.         IN SOA poseidon.bmw.de. root.poseidon
                                        ( 20000107      ; serial
                                          36000         ; refresh
                                          1800          ; retry
                                          3600000       ; expire
                                          86400 )       ; time to live (TTL)

Der "SOA"-Record stellt den Kopf der Datenbankdatei dar. bmw.de. legt zunächst die beschriebene Domain fest, achten Sie dabei auf den abschließenden Punkt, der für den Root-Namensraum steht. Diesen Punkt müssen Sie immer hinter alle voll qualifizierten Namen schreiben, sonst geht named von einem erst noch zu vervollständigenden Namen aus und hängt die aktuelle Domain an. poseidon.bmw.de. (wieder mit Punkt am Schluß) steht für den aktuellen Rechner, auf dem named läuft. root.poseidon gibt die Email-Adresse des DNS-Administrators an, der Punkt steht dabei für das sonst übliche "@". Da diesmal der Name nicht mit einem Punkt beendet wird, vervollständigt BIND den Eintrag zu root.poseidon.bmw.de., was praktisch die Mailadresse "" bedeutet. Damit die anderen Nameserver, die Ihre Daten vorhalten (entweder als Secondaries oder in ihrem Cache) deren Aktualität überprüfen können, müssen Sie eine Seriennummer für den Datensatz angeben, die Sie bei jeder Änderung erhöhen. Das konkrete Format bleibt Ihnen überlassen, oft benutzt wird das aktuelle Datum (wie in diesem Fall der 07. 01. 2000 als 20000107). Der Refresh-Wert gibt in Sekunden an, wie oft die Secondary Nameservers nach Updates fragen sollen (hier zehn Stunden). Falls bei dieser Anfrage der Primary Server nicht antworten sollte, wird alle retry (hier: 1800) Sekunden ein neuer Versuch gestartet. Falls innerhalb des expire-Wertes keine Reaktion des Primaries kommen sollte, hört der Secondary Server auf, Requests für diese Domain zu beantworten, da keine Antwort noch immer besser ist als eine falsche. TTL (time to live) wird mit allen Antworten verschickt und zeigt an, wie lange der Datensatz gültig bleibt und im Cache gehalten werden darf. Berücksichtigen Sie, daß bei großen Werten korrigierte Tippfehler oder Änderungen sehr lange brauchen, um sich im Netz zu verbreiten.

bmw.de.                 IN      NS      poseidon.bmw.de.
                        IN      NS      pns.dtag.de.

Die nächsten zwei Zeilen geben alle Nameserver für die Domain an. Der erste ist der Rechner, auf dem sich die Masterzone befindet, danach folgen alle Secondaries.

bmw.de.                 IN      MX 1    193.158.36.59
                        IN      MX 2    193.158.36.60

MX-Records geben die Adressen der MaileXchanges, also der Mailserver an. Die Zahl vor der Adresse ist der Vorzugswert, also eine Art inverse Priorität dieses Servers. Ein SMTP-Server, der eine Mail an schicken will, versucht zunächst eine Verbindung zu dem Server mit dem niedrigsten Vorzugswert aufzubauen, und nur falls dies fehlschlägt, wird er die Liste weiter durchgehen entsprechend der nächsten Prioritäten.

localhost               IN      A       127.0.0.1
poseidon                IN      A       193.158.36.58
phoenix                 IN      A       193.158.36.59
venus                   IN      A       193.158.36.60

A-Records legen das Mapping der Hostnamen auf IP-Adressen fest. So wird poseidon beispielsweise zu poseidon.bmw.de. ergänzt und, falls die Anfrage diesem Namen entspricht, 193.158.36.58 als zugehörige Adresse zurückgegeben.

ftp                     IN      CNAME   phoenix.bmw.de.
www                     IN      CNAME   poseidon.bmw.de.
ns                      IN      CNAME   poseidon.bmw.de.
news                    IN      CNAME   venus.bmw.de.
irc                     IN      CNAME   venus.bmw.de.

CNAME-Datensätze stellen Aliasnamen zur Verfügung. news - da ohne Punkt am Schluß nach Vervollständigung news.bmw.de - wird nach venus.bmw.de übersetzt und der diesem Hostnamen zugehörige A-Satz gesucht und ausgewertet. Die Zone für den localhost, die in jeder Konfiguration enthalten sein muß, entspricht dem gleichen Syntax wie die Datei für bmw.de, lediglich der Umfang ist erheblich übersichtlicher. Allerdings werden einige kleiner Abkürzungen benutzt: Mit $ORIGIN wird localhost. als Makro für die aktuelle Domain benannt, auf die dann die @ verweisen.

Listing 4: Die Zonendatei /var/named/localhost.zone
# /var/named/localhost.zone enthaelt die Zuordnung 
# der loopback-Namen und Adressen

$ORIGIN localhost.
@                       1D IN SOA       @ root (
                                        42      ; serial
                                        3H      ; refresh
                                        15M     ; retry
                                        1W      ; expiry
                                        1D )    ; minimum

                        1D IN NS        @
                        1D IN A         127.0.0.1

Reverse Lookups

Einige Programme versuchen zu IP-Adressen den zugehörigen Hostnamen herauszufinden. Diese Reverse Lookups werden von BIND anhand der in-addr.arpa-Zonendateien aufgelöst. In unserer Datei /etc/named.conf haben wir eine Zone 36.158.193.in-addr.arpa IN ... definiert, die die Adressen 193.158.36.0/24 (also maximal im Bereich 193.158.36.0 bis 193.158.36.255) enthält. Aus historischen Gründen werden die IP-Adressen für die Rückwärtsauflösung auch rückwärts geschrieben (also kein Druckfehler...) und müssen mit in-addr.arpa (und in der Zonendatei natürlich mit in-addr.arpa.) enden.

Listing 5: Die Zonendatei /var/named/36.158.193.zone
# /var/named/36.158.193.zone enthaelt die Zuordnung 
# der Hostnamen zu IP-Adressen

36.158.193.in-addr.arpa.        IN SOA  poseidon.bmw.de. root.poseidon (
                                        20000107        ; serial
                                        3H              ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        1D )            ; TTL

36.158.193.in-addr.arpa.                IN NS   poseidon.bmw.de.
                                        IN NS   pns.dtag.de.
                                
58.36.158.193.in-addr.arpa.             IN PTR  poseidon.bmw.de.
59.36.158.193.in-addr.arpa.             IN PTR  phoenix.bmw.de.
60.36.158.193.in-addr.arpa.             IN PTR  venus.bmw.de.

Der SOA-Record hat das übliche Format (hier sieht man auch die möglichen, selbsterklärenden und sehr praktischen Abkürzungen für Zeitangaben), nur wird hier eben die Rückwärtsauflösung festgelegt und daher ist der Zonenname 36.158.193.in-addr.arpa. Mit NS werden wieder die primären und sekundären Nameserver definiert, danach folgen PTR-Datensätze. Sie sind das Pendant zu den A-Records der Vorwärtsauflösung und ordnen den IP-Adressen die Hostnamen zu. Hier sollte man sorgfältig auf Konsistenz zwischen den A- und den zugehörigen PTR-Sätzen achten. Zusammen mit der Reverse-Mapping Datei für den 127.0.0.0-Adreßraum ist damit die Konfiguration komplett. Da die 1 in der letzten Zeile nicht vollqualifiziert ist und mit keinem Punkt endet, wird sie automatisch zu 1.0.0.127.in-addr.arpa. ergänzt.

Listing 6: Die Zonendatei /var/named/0.0.127.zone
# /var/named/0.0.127.zone enthaelt die Zuordnung 
# von localhost zur Adresse 127.0.0.1

0.0.127.in-addr.arpa.           IN SOA  poseidon.bmw.de. root.poseidon (
                                        43              ; serial
                                        3H              ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        1D )            ; minimum

                        IN NS   poseidon.bmw.de.
1                       IN PTR  localhost.

Fehlersuche

Wie bereits angesprochen ist es durch die Verteilung der Informationen auf alle möglichen Konfigurationsdateien und im nächsten Schritt auf alle möglichen Rechner weltweit nicht so einfach, Fehler zu finden und zu beheben. Am häufigsten - außer dem Nichtneustarten des named-Dämons - wird nach Modifikationen wohl vergessen, die Seriennummer der Zonen zu inkrementieren, so daß die angeschlossenen Rechner nicht bemerken, daß sich etwas geändert hat. Berücksichtigen Sie auch, daß durch das Caching einige Zeit vergehen kann, bis sich Ihre Änderungen im Netz verbreiten (denken Sie hier an einen vernünftigen TTL-Wert). Bei Problemen mit anderen Zonen holen Sie sich am besten mit whois oder finger die Kontaktinformationen des zuständigen Administrators und sprechen mit ihm.

Viele Fehler werden Sie bereits finden, wenn Sie das Systemlog (/var/log/messages) nach einem Neueinlesen der Konfiguration anschauen. Syntaxfehler sind auch die Regel, wenn sich named in so einer Situation verabschiedet (dies sollte nicht der Fall sein, wenn Sie in /etc/named.conf check-names master warn angegeben haben). Prüfen Sie dann, ob Ihre vollqualifizierten Namen in den Zonendateien mit einem Punkt aufhören (also beispielsweise poseidon.qdrei.de., wenn Sie poseidon.qdrei.de schreiben, so wird dies zu poseidon.qdrei.de.qdrei.de. ergänzt, und das ist wohl meist nicht was Sie haben wollen). Falls Anwendungen wie Telnet, die Reverse Lookups durchführen, sehr langsam laufen, ist sicher Ihre Rückwärtsauflösung nicht richtig konfiguriert. Testen Sie das mit dem Tool nslookup, das bei Unix/Linux dabei ist und wohl das Allzwecktool im Werkzeugkasten des BIND-Administrators ist. Im folgenden Beispiel funktioniert zwar die Zuordnung von Adressen zu Namen, aber eben nicht der umgekehrte Fall (193.158.24.68 ist die Adresse des getesteten Nameservers):

root@qdrei.de ~ # nslookup poseidon.autsch.de 193.158.24.68
Server:  autsch.de
Address:  193.158.24.68

Name:    poseidon.autsch.de
Address:  193.158.24.69

root@qdrei.de ~ # nslookup 193.158.24.69
Server:  ns.phade.de
Address:  195.35.22.1

*** ns.phade.de can't find 193.158.24.69: Non-existent host/domain

nslookup wird Ihnen in den meisten Fällen helfen können, außerdem gibt es dnswalk, das Konfigurationen auf häufige Fehler wie inkonsistente A- und PTR-Datensätze hin untersucht. Vergessen Sie nicht, Änderungen der IP-Adresse Ihres Nameservers der zuständigen Stelle (DENIC, INTERNIC etc.) bekanntzugeben. Sehr häufig sind auch Lame oder Missing Delegations: Im ersten Fall liefert ein in der Hierarchie höher stehender Nameserver bei einer Anfrage die Adresse eines angeblich zuständigen Servers, der von seinem Glück aber leider gar nichts weiß. Im letzteren, umgekehrten Fall liefert der Server die Adresse des Zuständigen eben nicht zurück. Um dies zu vermeiden ist eine gute Zusammenarbeit mit Ihrem ISP nötig. Vergessen Sie auch nicht, gelegentlich die Aktualität Ihrer Root-Datei (im Beispiel diese Artikels root.hint) zu überprüfen, dies können Sie natürlich auch mit cron automatisieren (lassen Sie sich aber dann auf alle Fälle die Logausgaben von named mailen).

Infos

[1] bind@uunet.uu.net: Mailingliste, Requests formlos an bindrequest@uunet.uu.net
[2] http://www.cis.ohio-state.edu:80/hypertext/information/rfc.html: Requests for Comments (RFCs) Nr. 1034, 1035, 1537, 1713
[3] http://www.isc.org/products/BIND: Internet Software Consortium; offizielle BIND Homepage
[4] http://www.dns.net/dnsrd: Umfangreiche Resourcenliste
Der Autor

Stephan Lichtenauer ist als Senior Consultant Software & Research bei Q³ Systemhaus (Grafrath, in der Nähe von München) verantwortlich für Design und Implementierung von Software in C/C++, CORBA und Java (EJB) für Unix und NT.

Copyright © 2000 Linux-Magazin Verlag