20.2 BIND aufsetzen
In diesem Buch soll der Software mit dem größeren Funktionsumfang – also dem DNS-Server BIND – der Vortritt gelassen werden. Zwar gibt es Tools für die Konfiguration von BIND – doch diese stehen erstens nicht auf jedem System zur Verfügung, und zweitens wollen wir Ihnen grundsätzliches Hintergrundwissen vermitteln. Daher lernen Sie im Folgenden, wie Sie BIND mittels der zugehörigen Konfigurationsdateien zum Laufen bringen.
Die Basiskonfiguration von BIND erfolgt über die Datei named.conf. Je nach Linux"=Distribution beziehungsweise BSD-Derivat befindet sie sich Datei meist im Verzeichnis /etc, /var/named oder /usr/local/etc.
Zone konfigurieren
Zunächst wird eine Zone konfiguriert. Um beispielsweise das lokale Netzwerk »sun« einzubauen, müsste diese Zone den Namen »sun« erhalten. Dabei soll der neue Server Master-Server der Domain werden, was man mit type master spezifiziert. Die Daten der Resource Records (also die Dateneinheiten im DNS-Server, dazu zählen beispielsweise Zuweisungen von Hostnames zu IPs) sollen in der Datei sun im BIND-Unterverzeichnis master liegen – also zum Beispiel in /var/named/master/sun.
Listing 20.1 sun
zone "sun" {
type master;
file "master/sun";
};
Slave-Server
Ein Slave-Server spiegelt die Daten eines anderen DNS-Servers (Master-Server) und dient der Ausfallsicherheit. Um einen Slave-Server zu konfigurieren, geben Sie type slave und einen oder mehrere Master an:
Listing 20.2 Master angeben
masters { 192.168.0.1; [...;] };
Caching-only
Ein Caching-only-Server ist ein Server, der selber keine Resource Records beinhaltet, sondern nur als ein Proxy dient. Ein Caching-only-Server wird im lokalen Netz verwendet, um Anfragen an einen übergeordneten DNS-Server weiterzuleiten. Die Antworten der übergeordneten Server werden zwischengespeichert (gecached) und entsprechende Antworten können somit bei wiederholter Anfrage eines Resource Records schneller beantwortet werden. Um einen Caching-only-Server aufzusetzen, müssen hingegen noch Hosts spezifiziert werden, zu denen die DNS-Requests weitergeleitet werden sollen. Dies funktioniert durch das Schlüsselwort forwarders, das man im options-Teil hinzufügt:
Listing 20.3 forwarders
options {
...
forwarders { 10.0.0.213; };
...
}
Resource Records anlegen
Um nun eine eigene Zone mit eigenen Resource Records (RR) anzulegen, erstellt man die in der Zonen-Konfiguration mit dem Schlüsselwort file angegebene Datei und fügt in diese mit einem Texteditor die Resource Records ein.
Eine fertige RR-Datei sieht etwa folgendermaßen aus:
Listing 20.4 sun-Datei
$ORIGIN sun.
Domain
Mit $ORIGIN wird die Domain für alle folgenden Hosts festgelegt. Der Eintrag sun. hängt an alle unten definierten A-Records (also Zuweisungen von Hostnames an IP-Adressen) die Domain .sun. an und spart somit Arbeit, zudem trägt er zur Übersichtlichkeit der Konfigurationsdatei bei.
Listing 20.5 sun-Datei (Fortsetzung)
$TTL 6h
; Das ist ein Kommentar
Lebensspanne
Mittels $TTL (time to live) wird eine allgemein gültige Lebensspanne für die Resource Records festgelegt. Sie kann auch für jeden Record einzeln festgelegt werden was aber nur selten sinnvoll ist.
Kommentare
Kommentare werden durch ein Semikolon eingeleitet. Man kann dieses Kommentarzeichen mit der Raute (#) in der Shell vergleichen.
Listing 20.6 sun-Datei (noch eine Fortsetzung)
@ IN SOA eygo.sun. admin.sun. (
1 ; serial
1h ; refresh
30m ; retry
7d ; expiration
1h ) ; minimum
SOA
Als Erstes wird ein SOA-Record (Start-Of-Authority) angelegt. Über diesen werden grundlegende Eigenschaften der Zone festgelegt, die verwendet werden, um mit anderen Servern dieser Zone zu kommunizieren. Bei BIND wird dabei zunächst die DNS-Klasse festgelegt. In diesem Fall ist dies »IN«, also Internet-Klasse. Die anderen Klassen sind praktisch tot, weshalb Sie bei einigen DNS-Servern gar nicht mehr anzugeben brauchen, welche Klasse Sie verwenden möchten.
Nach dem Typ des Records (SOA) folgen zwei Hostnamen. Der erste davon gibt den Master-DNS-Server an, der zweite ist eine Mail-Adresse. Da in der Konfiguration allerdings keine @-Zeichen verwendet werden dürfen, muss »admin.sun.« als »admin@sun« gelesen werden. Innerhalb der Klammern folgen verschiedene numerische Werte:
- Die erste Zahl – die Serial Number – legt die Version der Datei fest. Damit kann geprüft werden, ob Clients bereits die aktuelle Konfigurationsversion geladen haben.
- Die zweite Zahl – die Refresh Number – gibt an, in welchen Zeitabständen Slave-Server prüfen sollen, ob sie über die aktuelle Version der Konfiguration verfügen.
- Die dritte Zahl – die Retry Number – legt fest, nach welcher Zeitspanne der Slave erneut versuchen soll, Kontakt mit dem Master aufzunehmen, falls dieser nicht antwortet (beispielsweise wegen Wartungsarbeiten oder einem Absturz).
- Die vierte Zahl – Expire – legt fest, wie lange ein Slave die Datenbestände behalten soll, bevor sie als »obsolet« gewertet und gelöscht werden sollen, wenn der Slave den Master nicht zwecks Update kontaktieren kann.
- Die fünfte Zahl legt fest, wie groß die Mindestlebenszeit (Time to Live, kurz TTL) eines Resource Records sein muss, bevor seine Aktualität überprüft werden soll.
Weitere RR-Typen
Anschließend wird mit dem RR-Typ »NS« ein Nameserver für die Domain festgelegt, der mit dem A-Record-Typ eine IPv4-Adresse bekommt und dessen lokale IPv6-Adresse ::1 ist (AAAA). Danach werden noch weitere IPv4-Records angelegt. Mit diesen wird hier im Beispiel dem Rechnernamen »milk« die IP-Adresse 192.168.0.2 zugewiesen. BIND unterstützt noch diverse weitere Typen von Resource Records wie MX, TXT oder PTR, deren Definitionen Sie im RFC 1033 [Lot87A] finden.
Listing 20.7 Weitere RR-Typen
NS eygo.sun.
A 192.168.0.1
AAAA ::1
milk A 192.168.0.2
yorick A 192.168.0.5
BIND starten
BIND wird über die Programmdatei named gestartet. Dabei werden eventuelle Probleme über den syslogd protokolliert:
Listing 20.8 named mit Fehlerdiagnose starten
# tail -f /var/log/messages&
...
...
# /usr/sbin/named
#
Jul 12 17:40:39 eygo named[19507]: starting BIND 9.3.0
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.