1.12.6. Konfiguration und Betrieb eines BIND-Nameservers

Die BIND-Implementation des Nameservers heißt named (in einigen Unix-Versionen auch in.named). Er wird üblicherweise beim Systemboot gestartet und liest zunächst sein Konfigurationsfile /etc/named.boot ein. Für jede Zone, für die er autoritativ ist, braucht er die entsprechenden Zonendaten. Da der BIND-NS aus Performance-Gründen alle DNS-Daten im Hauptspeicher hält, liest ein Primary Server diese beim (Re-)Start aus einem Datenfile ein. Ein Secondary Server einer Zone verwendet zunächst Daten aus einem evtl. Backup-File, bevor er einen Zonentransfer vom Primary Server anstößt. Dieser Abgleich erfolgt regelmäßig. Für den Zonentransfer wird das Programm named-xfer (oder in.named-xfer) verwendet.

Die Konfiguration des named ist nicht trivial und füllt ganze Bücher (siehe Vertiefung). An dieser Stelle können nur einige Hinweise für den Start gegeben werden.

Das named.boot File

Hier wird der Typ des Servers festgelegt: für welche Zone(n) Primary, wofür Secondary und so weiter. Dies soll an einem Beispiel erläutert werden:

; /etc/named.boot

; Arbeitsverzeichnis, dort befinden sich die u.g. Dateien
directory    /var/domain   ; muss existieren

; Typ          Domain                 Datei/Nameserver  Backupfile 
primary        iuk.tu-chemnitz.de     db.iuk
primary        1.168.192.in-addr.arpa db.192.168.1
secondary      tu-chemnitz.de         134.109.132.51    db.tu-chemnitz
primary        0.0.127.in-addr.arpa   db.127.0.0
cache          .                      db.root

; Andere Anfragen an folgende NS weiterleiten
forwarders        134.109.132.51 134.109.132.55
; Falls keine Anfragen nach aussen erwünscht (Slave NS), 
; folgende Anweisung aktivieren:
; options forward-only

Hiermit wird ein NS konfiguriert, der für die Zone iuk.tu-chemnitz.de ein Primary NS ist. Die entsprechenden Zonendaten liest er aus der Datei /var/domain/db.iuk. Des weiteren ist er auch ein Primary NS für das Reverse Mapping seines IP-Adreßraumes 192.168.1.x.

Für tu-chemnitz.de ist der NS als Secondary NS zuständig. Die entsprechenden Zonendaten liest er aus dem Backupfile /var/domain/db.tu-chemnitz, bevor diese Daten auf Aktualität geprüft werden. Er ruft die Serial Number vom Primary NS (134.109.132.51) ab und vergleicht sie mit der im Backupfile enthaltenen. Ist erstere größer, werden alle Daten der Zone tu-chemnitz.de via Zonentransfer beschafft und das Backupfile erneuert.

Für das Reverse Mapping der Loopback-Adresse (127.0.0.1) sollte jeder NS Primary sein.

Die cache-Anweisung schaltet das Caching von anderen DNS-Daten ein und verweist auf eine Datei, in der die IP-Adressen der Root-NS verzeichnet sind. Diese werden sozusagen als Initialzündung benötigt.

Mit der forwarders-Anweisung beeinflußt man das Verhalten des NS, wenn er rekursiv andere DNS-Daten (für die er nicht autoritativ ist) abfragen soll. In dem Falle soll er zunächst die in der Liste angegebenen NS befragen, bevor er die eigentlich zuständigen NS kontaktiert (mit der Option forward-only kann man auch das unterdrücken).

Weitere Konfigurationsbeispiele:

named.boot für Caching-only NS

; Caching-only NS
; ist nur Primary fuer 0.0.127.in-addr.arpa

directory  /usr/local/domain

;type      domain                host/file             backup file

cache      .                     db.cache
primary    0.0.127.in-addr.arpa  db.127.0.0

; keine Beschraenkung, fragt externe NS

Ein solcher NS ist nur für das Reverse Mapping von 127.0.0.1 zuständig, aber nicht für "richtige" DNS-Daten.

named.boot für NS ohne Internet-Verbindung

; Nameserver fuer ein Netz ohne Internet-Anschluss
; "Interner Root-NS", kein Caching 

directory	/usr/local/domain   ; running directory for named

;type		domain			host/file

primary		.			db.internal
primary		0.0.127.in-addr.arpa	db.127.0.0
primary		iuk.tu-chemnitz.de	db.iuk.tu-chemnitz.de

In diesem Falle kann der NS nur DNS-Daten auflösen, für die er autoritativ ist. Deswegen wird auch kein Cache angelegt. Spezielle Vorkehrungen sind nötig, z.B. muß er selbst als "Quasi-Root-NS" konfiguriert sein.

Die Datenfiles

Für jede Zone, für die ein NS Primary ist, liest er beim Start ein speziell formatiertes Datenfile. Das Format ist relativ streng, aber "menschenlesbar" (und "menschenschreibbar", man muß aber etwas sorgfältig sein!).

Ein solches File bezieht sich immer auf eine Domain (sog. ORIGIN, wird mit der Option primary in named.boot festgelegt). Deswegen kann man darin auch relative Namen verwenden. Absolute Namen muß man mit einem Punkt abschließen (häufige Fehlerquelle). Bezieht man sich auf die Domain selbst, wird das Zeichen "@" geschrieben.

Die Einträge in den Datenfiles bilden die Resource Records (RR), also die DNS-Dateneinheiten, in folgendem Format (optionale Felder in eckigen Klammern):

[Domain] [TTL] [Klasse] Typ Daten

Die Felder werden durch Leerzeichen oder Tabulatoren getrennt. Ein Semikolon startet einen Kommentar, der bis zum Zeilenende reicht.

Domain: ist der Domainname, für den der Eintrag gilt. Er kann weggelassen werden (d.h., die Zeile beginnt mit Leerzeichen/Tabulator), dann wird der vorige verwendet (wenn eine Domain mehrere RR hat).
TTL: Dies ist das Time-To-Live-Feld, das festlegt, wie lange diese Information in einem Cache liegen darf. Die Angabe erfolgt in Sekunden und ist max. 8 Dezimalstellen lang. Ist kein TTL-Feld vorhanden (das ist wohl der Normalfall), wird das minimum-Feld des SOA-Records verwendet (s.u.).
Klasse: Das ist die Adreßklasse, die für TCP/IP immer IN lautet (Es gibt weitere, weniger verbreitete solche Klassen, wie z.B. HS für Hesiod). Fehlt diese Angabe, wird die des vorigen RR verwendet.
Typ: beschreibt die Art der folgenden Daten. Am gebräuchlichsten sind A, SOA, NS, MX, CNAME und PTR.
Daten: Der eigentliche Inhalt des RR. Das Format hängt vom Typ ab.

Betrachten wir nun die wichtigsten RR-Typen und ihre Verwendung (mit einigen Hinweisen):

SOA

Ein solcher RR muß zu Beginn der Zonendaten stehen und zeigt an, daß die folgenden RR autoritative Daten sind (SOA steht für "Start of Authority"). Die Daten bestehen aus mehreren Feldern, die durch Einschluß in runde Klammern auch über mehrere Zeilen ausgedehnt sein können:

origin	kanonischer, absoluter Hostname des Primary NS dieser Zone - kein Aliasname!
contact	E-Mailadresse des Zonenadministrators ('@'-Zeichen durch Punkt ersetzt) - wird nicht von NS selbst verwendet.
serial	Versionsnummer der Zonendaten (Dezimalzahl). Anhand dieser Nummer vergleicht ein Secondary NS die Aktualität seiner Daten. Bei Änderung der Daten muß diese erhöht werden (nicht vergessen!), damit die Secondary NS dies mitbekommen. Als günstig hat sich eine Kodierung des Datums in die Serial Number erwiesen: YYYYMMDD00, z.B. 1996111900, die zwei letzten Ziffern sind laufende Nummern für Änderungen an einem Tag (00 ... 99, sollte ausreichen).
refresh	Intervall, aller wieviel Sekunden ein Secondary NS die Aktualität der Zonendaten prüfen soll. Hier muß man einen Kompromiß zwischen Aktualität und Netzverkehr finden. Vor wichtigen Änderungen kann man diese Zeit herabsetzen, damit die Secondaries ihre Kopien schneller erneuern. Je nachdem, wie oft sich Daten in einer Zone ändern, kann dieser Wert zwischen einer Stunde und einigen Tagen liegen.
retry	Intervall, aller wieviel Sekunden ein fehlgeschlagener Aktualitätstest wiederholt werden soll. Das ist im allgemeinen ein geringerer Wert als refresh.
expire	Zeit in Sekunden, nach der ein Secondary NS alle Zonendaten löscht, wenn er den Primary NS nicht kontaktieren kann. Hier wird eine große Zeitdauer empfohlen, z.B. 42 Tage.
minimum	Standard-TTL für RR ohne eigene TTL. Betrifft die Gültigkeitsdauer von Daten in einem Cache (nicht im Seconday NS). Kann im allgemeinen auch hoch sein (Tage ... Wochen). Für Daten, die sich häufiger ändern, können ja auch individuell kleinere TTLs vergeben werden.

Beispiel:

; SOA fuer tu-chemnitz.de, primary NS saturn.hrz.tu-chemnitz.de

@   IN SOA  saturn.hrz.tu-chemnitz.de. hostmaster.tu-chemnitz.de. (
            1996111900  ; serial
            10800       ; refresh every 3 hours
            3600        ; retry every hour
            3628800     ; expire after 42 days
            259200 )    ; minimum ttl of 3 days

NS

Diese RRs zeigen auf autoritative NS für die eigene Zone bzw. für delegierte Zonen. Dabei wird nicht zwischen Primary und Secondary unterschieden. Hier ist der kanonische Hostname und kein Aliasname anzugeben!

Die NS-RR für die eigene Zone müssen im Zonenfile unmittelbar nach dem SOA-RR stehen.

Beispiel:

  tu-chemnitz.de.      IN NS   saturn.hrz.tu-chemnitz.de.  
                       IN NS   ns.nic.de.

Wenn man eine Zone delegiert, werden die Hostnamen der zuständigen Nameserver angegeben. Liegen diese NS in der delegierten Zone und ist man nicht selber Secondary Server für diese Zone, muß man hier durch einen sogenannten Glue Record die IP-Adresse des Servers eintragen (sonst könnte der Name hier nicht aufgelöst werden).

Beispiel:

  iuk.tu-chemnitz.de.      IN NS   ns.iuk.tu-chemnitz.de.
  ns.iuk.tu-chemnitz.de.   IN A    192.168.1.1

Man mag sich wundern, daß hier Daten einer Zone eingetragen werden, für die man gar nicht autoritativ ist. Aber nur so kann hier die Zonen-Delegierung funktionieren.
Vorsicht mit Glue Records! Im gerade genannten Fall müssen wir sie verwenden, aber im Beispiel davor wird kein Glue Record benötigt, da der NS ns.nic.de nicht in einer delegierten Zone liegt.

A

Dieser RR enthält eine IP-Adresse in üblicher Darstellung und dient der Auflösung von Hostnamen, also der wichtigsten NS-Funktion. Hat ein Rechner mehrere Netz-Interfaces, werden mehrere A-RR vergeben.

Beispiel:

  router            IN A  192.168.1.254
                    IN A  192.168.100.254

CNAME

Hiermit wird einem Aliasnamen ein Verweis auf den richtigen, den kanonischen Hostnamen (der mit A RR) gegeben. Ein solcher Aliasname darf keine weiteren RRs haben.

Beispiel:

  ftp         IN CNAME  fripp.hrz.tu-chemnitz.de.

PTR

Dieser RR-Typ dient dem Reverse Mapping, indem er Einträge in der in-addr.arpa-Domain mit (kanonischen) Hostnamen verbindet.

Beispiel:

  ; ORIGIN ist 1.168.192.in-addr.arpa.
  254  IN PTR  router.iuk.tu-chemnitz.de.

MX

Damit wird ein Mail Exchanger für eine Domain definiert. Das ist sozusagen das "zuständige Postamt" und regelt die Zustellung für E-Mail im Internet. Aus Gründen der Redundanz werden häufig mehrere Mail Exchanger mit unterschiedlicher Präferenz (kleine Zahl bedeutet große Priorität) angegeben. Genaueres dazu in einem späteren Kapitel ...

Beispiel:

  hrz.tu-chemnitz.de.   IN MX  10  obelix.hrz.tu-chemnitz.de.
                        IN MX  100 deneb.dfn.de.

HINFO

Hier kann man Informationen zu Hardware und Betriebssystem eines Rechners ablegen. Dieser RR besteht aus genau 2 Zeichenketten. Falls Leerzeichen enthalten sind, ist die Zeichenkette in Anführungszeichen zu setzen. Das wird häufig vergessen und führt daher zu Fehlern.

Beispiel:

  hydra.informatik.tu-chemnitz.de.   IN HINFO  "i586" "Linux 2"

Nun muß nicht jeder DNS-Eintrag all diese RRs besitzen. Am wichtigsten ist zuerst einmal der A-RR mit der IP-Adresse. Einträge für das Reverse Mapping enthalten nur einen PTR-RR.

Betrachten wir abschließend komplette Beispiel-Datenfiles. Sie bilden zusammen mit dem ersten /etc/named.boot-File einen funktionstüchtigen Nameserver auf einem (imaginären) Rechner uff.iuk.tu-chemnitz.de für die (imaginäre) Domain iuk.tu-chemnitz.de inkl. Reverse Mapping.

Zunächst die Zonendaten für iuk.tu-chemnitz.de in db.iuk:

; Named-Datenbasis fuer unsere "Spieldomain" iuk.tu-chemnitz.de
; ORIGIN ist iuk.tu-chemnitz.de.
; Diese Angabe wird an alle nicht durch Punkt abgeschlossenen
; Namen angehaengt.

@ IN SOA uff.iuk.tu-chemnitz.de. root.iuk.tu-chemnitz.de. (
        1996111900      ; serial
        86400           ; refresh, 1 Tag
        3600            ; retry, 1 Stunde
        3628800         ; expire, 42 Tage
        86400 )         ; default TTL, 1 Tag

        IN NS    uff.iuk.tu-chemnitz.de.
; wir haben keinen Secondary NS, der muesste sonst hier stehen

uff     IN A     192.168.1.1
        IN HINFO "AT 486" "Linux"
        IN MX    10  biff.iuk.tu-chemnitz.de.

baff    IN A     192.168.1.2
       
biff    IN A     192.168.1.3
mailsrv IN CNAME biff

Das Reverse Mapping steht in db.192.168.1:

; Named Datenbasis fuer Reverse Mapping der IP-Adressen 192.168.1.x
; ORIGIN ist 1.168.192.in-addr.arpa.
@ IN SOA uff.iuk.tu-chemnitz.de. root.iuk.tu-chemnitz.de. (
        1996111900      ; serial
        86400           ; refresh, 1 Tag
        3600            ; retry, 1 Stunde
        3628800         ; expire, 42 Tage
        86400 )         ; default TTL, 1 Tag
        IN NS    uff.iuk.tu-chemnitz.de.

1  IN PTR  uff.iuk.tu-chemnitz.de.  ; letzten Punkt nicht vergessen,
2  IN PTR  baff.iuk.tu-chemnitz.de. ; sonst wird ORIGIN angehaengt!
3  IN PTR  biff.iuk.tu-chemnitz.de.

Die Datei db.root enthält die Hinweise auf die Root-NS (hier gekürzt dargestellt). Die vollständige Datei ist u.a. beim INTERNIC verfügbar: ftp://ftp.rs.internic.net/domain/named.root.

;  This file holds the information on root name servers needed to
;  initialize cache of Internet domain name servers

.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
; ... usw.

Schließlich noch die immer weitgehend identisch verwendbare Datei für das Reverse Mapping der Loopback-Adresse:

; Reverse Mapping fuer 127.0.0.1 (localhost)

@       IN SOA  uff.iuk.tu-chemnitz.de. root.iuk.tu-chemnitz.de. (
                1 10800  3600  604800 86400 )

        IN NS   uff.iuk.tu-chemnitz.de.

1       IN PTR  localhost.

Damit ist unser Spiel-NS komplett ... uff :-)

Für den Fall, daß wir ihn in einem abgeschlossenen Netz ohne Internet-Zugang betreiben, müssen wir den NS als "Pseudo-Root-NS" konfigurieren (s. dazu obiges named.boot). Das nötige File db.internal ist hier gezeigt:

; Pseudo-Root-Nameserver fuer den Fall, dass wir nicht direkt im
; Internet sind, d.h. keine Online-Verbindung zu den richtigen 
; Root-NS aufbauen koennen.
; NICHT ZU VERWENDEN, WENN WIR ONLINE SIND.

. IN SOA uff.iuk.tu-chemnitz.de. root.iuk.tu-chemnitz.de. (
        1       ; serial
        86400   ; refresh
        3600    ; retry
        608400  ; expire
        86400 ) ; minimum
  IN NS uff.iuk.tu-chemnitz.de.

uff.iuk.tu-chemnitz.de. IN A  192.168.1.1 
iuk.tu-chemnitz.de.     IN NS uff.iuk.tu-chemnitz.de.

Betrieb des Nameservers

Haben wir alle Dateien komplett, gehen wir frohen Mutes an den Start des Nameservers. Viele Aktionen des named können wir mit dem Kommando ndc beeinflussen bzw. kontrollieren.

So verwenden wir zum Start:: ndc start
und zur Kontrolle, ob er auch läuft:: ndc status

Named teilt Status-Informationen via Syslog-Daemon mit (Level daemon.notice, Näheres dazu im Unix-Manual: syslogd bzw. syslog.conf). Unter Linux werden diese Meldungen üblicherweise in die Datei /var/adm/messages geschrieben.

Dort kontrollieren wir nach dem Start:: tail /var/adm/messages

Evtl. Fehler in den Datenfiles finden wir dort notiert. Deutet nichts auf Fehler hin, können wir den Nameserver testen, indem wir z.B. das Programm nslookup aufrufen und einige Daten abfragen.

Hier folgen weitere Aktionen mit dem Kommando ndc, die z.T. zur Fehlersuche benutzt werden können:

`ndc reload`	überprüft anhand der Serial Number die Aktualität aller Zonen, für die er autoritativ ist, und lädt ggf. die neuen Daten (Cache bleibt erhalten)
`ndc restart`	Stopp und Neustart (Cache geht verloren)
`ndc dumpdb`	interne Datenbasis und Cache werden nach `/var/tmp/named_dump.db` geschrieben - Kontrollmöglichkeit
`ndc stats`	Statistikdaten werden nach `/var/tmp/named.stats` geschrieben
`ndc trace`	Debug-Level wird erhöht, schreibt nach `/var/tmp/named.run`. Achtung - viele Daten!
`ndc notrace`	schaltet Debugging aus
`ndc querylog`	schaltet das Loggen der Anfragen um. Für jede Anfrage wird via syslog auf Level `daemon.info` eine Zeile geschrieben. Achtung - viele Daten!
`ndc stop`	Stopp

Läuft der named, haben wir uns eine Pause verdient. Denn wenn erst einmal die Hürde der Konfiguration genommen ist, funktioniert der Nameserver eigentlich völlig problemlos. Ein paar Routine-Tätigkeiten sollte man dennoch einplanen:

Logfiles durchsehen: Dafür gibt es Tools, die die Aktivitäten zusammenfassen und auf Unregelmäßigkeiten hinweisen.
Statistiken erzeugen und auf massive Anfragen einzelner Rechner durchsehen (das deutet auf fehlkonfigurierte Resolver hin).

In der BIND-Distribution sind einige Tools enthalten, die von Nameserver-Administratoren für Routine-Arbeiten geschrieben wurden.

Nun ist es Zeit, uns zu überlegen, wie wir die Datenfiles in Zukunft verwalten wollen. Das Editieren "per Hand" ist natürlich die einfachste Methode (diesbezüglich können Sie mir u.U. gar nicht zustimmen ...), zumindest braucht man dazu nichts weiter als einen Editor. Allerdings sind die Fehlermöglichkeiten doch ziemlich groß, daher sollte die Datenbasis regelmäßig geprüft werden. Dazu gibt es z.B. ein Tool namens dnswalk, einen sog. DNS-Datenbasis-Debugger. Er beschafft sich alle DNS-Daten einer angegebenen Zone und überprüft sie nach allen Regeln der Kunst. So werden z.B. fehlende oder falsche Reverse Mappings gefunden.

Denkbar wäre die Verwaltung der Rechner in einer Datenbank, aus der die named-Datenfiles per Programm einfach erzeugt werden können. Solche Produkte gibt es, sie sind wie die o.g. Tools im DNS Resources Directory - Tools [http://www.dns.net/dnsrd/tools.html] gesammelt.

Vertiefung:

BIND Homepage [http://www.isc.org/bind.html]
In UnixWorld Online: "PC-Unix Connection" Column: No. 005 findet sich der Artikel DNS Database Files [http://www.nwc.com/unixworld/pcunix/005.html]