Wieder ist ein neues Projekt abgeschlossen und funktioniert vorerst soweit wie es benötigt wird. Hintergrund des Projektes war es, für das IPv6-Subnetz des Servers die rDNS-Namensauflösung (Reverse DNS) zu konfigurieren. Vom Anbieter wurde hierfür zwar ein „Web-Interface“ bereitgestellt, was aber dazu geführt hätte, dass jede IPv6 einzeln einzutragen gewesen wäre – schön ist irgendwie anders.
Nun ist das Einrichten einer IPv6-rDNS-Zone zwar an sich kein großes Thema, da dies wie jede andere Zone sonst auch in Bind (oder jeden anderen DNS-Server seiner Wahl) eingetragen werden kann; kompliziert wird es aber, wenn man eine öffentlich im Internet erreichbare Zone offiziell deligiert bekommt, da man in diesem Fall eine Reihe von Voraussetzungen erfüllen muss. Die erste Voraussetzung ist, dass man mindestens 2 DNS-Server besitzt, was gleich auch zur ersten Herausforderung führt: nämlich, dass diese ständig mit einem synchronisierten Datenstand arbeiten. Zweitens müssen beide Server autoritiv auf gestellte Anfragen innerhalb ihrer Zone antworten, was sich aber aus einer erfolgreichen Konfiguration des ersten Punktes ergibt.
Nun ist alle Theorie grau. Daher hier eine kurze Information zum geplanten System:
Gateway: 2001:db8:dead:beef:0000::1/64
Hypervisor: 2001:db8:dead:beef:0000::2/64
VM 1: 2001:db8:dead:beef:0000::3/65
VM 2: 2001:db8:dead:beef:8000::1/65
Sowohl Gateway als auch Hypervisor sind in dieser Konfiguration Teil des für VM 1 zugeteilten Netzes, was aber kein Problem darstellt, da die Adressvergabe von Hand geschieht. Die DNS-Konfiguration sieht hierzu analog aus:
Hypervisor: 2001:db8:dead:beef:0000::2/64 Master
VM 1: 2001:db8:dead:beef:0000::3/65 Slave (Master für sein /65)
VM 2: 2001:db8:dead:beef:8000::1/65 Slave (Master für sein /65)
Da alle drei Systeme physikalisch auf dem gleichen Host liegen (was aus Sicht der Ausfallsicherheit vermieden werden sollte, in diesem Fall aber nicht anders ging), wird hier zudem auf die Einrichtung von DNSSEC an dieser Stelle verzichtet. Stattdessen erfolgt die Authentifizierung in der in diesem Beispiel gezeigte Konfiguration anhand der IP-Adresse, was bei einer vernünftig eingerichteten Firewall vor dem System durchaus ausreichend ist.
Damit nun die DNS-Server die rDNS-Namen zu den IPv6-Adressen suchen können, sollte man sich zudem anschauen, wie das Suchen eines Hostnamens zu einer IP-Adresse funktioniert. Unterscheiden muss man hierbei die Vorgehensweise für IPv4 und IPv6, auch wenn das Grundprinzip in beiden Fällen ähnlich ist. Das DNS definiert einen homogenen Namensraum, in dem jegliche Bezeichner hierarchisch abgelegt werden. Zu diesen Namen können nun weitere Angaben wie Adressen, Informationen zu einem Host, darauf laufende Services oder beliebige andere Angaben eingetragen werden. Zudem besteht die Möglichkeit, Teile dieser Hierarchie an andere Stellen zu delegieren, wenn diese in einen anderen Autoritätsbereich fallen.
Da das DNS nun aber auf hierarchische Strukturen ausgelegt ist, müssen auch eigentlich ungeordnete Daten in eine Hierarchie überführt werden, wenn man nach diesen im DNS suchen möchte. Um dies zu erreichen teilt man für das Nachschlagen des Hostnamens zu einer IP-Adresse diese in ihre Bestandteile auf. Bei IPv4 sind diese Bestandteile die einzelnen Oktets, wobei man im nachgeschlagenen Namen die Reihenfolge der Einzelteile zugunsten der Hierarchie vertauscht. Möchte man also zur IPv4-Adresse 127.0.0.1 wissen, wie der zugehörige Rechner heißt, muss man nach 1.0.0.127.in-addr.arpa. suchen. Die Domain in-addr.arpa. ist hierbei ein speziell für Reverse-DNS reservierter Namensraum, der für das Nachschlagen von IPv4-Adressen verwendet wird. Wird zu dieser angefragten Adresse ein Hostname (oder mehrere) gefunden, so werden diese als PTR-Records vom angefragten DNS-Server zurückgeliefert.
Ganz Analog hierzu verhält es sich für IPv6. Da hier jedoch die Trennung nach Doppelpunkten recht unhandliche Zonefiles produzieren würde, hat man festgelegt, dass jede Hex-Ziffer einer Adresse einzeln als Teil der Hierarchie auftaucht. Den Namen des Gateways würde man daher unter 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.d.a.e.d.1.0.0.2.ip6.arpa. finden. Auch bei ip6.arpa. handelt es sich um einen reservierten Namensraum, in dem alle IPv6-Adressen eingehangen werden können.
Nach dem die Grundlagen für die Namensauflösung zu IP-Adressen klar sein dürfte, soll es im Folgenden darum gehen, wie man seinen Master zum Bedienen einer solchen rDNS-Zone bringt. Auch wenn dies zu 100% mit normalen Domains identisch ist, kann man sich durch hinzufügen von Buchstaben an der falschen Stelle durchaus Fehler einhandeln, deren Suche länger dauern kann (z.B. wenn man ipv6.arpa statt ip6.arpa beim Benennen der Zone schreibt – richtig ist die Variante OHNE v ;-)). Aber werfen wir einen Blick auf eine einfache Zone-File:
$ORIGIN .
$TTL 43200 ; 12 hours
f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa IN SOA ns42.example.org. hostmaster.example.org. (
1984052342 ; serial
28800 ; refresh (8 hours)
1800 ; retry (30 minutes)
2419200 ; expire (4 weeks)
10800 ; minimum (3 hours)
)
NS ns42.example.org.
NS slave1.example.org.
NS slave2.example.org.
$ORIGIN f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa.
0 NS slave1.example.org.
1 NS slave1.example.org.
2 NS slave1.example.org.
3 NS slave1.example.org.
4 NS slave1.example.org.
5 NS slave1.example.org.
6 NS slave1.example.org.
7 NS slave1.example.org.
8 NS slave2.example.org.
9 NS slave2.example.org.
a NS slave2.example.org.
b NS slave2.example.org.
c NS slave2.example.org.
d NS slave2.example.org.
e NS slave2.example.org.
f NS slave2.example.org.
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa.
1 PTR gateway.example.org.
2 PTR ns42.example.org.
Die SOA-Zeile legt hierbei fest, wo der Autoritätsbereich beginnt (in diesem Fall bei f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa. mit dem Nameserver ns42.example.org. und dem Verantwortlichen hostmaster@example.org. Zudem wird festgelegt, wie die Timeouts für diese Zone zu handhaben sind. Die Seriennummer ist hierbei eine Ganzzahl, die die Version dieser Zonendatei angibt. Per Konvention wird hier oft das Format YYYYMMDDNN verwendet, so dass beim Aktualisieren der Zone immer eine größere Seriennummer als zuvor entsteht. Statt dieser Konvention könnte jedoch auch einfach gezählt werden.
In den 3 Zeilen darunter wird festgelegt, welche Nameserver autoritiv für diese Zone antworten dürfen. In diesem Beispiel sind das ns42, slave1 und slave2. Hier müssen für eine gültige Delegation dieser Zone mindestens zwei Server aufgelistet werden, um die nötige Redundanz zu sichern. Die hier angegebenen Nameserver sind rein praktisch gesehen redundant, sollten aber für die Korrektheit eingetragen sein, da sie die Bestätigung der vom übergeordneten DNS-Server gelieferten Information darstellen, wo eine bestimmte Kind-Zone zu finden ist (hin delegiert wurde).
Eine solche Delegation stellen die nun folgenden 16 NS-Einträge dar. Diese definieren Verweise im DNS, wo Informationen zu den unterhalb dieser Knoten befindlichen Angaben zu finden sind. So würde, nach dem ein Resolver für die Adresse 2001:db8:dead:beef:c0fe:affe:1337:42 bereits zur Authority 2001:db8:dead:beef verwiesen wurde, als nächstes das Label c suchen und daher für nähere Informationen bei slave2.example.org. zu dieser Adresse anfragen.
Bei den letzten beiden Records in dieser Beispiel-Zone handelt es sich um sogenannte GLUE-Records. Diese können verwendet werden, um Informationen aus einer Child-Zone bereitzustellen, die für das Auffinden des hierfür nötigen Nameservers nötig sind, oder um häufige Anfragen ohne Delegation durchzuführen. Möchte ein Client beispielsweise foo.example.org. auflösen, wird er möglicherweise von dem für .org zuständigen DNS-Server erfahren, dass er für example.org. bitte bei ns42.example.org. nachfragen soll. Da er jedoch nicht weiß, wo er ns42.example.org. findet, benötigt er diese Angabe bereits vom für org. zuständigen Server mitgeliefert. Die in diesem Beispiel verwendeten PTR-Einträge vereinfachen das Auffinden der für den Hypervisor reservierten Einträge und erlauben dem Server so, über sich selbst bereits Auskunft zu geben, ohne an die Unterzone die auf slave1.example.org. gehostet wäre, verweisen zu müssen.
Nachdem nun der Inhalt für die Zone von unseren Master bekannt ist, muss diese in der Konfiguration bekannt gemacht werden. Hierzu muss diese z.B. in der named.conf.local eingetragen werden:
zone "f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa" {
type master;
file "/etc/bind/master/db.arpa.ip6.2.0.0.1.0.d.b.8.d.e.a.d.b.e.e.f";
allow-transfer {
127.0.0.2; 127.0.0.3;
};
also-notify {
127.0.0.2; 127.0.0.3;
};
};
Wobei 127.0.0.2 und 127.0.0.3 die IPs von slave1 und slave2 sind. Die Einstellung allow-transfer legt fest, von welcher IP aus die Zone via Zone-Transfer abgefragt werden darf. Bei also-notify wird konfiguriert, welche Nameserver im Falle einer Änderung über die aktualisierte Zonefile informiert werden.
Ferner muss die Zone bei allen Slave-Servern als solche eingetragen werden. Es empfiehlt sich, eine leere, auf ein SEHR kleines Serial gestellte Zone auf beiden Slaves anzulegen, oder die aktuelle Kopie des Masters auch auf den Slave-Servern anzulegen. Ersteres Vorgehen hat jedoch den Vorteil, dass man beim ersten Start des Nameservers das korrekte Funktionieren des Zone-Transfers prüfen kann. Die Konfiguration der Zone in den Slave-Servern erfolgt analog dem Master:
zone "f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa" {
type slave;
file "/etc/bind/slave/db.arpa.ip6.2.0.0.1.0.d.b.8.d.e.a.d.b.e.e.f";
allow-transfer {
127.0.0.1; 127.0.0.3;
};
also-notify {
127.0.0.1; 127.0.0.3;
};
};
Hierbei gilt es, dass jeder Slave mindestens dem Master erlaubt einen Zonen-Transfer durchzuführen, besser ist es jedoch, allen autoritiven Servern untereinander Notify- und Zonentransfer-Rechte zu geben, um Komplikationen zu vermeiden.
Zu guter Letzt müssen noch die Nameserver gestartet werden. Als Reihenfolge empfiehlt sich, zuerst den Master gefolgt von den beiden Slaves zu starten. Da aber alle Server autoritiv antworten ist dies im Wesentlichen eine Frage, ob die ausgelieferten Daten in allen Fällen konsistent wären, da ein Zonetransfer für größere Zonen durchaus mehrere Minuten benötigen kann.
Ob alles beim Starten der DNS-Server funktioniert hat, sieht man anschließend in den Logfiles von Bind. Hier sollte von jedem Server ein Notify auftauchen. Wenn man zudem mit reduzierten Serials bei den Slave-Zonen für die Initialisierung gearbeitet hat, sollte zudem mindestens ein erfolgreicher Zonetransfer vermerkt worden sein.
Sollte es trotz erfolgreichem Zonetransfer bei einigen Hosts zu seltsamen Domainnamen kommen, etwa wenn der Domainname doppelt auftaucht („host.example.org.example.org“), sollte man noch einmal prüfen, ob alle FQDNs (Full Qualified Domain Names) mit einem Punkt abgeschlossen wurden. Ohne diesen Abschließenden Punkt gelten Domainnamen für Bind als Relative Angaben bzgl. der via $ORIGIN angegebenen Domain. Man befindet sich dann aber in guter Gesellschaft: Die Schweden haben auf diese Weise schon einmal eine gesamte Top-Level-Domain lahmgelegt 😉
