Zonendateien

Zwei Arten von Zonendateien sind erforderlich. Eine Art ordnet IP-Adressen Hostnamen zu, die andere stellt Hostnamen für IP-Adressen bereit.

[Tip]Verwenden des Punktes in Zonendateien

Die . hat eine wichtige Bedeutung in den Zonendateien. Wenn Hostnamen ohne . am Ende angegeben werden, wird die Zone angefügt. Vollständige Hostnamen, die mit einem vollständigen Domänennamen angegeben werden, müssen mit . abgeschlossen werden, um zu verhindern, dass die Domäne ein weiteres Mal angefügt wird. Ein fehlender oder falsch platzierter Punkt ist wahrscheinlich die häufigste Ursache von Fehlern bei der Namenserverkonfiguration.

Der erste zu betrachtende Fall ist die Zonendatei world.zone, die für die Domäne world.cosmos zuständig ist (siehe Beispiel 33.6, „Datei /var/lib/named/world.zone“).

Beispiel 33.6. Datei /var/lib/named/world.zone

$TTL 2D
world.cosmos. IN SOA      gateway  root.world.cosmos. (
            2003072441  ; serial
            1D          ; refresh
            2H          ; retry
            1W          ; expiry
            2D )        ; minimum

            IN NS       gateway
            IN MX       10 sun

gateway     IN A        192.168.0.1
            IN A        192.168.1.1
sun         IN A        192.168.0.2
moon        IN A        192.168.0.3
earth       IN A        192.168.1.2
mars        IN A        192.168.1.3
www         IN CNAME    moon

Zeile 1:

$TTL legt die Standardlebensdauer fest, die für alle Einträge in dieser Datei gelten soll. In diesem Beispiel sind die Einträge zwei Tage lang gültig (2 D).

Zeile 2:

Hier beginnt der SOA (Start of Authority)-Steuereintrag:

  • Der Name der zu verwaltenden Datei ist world.cosmos an der ersten Stelle. Dieser Eintrag endet mit ., da anderenfalls die Zone ein zweites Mal angefügt würde. Alternativ kann hier @ eingegeben werden. In diesem Fall wird die Zone aus dem entsprechenden Eintrag in /etc/named.conf extrahiert.

  • Nach IN SOA befindet sich der Name des Namenservers, der als Master für diese Zone fungiert. Der Name wird von gateway zu gateway.world.cosmos erweitert, da er nicht mit . endet.

  • Es folgt die E-Mail-Adresse der für diesen Namenserver zuständigen Person. Da das Zeichen @ bereits eine besondere Bedeutung hat, wird hier stattdessen . eingegeben. Statt root@world.cosmos muss der Eintrag root.world.cosmos. lauten. Der Punkt . muss angehängt werden, damit die Zone nicht hinzugefügt wird.

  • Durch ( werden alle Zeilen bis einschließlich ) in den SOA-Eintrag aufgenommen.

Zeile 3:

Die Seriennummer (serial) ist eine beliebige Nummer, die sich bei jeder Änderung der Datei erhöht. Sie wird benötigt, um die sekundären Namenserver (Slave-Server) über Änderungen zu informieren. Hierfür hat sich eine 10-stellige Nummer aus Datum und Ausführungsnummer in der Form JJJJMMMTTNN als übliches Format etabliert.

Zeile 4:

Die Aktualisierungsrate (refresh rate) gibt das Zeitintervall an, in dem die sekundären Namenserver die Seriennummer (serial) der Zone überprüfen. In diesem Fall beträgt dieses Intervall einen Tag.

Zeile 5:

Die Wiederholungsrate (retry) gibt das Zeitintervall an, nach dem ein sekundärer Namenserver bei einem Fehler erneut versucht, Kontakt zum primären Server herzustellen. In diesem Fall sind dies zwei Stunden.

Zeile 6:

Die Ablaufzeit (expiry) gibt den Zeitraum an, nach dem ein sekundärer Server die im Cache gespeicherten Daten verwirft, wenn er keinen erneuten Kontakt zum primären Server herstellen konnte. In diesem Fall ist dies eine Woche.

Zeile 7:

Die letzte Angabe im SOA-Eintrag gibt die negative Cache-Lebensdauer (negative caching TTL) an. Sie legt fest, wie lange Ergebnisse nicht aufgelöster DNS-Abfragen anderer Server im Cache gespeichert werden können.

Zeile 9:

IN NS gibt den für diese Domäne verantwortlichen Namenserver an. gateway wird zu gateway.world.cosmos erweitert, da es nicht auf . endet. Es können mehrere solcher Zeilen vorhanden sein - eine für den primären und eine für die einzelnen sekundären Namenserver. Wenn notify in /etc/named.conf nicht auf no gesetzt ist, werden alle hier aufgeführten Namenserver über die Änderungen an den Zonendaten informiert.

Zeile 10:

Der MX-Eintrag gibt den Mailserver an, der E-Mails für die Domäne world.cosmos annimmt, verarbeitet und weiterleitet. In diesem Beispiel ist dies der Host sun.world.cosmos. Die Zahl vor dem Hostnamen ist der Präferenzwert. Wenn mehrere MX-Einträge vorhanden sind, wird zunächst der Mailserver mit dem kleinsten Wert verwendet. Wenn die Mailzustellung an diesen Server nicht möglich ist, wird ein Versuch mit dem nächsthöheren Wert unternommen.

Zeilen 12 – 17:

Dies sind die eigentlichen Adresseinträge, in denen den Hostnamen eine oder mehrere IP-Adressen zugewiesen werden. Die Namen werden hier ohne . endet, da sie nicht ihre Domäne beinhalten; daher wird world.cosmus zu allen hinzugefügt. Dem Host-Gateway (gateway) werden zwei IP-Adressen zugewiesen, weil er zwei Netzwerkkarten aufweist. Bei allen traditionellen Hostadressen (IPv4) wird der Eintrag mit AAAA gekennzeichnet. Wenn es sich um eine IPv6-Adresse handelt, wird der Eintrag mit AAAA 0 gekennzeichnet. Das frühere Token für IPv6-Adressen war AAAA. Es ist inzwischen veraltet.

[Note]IPv6-Syntax

Die Syntax des IPv6-Eintrags unterscheidet sich geringfügig von der Syntax von IPv4. Aufgrund der Möglichkeit einer Fragmentierung müssen Informationen zu fehlenden Bits vor der Adresse angegeben werden. Sie müssen diese Informationen angeben, selbst wenn Sie vorhaben, eine völlig unfragmentierte Adresse zu verwenden. Für den IPv4-Eintrag mit der Syntax

 pluto IN            AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
 pluto IN            AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0

müssen Sie Informationen über fehlende Bits im IPv6-Format hinzufügen. Da das obige Beispiel vollständig ist (es fehlen keine Bits), lautet das IPv6-Format des Eintrags:

 pluto  IN            AAAA 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
 pluto  IN            AAAA 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0

Verwenden Sie keine IPv4-Adressen mit IPv6-Zuordnung.

Zeile 18:

Der Alias www kann zur Adressierung von mond (CNAME steht für canonical name (kanonischer Name)) verwendet werden.

Die Pseudodomäne in-addr.arpa wird für Reverse-Lookups zur Auflösung von IP-Adressen in Hostnamen verwendet. Sie wird in umgekehrter Notation an den Netzwerk-Teil der Adresse angehängt. 192.168.1 wird also in 1.168.192.in-addr.arpa aufgelöst. Weitere Informationen hierzu finden Sie unter Beispiel 33.7, „Reverse-Lookup“.

Beispiel 33.7. Reverse-Lookup

    


$TTL 2D
1.168.192.in-addr.arpa. IN SOA gateway.world.cosmos. root.world.cosmos. (
                        2003072441      ; serial
                        1D              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

                        IN NS           gateway.world.cosmos.

1                       IN PTR          gateway.world.cosmos.
2                       IN PTR          earth.world.cosmos.
3                       IN PTR          mars.world.cosmos.

Zeile 1:

$TTL definiert die Standard-TTL, die für alle Einträge hier gilt.

Zeile 2:

Die Konfigurationsdatei muss Reverse-Lookup für das Netzwerk 192.168.1.0 aktivieren. Angenommen, die Zone heißt 1.168.192.in-addr.arpa, sollte sie nicht zu den Hostnamen hinzugefügt werden. Daher werden alle Hostnamen in ihrer vollständigen Form eingegeben, d. h. mit der Domäne und einem abschließenden Punkt (.). Die restlichen Einträge entsprechen den im vorherigen Beispiel (world.cosmos) beschriebenen Einträgen.

Zeilen 3 – ;7:

Siehe vorheriges Beispiel für world.cosmos.

Zeile 9:

Diese Zeile gibt wieder den für diese Zone verantwortlichen Namenserver an. Diesmal wird der Name allerdings in vollständiger Form mit Domäne und . am Ende eingegeben.

Zeilen 11 – ;13:

Dies sind die Zeigereinträge, die auf die IP-Adressen auf den entsprechenden Hosts verweisen. Am Anfang der Zeile wird nur der letzte Teil der IP-Adresse eingegeben, ohne . am Ende. Wenn daran die Zone angehängt wird (ohne .in-addr.arpa), ergibt sich die vollständige IP-Adresse in umgekehrter Reihenfolge.

Normalerweise sollten Zonentransfers zwischen verschiedenen Versionen von BIND problemlos möglich sein.