Sowohl Gateway als auch Hypervisor sind in dieser Konfiguration Teil des f\u00fcr VM 1 zugeteilten Netzes, was aber kein Problem darstellt, da die Adressvergabe von Hand geschieht. Die DNS-Konfiguration sieht hierzu analog aus:<\/p>\n
Hypervisor: 2001:db8:dead:beef:0000::2\/64 Master\r\nVM 1: 2001:db8:dead:beef:0000::3\/65 Slave (Master f\u00fcr sein \/65)\r\nVM 2: 2001:db8:dead:beef:8000::1\/65 Slave (Master f\u00fcr sein \/65)<\/pre>\nDa 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\u00fcnftig eingerichteten Firewall vor dem System durchaus ausreichend ist.<\/p>\n
Damit nun die DNS-Server die rDNS-Namen zu den IPv6-Adressen suchen k\u00f6nnen, sollte man sich zudem anschauen, wie das Suchen eines Hostnamens zu einer IP-Adresse funktioniert. Unterscheiden muss man hierbei die Vorgehensweise f\u00fcr IPv4 und IPv6, auch wenn das Grundprinzip in beiden F\u00e4llen \u00e4hnlich ist. Das DNS definiert einen homogenen Namensraum, in dem jegliche Bezeichner hierarchisch abgelegt werden. Zu diesen Namen k\u00f6nnen nun weitere Angaben wie Adressen, Informationen zu einem Host, darauf laufende Services oder beliebige andere Angaben eingetragen werden. Zudem besteht die M\u00f6glichkeit, Teile dieser Hierarchie an andere Stellen zu delegieren, wenn diese in einen anderen Autorit\u00e4tsbereich fallen.<\/p>\n
Da das DNS nun aber auf hierarchische Strukturen ausgelegt ist, m\u00fcssen auch eigentlich ungeordnete Daten in eine Hierarchie \u00fcberf\u00fchrt werden, wenn man nach diesen im DNS suchen m\u00f6chte. Um dies zu erreichen teilt man f\u00fcr 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\u00f6chte man also zur IPv4-Adresse 127.0.0.1 wissen, wie der zugeh\u00f6rige Rechner hei\u00dft, muss man nach 1.0.0.127.in-addr.arpa. suchen. Die Domain in-addr.arpa. ist hierbei ein speziell f\u00fcr Reverse-DNS reservierter Namensraum, der f\u00fcr 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\u00fcckgeliefert.<\/p>\n
Ganz Analog hierzu verh\u00e4lt es sich f\u00fcr IPv6. Da hier jedoch die Trennung nach Doppelpunkten recht unhandliche Zonefiles produzieren w\u00fcrde, hat man festgelegt, dass jede Hex-Ziffer einer Adresse einzeln als Teil der Hierarchie auftaucht. Den Namen des Gateways w\u00fcrde 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\u00f6nnen.<\/p>\n
Nach dem die Grundlagen f\u00fcr die Namensaufl\u00f6sung zu IP-Adressen klar sein d\u00fcrfte, 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\u00fcgen von Buchstaben an der falschen Stelle durchaus Fehler einhandeln, deren Suche l\u00e4nger 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:<\/p>\n
$ORIGIN .\r\n$TTL 43200 ; 12 hours\r\nf.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. (\r\n 1984052342 ; serial\r\n 28800 ; refresh (8 hours)\r\n 1800 ; retry (30 minutes)\r\n 2419200 ; expire (4 weeks)\r\n 10800 ; minimum (3 hours)\r\n )\r\n NS ns42.example.org.\r\n NS slave1.example.org.\r\n NS slave2.example.org.\r\n\r\n$ORIGIN f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa.\r\n0 NS slave1.example.org.\r\n1 NS slave1.example.org.\r\n2 NS slave1.example.org.\r\n3 NS slave1.example.org.\r\n4 NS slave1.example.org.\r\n5 NS slave1.example.org.\r\n6 NS slave1.example.org.\r\n7 NS slave1.example.org.\r\n8 NS slave2.example.org.\r\n9 NS slave2.example.org.\r\na NS slave2.example.org.\r\nb NS slave2.example.org.\r\nc NS slave2.example.org.\r\nd NS slave2.example.org.\r\ne NS slave2.example.org.\r\nf NS slave2.example.org.\r\n\r\n$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.\r\n1 PTR gateway.example.org.\r\n2 PTR ns42.example.org.<\/pre>\nDie SOA-Zeile legt hierbei fest, wo der Autorit\u00e4tsbereich 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\u00fcr 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\u00f6\u00dfere Seriennummer als zuvor entsteht. Statt dieser Konvention k\u00f6nnte jedoch auch einfach gez\u00e4hlt werden.<\/p>\n
In den 3 Zeilen darunter wird festgelegt, welche Nameserver autoritiv f\u00fcr diese Zone antworten d\u00fcrfen. In diesem Beispiel sind das ns42, slave1 und slave2. Hier m\u00fcssen f\u00fcr eine g\u00fcltige Delegation dieser Zone mindestens zwei Server aufgelistet werden, um die n\u00f6tige Redundanz zu sichern. Die hier angegebenen Nameserver sind rein praktisch gesehen redundant, sollten aber f\u00fcr die Korrektheit eingetragen sein, da sie die Best\u00e4tigung der vom \u00fcbergeordneten DNS-Server gelieferten Information darstellen, wo eine bestimmte Kind-Zone zu finden ist (hin delegiert wurde).<\/p>\n
Eine solche Delegation stellen die nun folgenden 16 NS-Eintr\u00e4ge dar. Diese definieren Verweise im DNS, wo Informationen zu den unterhalb dieser Knoten befindlichen Angaben zu finden sind. So w\u00fcrde, nach dem ein Resolver f\u00fcr die Adresse 2001:db8:dead:beef:c0fe:affe:1337:42 bereits zur Authority 2001:db8:dead:beef verwiesen wurde, als n\u00e4chstes das Label c suchen und daher f\u00fcr n\u00e4here Informationen bei slave2.example.org. zu dieser Adresse anfragen.<\/p>\n
Bei den letzten beiden Records in dieser Beispiel-Zone handelt es sich um sogenannte GLUE-Records. Diese k\u00f6nnen verwendet werden, um Informationen aus einer Child-Zone bereitzustellen, die f\u00fcr das Auffinden des hierf\u00fcr n\u00f6tigen Nameservers n\u00f6tig sind, oder um h\u00e4ufige Anfragen ohne Delegation durchzuf\u00fchren. M\u00f6chte ein Client beispielsweise foo.example.org. aufl\u00f6sen, wird er m\u00f6glicherweise von dem f\u00fcr .org zust\u00e4ndigen DNS-Server erfahren, dass er f\u00fcr example.org. bitte bei ns42.example.org. nachfragen soll. Da er jedoch nicht wei\u00df, wo er ns42.example.org. findet, ben\u00f6tigt er diese Angabe bereits vom f\u00fcr org. zust\u00e4ndigen Server mitgeliefert. Die in diesem Beispiel verwendeten PTR-Eintr\u00e4ge vereinfachen das Auffinden der f\u00fcr den Hypervisor reservierten Eintr\u00e4ge und erlauben dem Server so, \u00fcber sich selbst bereits Auskunft zu geben, ohne an die Unterzone die auf slave1.example.org. gehostet w\u00e4re, verweisen zu m\u00fcssen.<\/p>\n
Nachdem nun der Inhalt f\u00fcr 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:<\/p>\n
zone \"f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa\" {\r\n type master;\r\n file \"\/etc\/bind\/master\/db.arpa.ip6.2.0.0.1.0.d.b.8.d.e.a.d.b.e.e.f\";\r\n allow-transfer {\r\n 127.0.0.2; 127.0.0.3;\r\n };\r\n also-notify {\r\n 127.0.0.2; 127.0.0.3;\r\n };\r\n};<\/pre>\nWobei 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 \u00c4nderung \u00fcber die aktualisierte Zonefile informiert werden.<\/p>\n
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\u00fcfen kann. Die Konfiguration der Zone in den Slave-Servern erfolgt analog dem Master:<\/p>\n
zone \"f.e.e.b.d.a.e.d.8.b.d.0.1.0.0.2.ip6.arpa\" {\r\n type slave;\r\n file \"\/etc\/bind\/slave\/db.arpa.ip6.2.0.0.1.0.d.b.8.d.e.a.d.b.e.e.f\";\r\n allow-transfer {\r\n 127.0.0.1; 127.0.0.3;\r\n };\r\n also-notify {\r\n 127.0.0.1; 127.0.0.3;\r\n };\r\n};<\/pre>\nHierbei gilt es, dass jeder Slave mindestens dem Master erlaubt einen Zonen-Transfer durchzuf\u00fchren, besser ist es jedoch, allen autoritiven Servern untereinander Notify- und Zonentransfer-Rechte zu geben, um Komplikationen zu vermeiden.<\/p>\n
Zu guter Letzt m\u00fcssen 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\u00e4llen konsistent w\u00e4ren, da ein Zonetransfer f\u00fcr gr\u00f6\u00dfere Zonen durchaus mehrere Minuten ben\u00f6tigen kann.<\/p>\n
Ob alles beim Starten der DNS-Server funktioniert hat, sieht man anschlie\u00dfend in den Logfiles von Bind. Hier sollte von jedem Server ein Notify auftauchen. Wenn man zudem mit reduzierten Serials bei den Slave-Zonen f\u00fcr die Initialisierung gearbeitet hat, sollte zudem mindestens ein erfolgreicher Zonetransfer vermerkt worden sein.<\/p>\n
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\u00fcfen, ob alle FQDNs (Full Qualified Domain Names) mit einem Punkt abgeschlossen wurden. Ohne diesen Abschlie\u00dfenden Punkt gelten Domainnamen f\u00fcr 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<\/a> \ud83d\ude09<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"