Inhalt

3. Ein »caching-only«-Nameserver

Ein erster Ausblick auf die DNS-Konfiguration - sehr praktisch für Benutzer, die sich ins Internet einwählen.

Ein »caching-only« Nameserver (ich werde den englischen Begriff weiterverwenden, weil sich »nur-Zwischenspeicher« nicht besonders schön anhört) wird auf Namensanfragen antworten und sich bei der nächsten Anfrage an die alte Antwort erinnern. Dieses Vorgehen verkürzt vor allem die Wartezeit bei jeder weiteren Anfrage - besonders, wenn man nur eine langsame Verbindung hat.

Zuerst wird eine Datei namens /etc/named.conf gebraucht. Sie wird bei jedem Start vom named eingelesen. Erstmal sollte sie einfach nur das folgende enthalten:

// Konfigurationsdatei für einen caching-only Nameserver

options {
        directory "/var/named";

        // Wenn Verbindungen über eine Firewall gehen müssen und das nicht
        // so funktioniert, wie es sollte, hilft es vielleicht, die folgende
        // Zeile auszukommentieren.

        // query-source port 53;
};

zone "." {
        type hint;
        file "root.hints";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};

Die »directory«-Zeile sagt dem named, wo er nach Dateien suchen soll. Alle noch folgenden Dateien gehören in dieses Verzeichnis (oder einem Unterverzeichnis relativ hierzu). Also ist pz ein Unterverzeichnis in /var/named: /var/named/pz. /var/named ist nach dem Linux File system Standard das für den Nameserver vorgesehene Verzeichnis für die Konfigurationsdateien eines Nameservers.

Die Datei /var/named/root.hints sollte die folgenden Daten beinhalten:

;
; Wenn diese Datei bereits existiert, könnten hier 
; einführende Kommentare stehen.
; Falls nicht - keine Panik ;-).
;
.                       6D IN NS        G.ROOT-SERVERS.NET.
.                       6D IN NS        J.ROOT-SERVERS.NET.
.                       6D IN NS        K.ROOT-SERVERS.NET.
.                       6D IN NS        L.ROOT-SERVERS.NET.
.                       6D IN NS        M.ROOT-SERVERS.NET.
.                       6D IN NS        A.ROOT-SERVERS.NET.
.                       6D IN NS        H.ROOT-SERVERS.NET.
.                       6D IN NS        B.ROOT-SERVERS.NET.
.                       6D IN NS        C.ROOT-SERVERS.NET.
.                       6D IN NS        D.ROOT-SERVERS.NET.
.                       6D IN NS        E.ROOT-SERVERS.NET.
.                       6D IN NS        I.ROOT-SERVERS.NET.
.                       6D IN NS        F.ROOT-SERVERS.NET.

G.ROOT-SERVERS.NET.     5w6d16h IN A    192.112.36.4
J.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.10
K.ROOT-SERVERS.NET.     5w6d16h IN A    193.0.14.129
L.ROOT-SERVERS.NET.     5w6d16h IN A    198.32.64.12
M.ROOT-SERVERS.NET.     5w6d16h IN A    202.12.27.33
A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4
H.ROOT-SERVERS.NET.     5w6d16h IN A    128.63.2.53
B.ROOT-SERVERS.NET.     5w6d16h IN A    128.9.0.107
C.ROOT-SERVERS.NET.     5w6d16h IN A    192.33.4.12
D.ROOT-SERVERS.NET.     5w6d16h IN A    128.8.10.90
E.ROOT-SERVERS.NET.     5w6d16h IN A    192.203.230.10
I.ROOT-SERVERS.NET.     5w6d16h IN A    192.36.148.17
F.ROOT-SERVERS.NET.     5w6d16h IN A    192.5.5.241

Diese Datei enthält die Hauptnameserver des Internet; auch Root-Nameserver genannt. Da sich diese Daten gelegentlich ändern, muss sie regelmässig erneuert werden. Mehr darüber gibt es im Abschnitt Wartung.

Der nächste zu erklärende Abschnitt in der named.conf-Datei ist die letzte Zone. Darauf werde ich aber erst später zurückkommen. Erstmal wird jetzt eine Datei namens 127.0.0 im Unterverzeichnis pz erstellt:

@               IN      SOA     ns.linux.test. hostmaster.linux.test. (
                                1       ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                1W      ; Expire
                                1D)     ; Minimum TTL
                        NS      ns.linux.test.
1                       PTR     localhost.

Der nächste Schritt ist die Erstellung einer /etc/resolv.conf-Datei, die so aussehen sollte:

search unterdomain.eigene-domain.de eigene-domain.de
nameserver 127.0.0.1

Die »search«-Zeile definiert die Suchreihenfolge der Domains, zu denen ein Rechner gehören könnte, der eine Anfrage an den named durchführt. Die »nameserver«-Zeile enthält die Adresse vom eigenen Nameserver. In diesem Fall ist das der eigene Computer, da dass der Rechner sein wird, auf dem der named eingerichtet wird (127.0.0.1 ist richtig, ganz egal, was die Maschine sonst noch für Adressen hat). Wenn man mehrere Nameserver auflisten möchte, macht man das, indem für jeden Server eine eigene »nameserver«-Zeile eingefügt wird. Der named selber wird diese Datei nie einlesen, sondern der resolver. Das ist ein Programm, welches die Anfragen an den named durchführt.

Eine kleine Beschreibung, was diese Datei bewirkt: Wenn ein Client-Programm versucht, einen Computer namens bla zu finden, dann wird zuerst nach bla.unterdomain.eigene-domain.de gesucht, anschliessend nach bla.eigene-domain.de und erst zuletzt nach bla. Wenn versucht wird, den Rechner sunsite.unc.edu zu finden, wird zuerst nach sunsite.unc.edu.unterdomain.eigene-domain.de (ja - das ist nicht sinnvoll, aber so funktioniert es nunmal...), dann nach sunsite.unc.edu.eigene-domain.de und erst zuletzt nach sunsite.unc.edu gesucht. Aus diesem Grund sollte man nicht zu viele Domains in die search-Zeile schreiben, da es lange dauern kann bis alle durchsucht wurden.

Das Beispiel geht davon aus, dass man zu der Domain unterdomain.eigene-domain.de gehört. Der eigene Rechner wird dann vermutlich eigener-Rechner.unterdomain.eigene-domain.de heissen. Auf keinen Fall sollte die search-Zeile die eigene TLD (Top Level Domain, in diesem Fall »de«) enthalten. Wenn man regelmässig Verbindungen zu Computern in anderen Domains aufbaut, dann wird diese wie folgt zusätzlich eingetragen:

search unterdomain.eigene-domain.de eigene-domain.de andere-domain.com

Und so weiter. Natürlich sollten existierende Domainnamen anstelle meiner ausgedachten benutzt werden. Ausserdem sollte man darauf achten, dass am Ende der Domainnamen keine Punkte stehen - wieso das wichtig ist, wird später erklärt.

Der nächste Schritt hängt von der verwendeten libc-Version ab. Entweder muss man die Datei /etc/nsswitch.conf oder die Datei /etc/host.conf anpassen. Wenn bereits eine nsswitch.conf existiert, muss diese geändert werden - falls nicht, passt man die host.conf an.

/etc/nsswitch.conf

In dieser etwas längeren Datei wird eingestellt, aus welcher Datei oder Datenbank Daten zu einem bestimmten Dienst geholt werden. Sie enthält normalerweise gleich am Anfang sehr hilfreiche Kommentare, die gelesen werden sollten. Die mit »hosts:« beginnende Zeile sollte wie folgt lauten:

hosts:      files dns

Wenn es noch keine Zeile mit »hosts:« am Anfang gibt, dann wird die oben gezeigte einfach hinzugefügt. Die Zeile besagt, dass Programme zuerst in der /etc/hosts-Datei nachschauen sollen und erst dann das DNS nach den Vorgaben in der resolv.conf zur Aufschlüsselung von Rechnernamen genutzt wird.

/etc/host.conf

Diese Datei enthält vermutlich mehrere Zeilen. Eine davon müsste mit order beginnen und sollte wie die folgende aussehen:

order hosts,bind

Wenn es keine »order«-Zeile gibt, wird sie hinzugefügt. Sie bewirkt, dass die Routinen, die die Computernamen aufschlüsseln, zuerst in der /etc/hosts nachschauen und dann beim Nameserver anfragen, der laut resolv.conf der Rechner mit der IP 127.0.0.1 ist.

3.1 Starten des named

Nachdem das alles erledigt ist, ist es an der Zeit, den named das erste Mal zu starten. Eventuell ist vorher noch die Verbindung ins Internet zu starten. Dann gibt man

ndc start/

ein. Sollte das nicht funktionieren, klappt statt dessen vielleicht der folgende Befehl:

/usr/sbin/ndc start

Wenn auch das nicht das gewünschte Ergebnis liefert, bleibt nur ein Blick in den Abschnitt Fragen und Antworten. Ein Blick in die Datei, in der der syslog Nachrichten speichert (üblicherweise heisst diese /var/adm/messages - sie kann aber auch im Verzeichnis /var/log gefunden werden oder nicht messages sondern syslog heissen...), während der named gestartet wird (tail -f /var/log/messages) sollte etwas Ähnliches wie das folgende zeigen:

(Zeilen, die mit \ enden, werden in der nächsten Zeile fortgeführt)

Feb 15 01:26:17 roke named[6091]: starting.  named 8.1.1 Sat Feb 14 \
  00:18:20 MET 1998 janl@roke.uio.no:/var/tmp/bind-8.1.1/src/bin/named
Feb 15 01:26:17 roke named[6091]: cache zone "" (IN) loaded (serial 0)
Feb 15 01:26:17 roke named[6091]: master zone "0.0.127.in-addr.arpa" \
  (IN) loaded (serial 1)
Feb 15 01:26:17 roke named[6091]: listening [127.0.0.1].53 (lo)
Feb 15 01:26:17 roke named[6091]: listening [129.240.230.92].53 (ippp0)
Feb 15 01:26:17 roke named[6091]: Forwarding source address is [0.0.0.0].1040
Feb 15 01:26:17 roke named[6092]: Ready to answer queries.

Wenn der named Fehler in der Konfiguration findet, meldet er im Logfile unter anderem den Name der Datei, die den Fehler enthält: entweder named.conf oder root.hints - hoffe ich :-). Dann wird der named beendet und die Datei muss überarbeitet werden.

Ansonsten können die Einstellungen jetzt getestet werden. Mit nslookup kann man seine Arbeit kontrollieren.

$ nslookup
Default Server:  localhost
Address:  127.0.0.1

>

Wenn dieses auf dem Bildschirm erscheint, läuft es. Hoffentlich. Wenn etwas anderes auftaucht, müssen alle Einstellungen von Anfang an kontrolliert werden. Jedesmal, wenn die named.conf-Datei verändert wurde, muss der named mit dem Befehl

named restart

neu gestartet werden.

Ansonsten kann jetzt eine erste Anfrage gemacht werden. Zuerst versucht man einen Rechner herauszufinden, der sich »in der Nähe« befindet. pat.uio.no befindet sich in meiner Nähe - an der Universität in Oslo:

> pat.uio.no
Server:  localhost
Address:  127.0.0.1

Name:    pat.uio.no
Address:  129.240.130.16

nslookup hat jetzt den gerade konfigurierten named nach dem Rechner pat.uio.no gefragt. Um darauf antworten zu können, fragt dieser einen der Nameserver aus der root.hints-Datei und bahnt sich von dort aus seinen Weg zum vollen Namen des Rechners. Vielleicht dauert es ein wenig, bis das Ergebnis gezeigt wird, weil zuerst alle Domains aus der /etc/resolv.conf durchsucht werden.

Macht man die gleiche Anfrage nochmal, bekommt man dieses Ergebnis:

> pat.uio.no
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
Name:    pat.uio.no
Address:  129.240.2.50

Man beachte die »Non-authoritative answer:«-Zeile, die dieses mal zusätzlich erscheint. Sie bedeutet, dass der named dieses Mal nicht im Netz nachgefragt hat, sondern dass die Informationen aus seinem Cache stammen. Durch die »Non-authorative answer:« wird man über die (sehr kleine) Möglichkeit informiert, dass diese zwischengespeicherten Daten eventuell nicht mehr aktuell sind. Wenn nslookup diese Zeile bei der zweiten Anfrage ausgibt, ist das ein sicheres Zeichen dafür, dass die Daten zwischengespeichert werden und dass der named wie gewünscht funktioniert. nslookup wird beendet, indem man »exit« eingibt.

3.2 Was noch verbessert werden kann

In grossen, gut organisierten wissenschaftlichen oder ISP (Internet Service Provider)-Netzen sieht man gelegentlich, dass die Netzwerkadministratoren sogenannte »forwarder«-DNS-Server eingerichtet haben, die dazu beitragen, dass die interne und externe Netzwerkbelastung klein bleibt. Es ist nicht leicht, herauszufinden, ob man sich in so einem Netz befindet - oder nicht. Es ist aber auch nicht wichtig und indem man den DNS-Server vom eigenen Provider als »forwarder« benutzt, kann man die Antwortzeiten auf Anfragen erheblich verkürzen und die Netzwerkbelastung sehr niedrig halten. Gerade für Leute mit Modem ist das ein nicht unerheblicher Vorteil. Um ein Beispiel nennen zu können, gehe ich davon aus, dass der Netz-Provider zwei Nameserver hat, die man benutzen kann und die die IPs 10.0.0.1 und 10.1.0.1 haben. Dann werden in die Datei named.conf in den Anfangsabschnitt »options« die folgenden Zeilen eingefügt:

           forward first;
           forwarders {
                10.0.0.1;
                10.1.0.1;
            };

Jetzt den Nameserver neu starten und mit nslookup testen. Er sollte die gleichen Ergebnisse wie vorher liefern.

3.3 Gratulation

Damit ist die Installation eines »caching-only« Nameservers beendet. Zeit für ein Bier, eine Milch oder was auch immer man zur Feier des Tages trinken möchte.


Inhalt