Introduction

DNS, oder das Domain Name System, ist oft eine schwierige Komponente, wenn man lernt, wie man Websites und Server konfiguriert. Während die meisten Leute wahrscheinlich die DNS-Server verwenden, die von ihrer Hosting-Firma oder ihrem Domain-Registrar zur Verfügung gestellt werden, gibt es einige Vorteile, wenn man seine eigenen DNS-Server erstellt.

In dieser Anleitung werden wir besprechen, wie man den Bind9 DNS-Server als autoritativen DNS-Server auf Ubuntu 14.04-Maschinen installiert und konfiguriert. Wir werden diese zwei Bind-Server für unsere Domäne in einer primär-sekundären Konfiguration einrichten.

Voraussetzungen und Ziele

Um diese Anleitung zu vervollständigen, müssen Sie zunächst mit einigen gängigen DNS-Begriffen vertraut sein. Lesen Sie diesen Leitfaden, um mehr über die Konzepte zu erfahren, die wir in diesem Leitfaden implementieren werden.

Sie benötigen außerdem mindestens zwei Server. Einer wird der „primäre“ DNS-Server sein, von dem die Zonendateien für unsere Domäne stammen, und einer wird der „sekundäre“ Server sein, der die Zonendaten durch Übertragungen erhält und verfügbar ist, falls der andere Server ausfällt. Dadurch wird die Gefahr eines Single Point of Failure für Ihre DNS-Server vermieden.

Im Gegensatz zu DNS-Servern mit Caching oder Weiterleitung oder einem Mehrzweck-DNS-Server antworten autoritative Server nur auf iterative Anfragen für die Zonen, für die sie autoritativ sind. Das heißt, wenn der Server die Antwort nicht kennt, teilt er dem Client (in der Regel ein auflösender DNS-Server) mit, dass er die Antwort nicht kennt, und verweist auf einen Server, der vielleicht mehr weiß.

Autoritative-only DNS-Server sind oft eine gute Konfiguration für hohe Leistung, da sie nicht den Overhead haben, rekursive Anfragen von Clients aufzulösen. Sie kümmern sich nur um die Zonen, für die sie bestimmt sind.

Für die Zwecke dieses Leitfadens werden wir uns auf drei Server beziehen. Die beiden oben erwähnten Nameserver sowie einen Webserver, den wir als Host in unserer Zone konfigurieren wollen.

Für diese Anleitung verwenden wir die Dummy-Domain example.com. Sie sollten sie durch die von Ihnen konfigurierte Domäne ersetzen. Dies sind die Details der Maschinen, die wir konfigurieren werden:

Zweck	DNS FQDN	IP-Adresse
Primärer Namensserver	ns1.Beispiel.com.	192.0.2.1
Sekundärer Nameserver	ns2.example.com.	192.0.2.2
Web Server	www.example.com.	192.0.2.3

Nach Beendigung dieser Anleitung sollten Sie zwei autoritative Nameserver für Ihre Domainzonen konfiguriert haben. Die Namen in der mittleren Spalte der obigen Tabelle können verwendet werden, um Ihre verschiedenen Hosts zu erreichen. Mit dieser Konfiguration ist ein rekursiver DNS-Server in der Lage, Daten über die Domäne an Clients zurückzugeben.

Einstellen des Hostnamens auf den Nameservern

Bevor wir mit der Konfiguration unserer Nameserver beginnen, müssen wir sicherstellen, dass unser Hostname sowohl auf unserem primären als auch auf unserem sekundären DNS-Server richtig konfiguriert ist.

beginnen Sie mit der Untersuchung der Datei /etc/hosts. Öffnen Sie die Datei mit sudo-Rechten in Ihrem Texteditor:

sudo nano /etc/hosts

Wir müssen diese Datei so konfigurieren, dass sie den Hostnamen und FQDN jedes Servers korrekt identifiziert. Für den primären Nameserver wird die Datei anfangs etwa so aussehen:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Wir sollten die zweite Zeile so ändern, dass sie auf unsere spezifische Host- und Domänenkombination verweist und diese auf unsere öffentliche, statische IP-Adresse zeigt. Dann können wir den unqualifizierten Namen als Alias am Ende hinzufügen. Für den primären Server in diesem Beispiel würden Sie die zweite Zeile wie folgt ändern:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Speichern Sie die Datei und schließen Sie sie, wenn Sie fertig sind.

Wir sollten auch die Datei /etc/hostname so ändern, dass sie unseren unqualifizierten Hostnamen enthält:

sudo nano /etc/hostname

ns1

Wir können diesen Wert dann in das derzeit laufende System einlesen, indem wir Folgendes eingeben:

sudo hostname -F /etc/hostname

Wir möchten das gleiche Verfahren auf unserem sekundären Server durchführen.

Beginnen Sie mit der Datei /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Ändern Sie dann die Datei /etc/hostname. Denken Sie daran, nur den tatsächlichen Host (in unserem Beispiel ns2) für diese Datei zu verwenden:

sudo nano /etc/hostname

ns2

Lesen Sie erneut die Datei, um das aktuelle System zu ändern:

sudo hostname -F /etc/hostname

Die Host-Definitionen Ihrer Server sollten nun korrekt eingestellt sein.

Installieren Sie Bind auf beiden Nameservern

Auf jedem Ihrer Nameserver können Sie nun Bind installieren, den DNS-Server, den wir verwenden werden.

Die Bind-Software ist in den Standard-Repositories von Ubuntu verfügbar, wir müssen also nur unseren lokalen Paketindex aktualisieren und die Software mit apt installieren. Wir werden auch die Dokumentation und einige allgemeine Dienstprogramme einbeziehen:

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Führen Sie diesen Installationsbefehl auf Ihrem primären und sekundären DNS-Server aus, um die entsprechenden Dateien zu erhalten.

Konfigurieren Sie den primären Bind-Server

Nachdem wir nun die Software installiert haben, können wir damit beginnen, unseren DNS-Server auf dem primären Server zu konfigurieren.

Konfigurieren Sie die Optionsdatei

Das erste, was wir konfigurieren werden, um loszulegen, ist die named.conf.options-Datei.

Der Bind-DNS-Server ist auch bekannt als named. Die Hauptkonfigurationsdatei befindet sich unter /etc/bind/named.conf. Diese Datei ruft die anderen Dateien auf, die wir tatsächlich konfigurieren werden.

Öffnen Sie die Optionsdatei mit sudo-Rechten in Ihrem Editor:

sudo nano /etc/bind/named.conf.options

Unten wurden die meisten kommentierten Zeilen der Kürze halber entfernt, aber im Allgemeinen sollte die Datei nach der Installation so aussehen:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Das Wichtigste, was wir in dieser Datei konfigurieren müssen, ist die Rekursion. Da wir versuchen, einen reinen Autoritätsserver einzurichten, wollen wir die Rekursion auf diesem Server nicht aktivieren. Wir können dies im options-Block deaktivieren.

Wir werden auch standardmäßig keine Übertragungen zulassen. Wir werden dies später in individuellen Zonenspezifikationen überschreiben:

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Wenn Sie fertig sind, speichern und schließen Sie die Datei.

Konfiguration der lokalen Datei

Der nächste Schritt, den wir machen müssen, ist die Angabe der Zonen, die wir für diesen Server kontrollieren wollen. Eine Zone ist jeder Teil der Domäne, der zur Verwaltung an einen Nameserver delegiert wird und nicht an andere Server unterdelegiert wurde.

Wir konfigurieren die Domäne example.com und werden die Verantwortung für keinen Teil der Domäne an andere Server unterdelegieren. Die Zone wird also unsere gesamte Domain abdecken.

Um unsere Zonen zu konfigurieren, müssen wir die Datei /etc/bind/named.conf.local mit sudo-Rechten öffnen:

sudo nano /etc/bind/named.conf.local

Diese Datei wird zunächst leer sein, abgesehen von Kommentaren. Es gibt andere Zonen, die unser Server für die allgemeine Verwaltung kennt, aber diese werden in der Datei named.conf.default-zones angegeben.

Zunächst müssen wir die Weiterleitungszone für unsere example.com-Domäne konfigurieren. Forward-Zonen sind die konventionelle Name-zu-IP-Auflösung, an die die meisten von uns denken, wenn wir über DNS sprechen. Wir erstellen einen Konfigurationsblock, der die Domain-Zone definiert, die wir konfigurieren möchten:

zone "example.com" {};

Hinweis: Viele DNS-Tools, ihre Konfigurationsdateien und Dokumentationen verwenden die Begriffe „Master“ und „Slave“, während DigitalOcean im Allgemeinen alternative Bezeichnungen bevorzugt. Um Verwirrung zu vermeiden, haben wir uns entschieden, die Begriffe „primär“ und „sekundär“ zu verwenden, um die Beziehungen zwischen den Servern zu bezeichnen, und „Master“ oder „Slave“ nur dann zu verwenden, wenn eine Konfigurationsrichtlinie dies erfordert.

In diesem Block fügen wir die Verwaltungsinformationen zu dieser Zone hinzu. Wir geben die Beziehung dieses DNS-Servers zu der Zone an. In der folgenden Beispielzone ist dies type master;, da wir diesen Rechner als primären Nameserver für alle unsere Zonen konfigurieren. Außerdem verweisen wir Bind auf die Datei, die die eigentlichen Ressourcendatensätze enthält, die die Zone definieren.

Wir werden unsere primären Zonendateien in einem Unterverzeichnis namens zones innerhalb des Bind-Konfigurationsverzeichnisses speichern. Wir werden unsere Datei db.example.com nennen, um die Konvention der anderen Zonendateien im Bind-Verzeichnis zu übernehmen. Unser Block sieht nun wie folgt aus:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com";};

Wenn wir zulassen wollen, dass diese Zone auf unseren sekundären Server übertragen wird, müssen wir eine Zeile wie diese hinzufügen:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

Als Nächstes werden wir die Reverse-Zone für unsere Domain definieren.

Ein wenig über Reverse Zones

Wenn die Organisation, die Ihnen Ihre IP-Adressen zur Verfügung gestellt hat, Ihnen keinen Netzwerkbereich zugewiesen hat und die Verantwortung für diesen Bereich an Sie delegiert hat, dann wird Ihre Reverse-Zone-Datei nicht referenziert und wird von der Organisation selbst gehandhabt.

Bei Hosting-Providern wird das Reverse-Mapping in der Regel von der Firma selbst übernommen. Bei DigitalOcean zum Beispiel werden Reverse-Mappings für Ihre Server automatisch erstellt, wenn Sie den FQDN des Rechners als Servernamen im Kontrollpanel verwenden. Die Reverse-Mappings für dieses Tutorial könnten beispielsweise so erstellt werden, dass die Server wie folgt benannt werden:

In solchen Fällen sollten Sie diese Strategie anwenden, da Ihnen keine zu verwaltenden Adressen zugewiesen wurden. Die nachfolgend beschriebene Strategie wird nur der Vollständigkeit halber erwähnt und ist auch dann anwendbar, wenn Ihnen die Kontrolle über größere Gruppen zusammenhängender Adressen übertragen wurde.

Umgekehrte Zonen werden verwendet, um eine IP-Adresse mit einem Domänennamen zu verbinden. Das Domänennamensystem wurde jedoch ursprünglich für Vorwärtszuordnungen konzipiert, so dass man sich Gedanken machen muss, um es für Rückwärtszuordnungen anzupassen.

Die Informationen, die man im Kopf behalten muss, um Rückwärtszuordnungen zu verstehen, sind:

• Bei einer Domäne befindet sich der spezifischste Teil der Adresse auf der linken Seite. Bei einer IP-Adresse steht der spezifischste Teil auf der rechten Seite.
• Der spezifischste Teil einer Domänenangabe ist entweder eine Subdomäne oder ein Hostname. Dieser wird in der Zonendatei für die Domain definiert.
• Jede Subdomain kann wiederum weitere Subdomains oder Hosts definieren.

Alle Reverse-Zone-Zuordnungen werden unter der speziellen Domain in-addr.arpa definiert, die von der Internet Assigned Numbers Authority (IANA) kontrolliert wird. Unter dieser Domäne gibt es einen Baum, der Subdomänen verwendet, um jedes der Oktette in einer IP-Adresse zuzuordnen. Um sicherzustellen, dass die Spezifität der IP-Adressen diejenige normaler Domänen widerspiegelt, werden die Oktette der IP-Adressen umgedreht.

Unser primärer DNS-Server mit der IP-Adresse 192.0.2.1 würde also umgedreht als 1.2.0.192 gelesen werden. Wenn wir diese Host-Spezifikation als Hierarchie unter der Domäne in-addr.arpa hinzufügen, kann der spezifische Host als 1.2.0.192.in-addr.arpa referenziert werden.

Da wir bei der Verwendung von DNS einzelne Hosts (wie hier die führende „1“) in der Zonendatei selbst definieren, wäre die Zone, die wir konfigurieren, 2.0.192.in-addr.arpa. Wenn unser Netzbetreiber uns einen /24-Adressblock, z. B. 192.0.2.0/24, zur Verfügung gestellt hat, würde er diesen in-addr.arpa-Teil an uns delegieren.

Nachdem Sie nun wissen, wie Sie den Namen der Reverse-Zone angeben, ist die eigentliche Definition genau dieselbe wie die der Forward-Zone. Unterhalb der example.com-Zonendefinition erstellen Sie eine Reverse-Zone für das Ihnen zugewiesene Netzwerk. Auch dies ist wahrscheinlich nur notwendig, wenn Ihnen die Kontrolle über einen Adressblock übertragen wurde:

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

Wir haben uns entschieden, die Datei db.192.0.2 zu nennen. Dieser Name gibt genau an, was die Zone konfiguriert und ist besser lesbar als die umgekehrte Schreibweise.

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Erstellen Sie die Vorwärtszonendatei

Wir haben Bind jetzt über unsere Vorwärts- und Rückwärtszonen informiert, aber wir haben noch nicht die Dateien erstellt, die diese Zonen definieren werden.

Wenn Sie sich erinnern, haben wir die Dateispeicherorte als in einem Unterverzeichnis namens zones angegeben. Wir müssen dieses Verzeichnis erstellen:

sudo mkdir /etc/bind/zones

Nun können wir einige der bereits vorhandenen Zonendateien im Bind-Verzeichnis als Vorlagen für die Zonendateien verwenden, die wir erstellen wollen. Für die Vorwärtszone kommt die Datei db.local dem, was wir brauchen, sehr nahe. Kopieren Sie diese Datei in das Unterverzeichnis zones mit dem Namen, der in der Datei named.conf.local verwendet wird.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

Während wir dies tun, können wir auch eine Vorlage für die Rückwärtszone kopieren. Wir verwenden die Datei db.127, da sie unseren Anforderungen am ehesten entspricht:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

Öffnen Sie nun die Vorwärtszonendatei mit sudo-Rechten in Ihrem Texteditor:

sudo nano /etc/bind/zones/db.example.com

Die Datei sieht dann so aus:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

Als Erstes müssen wir den SOA-Datensatz (Beginn der Autorität) ändern, der mit dem ersten @-Symbol beginnt und bis zur schließenden Klammer reicht.

Wir müssen localhost. durch den Namen des FQDN dieses Rechners ersetzen. Dieser Teil des Datensatzes wird verwendet, um einen Nameserver zu definieren, der für die zu definierende Zone autorisiert antwortet. Dies wird der Rechner sein, den wir jetzt konfigurieren, in unserem Fall ns1.example.com. (beachten Sie den Punkt am Ende. Dies ist wichtig, damit unser Eintrag korrekt registriert wird!).

Das nächste Element ist eine speziell formatierte E-Mail-Adresse, bei der das @ durch einen Punkt ersetzt wird. Wir wollen, dass unsere E-Mails an einen Verwalter der Domäne gehen, also lautet die traditionelle E-Mail-Adresse [email protected]. Wir würden dies so übersetzen, dass es so aussieht: admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

Das nächste Stück, das wir bearbeiten müssen, ist die Seriennummer. Anhand des Wertes der Seriennummer erkennt Bind, ob aktualisierte Informationen an den sekundären Server gesendet werden müssen.

Hinweis: Die Seriennummer nicht zu erhöhen, ist einer der häufigsten Fehler, der zu Problemen bei Zonenaktualisierungen führt. Jedes Mal, wenn Sie eine Änderung vornehmen, müssen Sie die Seriennummer erhöhen.

Eine gängige Praxis ist es, eine Konvention für die Erhöhung der Nummer zu verwenden. Eine Möglichkeit besteht darin, das Datum im Format JJJJMMTT zu verwenden und am Ende eine Revisionsnummer für den Tag hinzuzufügen. So könnte die erste Revision vom 05. Juni 2014 die Seriennummer 2014060501 haben und eine später an diesem Tag vorgenommene Aktualisierung die Seriennummer 2014060502. Der Wert kann eine 10-stellige Zahl sein.

Es lohnt sich, eine Konvention für die Benutzerfreundlichkeit anzunehmen, aber um die Dinge für unsere Demonstration einfach zu halten, werden wir unsere vorerst auf 5 setzen:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

Nächste können wir die letzten drei Zeilen in der Datei loswerden (die am Ende, die mit @ beginnen), da wir unsere eigenen machen werden.

Das erste, was wir nach dem SOA-Eintrag einrichten wollen, sind die Nameserver für unsere Zone. Wir geben die Domäne und dann die beiden Nameserver an, die für die Zone autorisierend sind, und zwar namentlich. Da es sich bei diesen Nameservern um Hosts innerhalb der Domäne selbst handelt, sieht es ein wenig selbstreferenziell aus.

Für unseren Leitfaden sieht es so aus. Achten Sie auch hier auf die Endpunkte!:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Da der Zweck einer Zonendatei hauptsächlich darin besteht, Hostnamen und Dienste bestimmten Adressen zuzuordnen, sind wir noch nicht fertig. Jede Software, die diese Zonendatei liest, muss wissen, wo sich die ns1– und ns2-Server befinden, um auf die autoritativen Zonen zugreifen zu können.

Als nächstes müssen wir also die A-Einträge erstellen, die diese Nameservernamen mit den tatsächlichen IP-Adressen unserer Nameserver verknüpfen:

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Nachdem wir nun die A-Einträge haben, die unsere Nameserver erfolgreich zu ihren korrekten IP-Adressen auflösen, können wir weitere Einträge hinzufügen. Denken Sie daran, dass wir einen Webserver auf einem unserer Hosts haben, den wir für die Bereitstellung unserer Website verwenden wollen. Wir werden Anfragen für die allgemeine Domäne (in unserem Fall example.com) an diesen Host weiterleiten, ebenso wie Anfragen für den Host www. Das sieht dann so aus:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Sie können weitere Hosts hinzufügen, indem Sie zusätzliche A-Einträge erstellen. Schauen Sie in unserem DNS-Grundlagenhandbuch nach, um sich mit einigen Ihrer Optionen bei der Erstellung zusätzlicher Einträge vertraut zu machen.

Wenn Sie fertig sind, sollte Ihre Datei in etwa so aussehen:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Erstellen Sie die Reverse-Zonendatei

Nun haben wir die Vorwärtszone konfiguriert, aber wir müssen die Reverse-Zonendatei einrichten, die wir in unserer Konfigurationsdatei angegeben haben. Wir haben die Datei bereits zu Beginn des letzten Abschnitts erstellt.

Öffnen Sie die Datei in Ihrem Texteditor mit sudo-Rechten:

sudo nano db.192.0.2

Die Datei sollte wie folgt aussehen:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Wir werden weitgehend dasselbe Verfahren wie bei der Vorwärtszone anwenden. Passen Sie zunächst den Domänennamen, die Admin-E-Mail und die Seriennummer so an, dass sie genau mit der letzten Datei übereinstimmen (die Seriennummer kann unterschiedlich sein, sollte aber inkrementiert werden):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

Löschen Sie auch hier die Zeilen unter der schließenden Klammer des SOA-Eintrags. Wir werden das letzte Oktett jeder IP-Adresse in unserem Netzwerkbereich nehmen und es mit Hilfe eines PTR-Eintrags auf den FQDN dieses Hosts zurückbilden. Jede IP-Adresse sollte nur einen einzigen PTR-Eintrag haben, um Probleme mit bestimmter Software zu vermeiden. Daher müssen Sie den Host-Namen wählen, auf den Sie die umgekehrte Zuordnung vornehmen möchten.

Wenn Sie beispielsweise einen Mail-Server eingerichtet haben, möchten Sie wahrscheinlich die umgekehrte Zuordnung auf den Mail-Namen einrichten, da viele Systeme die umgekehrte Zuordnung zur Überprüfung von Adressen verwenden.

Zunächst müssen wir unsere Nameserver neu einstellen:

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

Nächste Aufgabe ist es, das letzte Oktett der IP-Adresse, auf die Sie sich beziehen, zu verwenden und auf den voll qualifizierten Domänennamen zu verweisen, mit dem Sie zurückkehren möchten. In unserem Beispiel verwenden wir dies:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Wenn Sie fertig sind, sollte die Datei etwa so aussehen:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Testen der Dateien und Neustart des Dienstes

Die Konfiguration des Primärservers ist nun abgeschlossen, aber wir müssen unsere Änderungen noch implementieren.

Bevor wir unseren Dienst neu starten, sollten wir alle unsere Konfigurationsdateien testen, um sicherzustellen, dass sie korrekt konfiguriert sind. Es gibt einige Werkzeuge, mit denen wir die Syntax jeder unserer Dateien überprüfen können.

Zuerst können wir die Dateien named.conf.local und named.conf.options mit dem Befehl named-checkconf überprüfen. Da diese beiden Dateien aus der Skelettdatei named.conf stammen, wird die Syntax der von uns geänderten Dateien getestet.

sudo named-checkconf

Wenn dieser Befehl keine Meldungen zurückgibt, bedeutet dies, dass die Dateien named.conf.local und named.conf.options syntaktisch gültig sind.

Als Nächstes können Sie Ihre einzelnen Zonendateien überprüfen, indem Sie die von der Zone verwaltete Domäne und den Speicherort der Zonendatei an den Befehl named-checkzone übergeben. Für unsere Anleitung könnten Sie also die Forward-Zonendatei überprüfen, indem Sie Folgendes eingeben:

sudo named-checkzone example.com /etc/bind/zones/db.example.com

Wenn Ihre Datei keine Probleme aufweist, sollte sie Ihnen mitteilen, dass sie die korrekte Seriennummer geladen hat und die Meldung „OK“ ausgeben;

zone example.com/IN: loaded serial 5OK

Wenn Sie auf andere Meldungen stoßen, bedeutet dies, dass Sie ein Problem mit Ihrer Zonendatei haben. Normalerweise ist die Meldung recht anschaulich, welcher Teil ungültig ist.

Sie können die Reverse-Zone überprüfen, indem Sie die in-addr.arpa-Adresse und den Dateinamen übergeben. Für unsere Demonstration würden wir dies eingeben:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

Auch hier sollten Sie eine ähnliche Meldung über das Laden der korrekten Seriennummer erhalten:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Wenn alle Ihre Dateien ausgecheckt sind, können Sie Ihren Bind-Dienst neu starten:

sudo service bind9 restart

Sie sollten die Protokolle überprüfen, indem Sie Folgendes eingeben:

sudo tail -f /var/log/syslog

Beobachten Sie dieses Protokoll, um sicherzustellen, dass keine Fehler vorliegen.

Konfigurieren Sie den sekundären Bindungsserver

Nachdem wir nun den primären Server konfiguriert haben, können wir mit der Einrichtung des sekundären Servers fortfahren. Dies wird wesentlich einfacher sein als der primäre Server.

Konfiguration der Optionsdatei

Auch hier beginnen wir mit der Datei named.conf.options. Öffnen Sie sie mit sudo-Rechten in Ihrem Texteditor:

sudo nano /etc/bind/named.conf.options

Wir nehmen an dieser Datei genau die gleichen Änderungen vor, die wir an der Datei des Primärservers vorgenommen haben.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Konfigurieren der lokalen Konfigurationsdatei

Als nächstes konfigurieren wir die Datei named.conf.local auf dem Sekundärserver. Öffnen Sie sie mit sudo-Rechten in Ihrem Texteditor:

sudo nano /etc/bind/named.conf.local

Hier erstellen wir jede unserer Zonenspezifikationen wie auf dem Primärserver. Die Werte und einige der Parameter werden jedoch unterschiedlich sein.

Zunächst arbeiten wir an der Forward-Zone. Beginnen Sie auf die gleiche Weise wie in der Primärdatei:

zone "example.com" {};

Diesmal setzen wir type auf slave, da dieser Server als Sekundärserver für diese Zone fungiert. Das bedeutet einfach, dass er seine Zonendateien über eine Übertragung erhält und nicht über eine Datei auf dem lokalen System. Außerdem geben wir nur den relativen Dateinamen anstelle des absoluten Pfades zur Zonendatei an.

Der Grund dafür ist, dass Bind für sekundäre Zonen die Dateien /var/cache/bind speichert. Bind ist bereits so konfiguriert, dass es in diesem Verzeichnis nachschaut, so dass wir den Pfad nicht angeben müssen.

Für unsere Forward-Zone sehen diese Details wie folgt aus:

zone "example.com" { type slave; file "db.example.com";};

Schließlich geben wir anstelle der Direktive allow-transfer die primären Server nach IP-Adresse an, von denen dieser Server Zonentransfers akzeptiert. Dies geschieht in einer Direktive namens masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

Damit ist die Spezifikation unserer Forward-Zone abgeschlossen. Wir können genau dasselbe Format für die Spezifikation unserer Rückwärtszone verwenden:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

Wenn Sie fertig sind, können Sie die Datei speichern und schließen.

Testen der Dateien und Neustart des Dienstes

Wir müssen die eigentliche Erstellung der Zonendateien auf dem sekundären Rechner nicht durchführen, da dieser Server, wie bereits erwähnt, die Zonendateien vom primären Server erhält. Wir sind also bereit für den Test.

Auch hier sollten wir die Syntax der Konfigurationsdatei überprüfen. Da wir keine Zonendateien zum Prüfen haben, brauchen wir nur das Tool named-checkconf zu verwenden:

sudo named-checkconf

Wenn dieses Tool keine Fehler zurückgibt, bedeutet das, dass die von Ihnen geänderten Dateien keine Syntaxfehler aufweisen.

Wenn dies der Fall ist, können Sie Ihren Bind-Dienst neu starten:

sudo service bind9 restart

Überprüfen Sie die Protokolle auf dem primären und sekundären Server mit:

sudo tail -f /var/log/syslog

Sie sollten einige Einträge sehen, die darauf hinweisen, dass die Zonendateien korrekt übertragen wurden.

Delegieren Sie die Autorität an Ihre Nameserver

Ihre autoritativen Nameserver sollten nun vollständig konfiguriert sein. Sie müssen jedoch noch die Autorität für Ihre Domäne an Ihre Nameserver delegieren.

Zu diesem Zweck müssen Sie die Website aufrufen, auf der Sie Ihren Domänennamen erworben haben. Die Benutzeroberfläche und vielleicht auch die Terminologie unterscheiden sich je nach der von Ihnen benutzten Registrierungsstelle für Domänennamen.

Suchen Sie in den Einstellungen Ihrer Domäne nach einer Option, mit der Sie die Nameserver angeben können, die Sie verwenden möchten. Da sich unsere Nameserver innerhalb unserer Domäne befinden, ist dies ein Sonderfall.

Anstatt dass der Registrar die Autorität für die Zone einfach durch die Verwendung von NS-Einträgen delegiert, muss er einen Glue-Eintrag erstellen. Ein Glue Record ist ein A-Record, der die IP-Adressen für die Nameserver angibt, nachdem er die Nameserver spezifiziert hat, an die er die Autorität delegiert.

Normalerweise listet die Delegation nur die Nameserver auf, die die Autorität der Domäne verwalten werden, aber wenn die Nameserver innerhalb der Domäne selbst sind, ist ein A-Record für die Nameserver in der übergeordneten Zone erforderlich. Wäre dies nicht der Fall, würden DNS-Resolver in einer Schleife stecken bleiben, weil sie nie die IP-Adresse der Nameserver der Domäne finden könnten, um dem Delegationspfad zu folgen.

So müssen Sie einen Bereich im Control Panel Ihres Domain-Registrars finden, der es Ihnen erlaubt, Nameserver und ihre IP-Adressen anzugeben.

Zur Veranschaulichung hat der Registrar Namecheap zwei verschiedene Nameserverbereiche.

Es gibt einen Bereich namens „Nameserver Registration“, in dem Sie die IP-Adressen für Nameserver innerhalb Ihrer Domain angeben können:

In diesem Bereich können Sie die IP-Adressen der Nameserver eingeben, die innerhalb der Domain existieren:

Dadurch werden die A-Records erstellt, die als Glue-Records dienen, die Sie in der übergeordneten Zonendatei benötigen.

Nachdem Sie dies getan haben, sollten Sie in der Lage sein, die aktiven Nameserver auf die Server Ihrer Domain zu ändern. In NameCheap erfolgt dies über die Menüoption „Domain Name Server Setup“:

Hier können Sie die von Ihnen hinzugefügten Nameserver als autoritative Server für Ihre Website verwenden:

Die Änderungen können eine Weile dauern, bis sie sich ausbreiten, aber Sie sollten sehen, dass die Daten Ihrer Nameserver bei den meisten Registraren innerhalb der nächsten 24-48 Stunden verwendet werden.

Abschluss

Sie sollten nun zwei autoritative DNS-Server für die Verwaltung Ihrer Domains konfiguriert haben. Diese können verwendet werden, um Zoneninformationen für zusätzliche Domains zu speichern, wenn Sie weitere erwerben.

Die Konfiguration und Verwaltung Ihrer eigenen DNS-Server gibt Ihnen die größte Kontrolle darüber, wie die DNS-Einträge behandelt werden. Sie können Änderungen vornehmen und sicher sein, dass alle relevanten DNS-Daten an der Quelle aktuell sind. Auch wenn andere DNS-Lösungen diesen Prozess vereinfachen können, ist es wichtig zu wissen, dass Sie Optionen haben und zu verstehen, was in anderen Paketlösungen geschieht.