 |
|
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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 17:56:55