Einführung
DNS oder das Domain Name System ist häufig eine schwierige Komponente, um die Konfiguration von Websites und Servern zu erlernen. Während die meisten Benutzer wahrscheinlich die von ihrem Hosting-Unternehmen oder ihrer Domain-Registrierungsstelle bereitgestellten DNS-Server verwenden, bietet das Erstellen eigener DNS-Server einige Vorteile.
In diesem Handbuch wird erläutert, wie Sie den Bind9-DNS-Server auf Ubuntu 14.04-Computern als Nur-Autorisierungs-DNS-Server installieren und konfigurieren. Wir richten diese zwei Bindungsserver für unsere Domäne in einer Primär-Sekundär-Konfiguration ein.
Voraussetzungen und Ziele
Um dieses Handbuch zu vervollständigen, müssen Sie zunächst mit einigen gängigen DNS-Begriffen vertraut sein. Schauen Sie sichthis guide an, um mehr über die Konzepte zu erfahren, die wir in diesem Handbuch implementieren werden.
Sie benötigen außerdem mindestens zwei Server. Einer ist für den „primären“ DNS-Server bestimmt, auf dem die Zonendateien für unsere Domain erstellt werden, und einer ist der „sekundäre“ Server, der die Zonendaten durch Übertragungen empfängt und für den Fall verfügbar ist, dass der andere Server ausfällt. Dies vermeidet die Gefahr, dass Ihre DNS-Server an einem einzigen Punkt ausfallen.
Im Gegensatz zucaching or forwarding DNS servers oder einem Mehrzweck-DNS-Server antworten nur autorisierende Server nur auf iterative Anfragen für die Zonen, für die sie autorisierend sind. Das heißt, wenn der Server die Antwort nicht kennt, teilt er dem Client (normalerweise ein DNS-Auflösungsserver) mit, dass er die Antwort nicht kennt, und gibt einen Verweis auf einen Server, der möglicherweise mehr weiß.
Nur autorisierende DNS-Server sind häufig eine gute Konfiguration für hohe Leistung, da sie nicht den Aufwand haben, rekursive Abfragen von Clients zu lösen. Sie kümmern sich nur um die Zonen, die sie bedienen sollen.
Für die Zwecke dieses Handbuchs verweisen wir tatsächlich auf die Server vonthree. Die beiden oben genannten Nameserver sowie ein Webserver, den wir als Host in unserer Zone konfigurieren möchten.
Wir werden die Dummy-Domainexample.com für dieses Handbuch verwenden. Sie sollten es durch die Domäne ersetzen, die Sie konfigurieren. Dies sind die Details der Maschinen, die wir konfigurieren werden:
| Zweck | DNS FQDN | IP Adresse |
|---|---|---|
Primärer Nameserver |
ns1.example.com. |
192.0.2.1 |
Sekundärer Nameserver |
ns2.example.com. |
192.0.2.2 |
Webserver |
192.0.2.3 |
Nach dem Ausfüllen dieses Handbuchs sollten zwei Nur-Autorisierungs-Nameserver für Ihre Domänenzonen konfiguriert sein. Die Namen in der mittleren Spalte in der obigen Tabelle können verwendet werden, um Ihre verschiedenen Hosts zu erreichen. Mit dieser Konfiguration kann ein rekursiver DNS-Server Daten über die Domäne an Clients zurückgeben.
Festlegen 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 ordnungsgemäß konfiguriert ist.
Beginnen Sie mit der Untersuchung der Datei/etc/hosts. Öffnen Sie die Datei mit sudo-Berechtigungen in Ihrem Texteditor:
sudo nano /etc/hostsWir müssen dies so konfigurieren, dass der Hostname und der FQDN jedes Servers korrekt identifiziert werden. Für den primären Nameserver sieht die Datei zunächst so aus:
127.0.0.1 localhost
127.0.1.1 ns1 ns1
. . .Wir sollten die zweite Zeile ändern, um auf unsere spezifische Kombination aus Host und Domain zu verweisen, und diese auf unsere öffentliche, statische IP-Adresse verweisen. Anschließend können wir den nicht qualifizierten Namen als Alias hinzufügen. Für den Primärserver in diesem Beispiel würden Sie die zweite Zeile folgendermaßen ändern:
127.0.0.1 localhost
192.0.2.1 ns1.example.com ns1
. . .Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Wir sollten auch die Datei/etc/hostnameo ändern, dass sie unseren nicht qualifizierten Hostnamen enthält:
sudo nano /etc/hostnamens1Wir können diesen Wert in das aktuell laufende System einlesen, indem wir Folgendes eingeben:
sudo hostname -F /etc/hostnameWir möchten das gleiche Verfahren auf unserem sekundären Server durchführen.
Beginnen Sie mit der Datei/etc/hosts:
sudo nano /etc/hosts127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Ändern Sie dann die Datei/etc/hostname. Denken Sie daran, für diese Datei nur den tatsächlichen Host (in unserem Beispiel nurns2) zu verwenden:
sudo nano /etc/hostnamens2Lesen Sie die Datei erneut, um das aktuelle System zu ändern:
sudo hostname -F /etc/hostnameAuf Ihren Servern sollten jetzt die Hostdefinitionen korrekt eingestellt sein.
Installieren Sie Bind auf beiden Nameservern
Auf jedem Ihrer Nameserver können Sie jetzt Bind installieren, den DNS-Server, den wir verwenden werden.
Die Bind-Software ist in den Standard-Repositorys von Ubuntu verfügbar. Daher müssen wir nur unseren lokalen Paketindex aktualisieren und die Software mitapt installieren. Wir werden auch die Dokumentation und einige gängige Dienstprogramme einschließen:
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-docFühren Sie diesen Installationsbefehl auf Ihrem primären und sekundären DNS-Server aus, um die entsprechenden Dateien abzurufen.
Konfigurieren Sie den primären Bindungsserver
Nachdem wir die Software installiert haben, können wir zunächst Ihren DNS-Server auf dem Primärserver konfigurieren.
Konfigurieren der Optionsdatei
Das erste, was wir konfigurieren, um loszulegen, ist dienamed.conf.options-Datei.
Der Bind-DNS-Server wird auch alsnamed bezeichnet. Die Hauptkonfigurationsdatei befindet sich bei/etc/bind/named.conf. Diese Datei ruft die anderen Dateien auf, die wir tatsächlich konfigurieren werden.
Öffnen Sie die Optionsdatei mit sudo-Berechtigungen in Ihrem Editor:
sudo nano /etc/bind/named.conf.optionsUnten sind die meisten kommentierten Zeilen der Kürze halber gestrichen, 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; };
};Die Hauptsache, die wir in dieser Datei konfigurieren müssen, ist die Rekursion. Da wir versuchen, einen autorisierenden Server einzurichten, möchten wir die Rekursion auf diesem Server nicht aktivieren. Wir können dies innerhalb desoptions-Blocks ausschalten.
Wir werden auch standardmäßig keine Übertragungen zulassen. Wir werden dies später in den einzelnen 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.
Lokale Datei konfigurieren
Der nächste Schritt, den wir ausführen müssen, besteht darin, die Zonen anzugeben, die diesen Server steuern sollen. Eine Zone ist ein beliebiger Teil der Domäne, der zur Verwaltung an einen Nameserver delegiert wurde, der nicht an andere Server delegiert wurde.
Wir konfigurieren dieexample.com-Domäne und delegieren die Verantwortung für keinen Teil der Domäne an andere Server. Die Zone wird also unsere gesamte Domain abdecken.
Um unsere Zonen zu konfigurieren, müssen wir die Datei/etc/bind/named.conf.localmit sudo-Berechtigungen öffnen:
sudo nano /etc/bind/named.conf.localDiese Datei ist zunächst leer, außer den Kommentaren. Es gibt andere Zonen, die unser Server für die allgemeine Verwaltung kennt, diese sind jedoch in der Dateinamed.conf.default-zonesangegeben.
Zu Beginn müssen wir die Weiterleitungszone für die Domäneexample.comkonfigurieren. Forward-Zone ist die herkömmliche Namens-zu-IP-Auflösung, an die die meisten von uns denken, wenn wir über DNS sprechen. Wir erstellen einen Konfigurationsblock, der die zu konfigurierende Domainzone definiert:
zone "example.com" {
};[.note] #Note:Many DNS tools, their configuration files, and documentation use the terms “master” and “slave” while DigitalOcean generally prefers alternative descriptors. To avoid confusion we’ve chosen to use the terms “primary” and “secondary” to denote relationships between servers, and only use “master” or “slave” where a configuration directive requires it.
#
Innerhalb dieses Blocks fügen wir die Verwaltungsinformationen zu dieser Zone hinzu. Wir geben die Beziehung dieses DNS-Servers zur Zone an. Dies isttype master; in der folgenden Beispielzone, da wir diesen Computer als primären Nameserver für alle unsere Zonen konfigurieren. Wir zeigen auch Binden an die Datei, die die tatsächlichen Ressourceneinträge enthält, die die Zone definieren.
Wir werden unsere primären Zonendateien in einem Unterverzeichnis namenszones im Bind-Konfigurationsverzeichnis aufbewahren. Wir werden unsere Dateidb.example.com aufrufen, um die Konvention aus den anderen Zonendateien im Bind-Verzeichnis auszuleihen. Unser Block wird jetzt so aussehen:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
};Damit diese Zone auf unseren sekundären Server übertragen werden kann, müssen wir eine Zeile wie die folgende hinzufügen:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
allow-transfer { 192.0.2.2; };
};Als Nächstes definieren wir die Reverse Zone für Ihre Domain.
Ein bisschen über Reverse Zones
Wenn die Organisation, die Ihnen Ihre IP-Adressen gegeben hat, Ihnen keinen Netzwerkbereich zugewiesen hat und die Verantwortung für diesen Bereich an Sie delegiert hat, wird auf Ihre Reverse-Zone-Datei nicht verwiesen und sie wird von der Organisation selbst verwaltet.
Bei Hosting-Anbietern wird die umgekehrte Zuordnung in der Regel vom Unternehmen selbst vorgenommen. Beispielsweise werden mit DigitalOcean automatisch umgekehrte Zuordnungen für Ihre Server erstellt, wenn der vollqualifizierte Domänenname des Geräts als Servername in der Systemsteuerung verwendet wird. Die umgekehrten Zuordnungen für dieses Lernprogramm können beispielsweise erstellt werden, indem die Server folgendermaßen benannt werden:
In solchen Fällen sollten Sie diese Strategie anwenden, da Ihnen kein Adressblock zur Verwaltung zugewiesen wurde. Die unten beschriebene Strategie wird aus Gründen der Vollständigkeit und Anwendbarkeit behandelt, wenn Ihnen die Kontrolle über größere Gruppen zusammenhängender Adressen übertragen wurde.
Reverse Zones werden verwendet, um eine IP-Adresse wieder mit einem Domainnamen zu verbinden. Das Domain-Name-System wurde jedoch ursprünglich für die Forward-Zuordnungen entwickelt, sodass einige Überlegungen erforderlich sind, um diese anzupassen und Reverse-Zuordnungen zu ermöglichen.
Die Informationen, die Sie berücksichtigen müssen, um Reverse Mappings zu verstehen, sind:
-
In einer Domain befindet sich der spezifischste Teil der Adresse auf der linken Seite. Bei einer IP-Adresse befindet sich der spezifischste Teil rechts.
-
Der spezifischste Teil einer Domänenspezifikation ist entweder eine Unterdomäne oder ein Hostname. Dies ist in der Zonendatei für die Domäne definiert.
-
Jede Subdomain kann wiederum mehrere Subdomains oder Hosts definieren.
Alle Umkehrzonenzuordnungen werden unter der speziellen Domänein-addr.arpa definiert, die von der Internet Assigned Numbers Authority (IANA) gesteuert wird. Unter dieser Domäne gibt es einen Baum, der Unterdomänen verwendet, um jedes der Oktetts in einer IP-Adresse zuzuordnen. Um sicherzustellen, dass die Spezifität der IP-Adressen der von normalen Domänen entspricht, werden die Oktette der IP-Adressen tatsächlich umgekehrt.
Unser primärer DNS-Server mit einer IP-Adresse von192.0.2.1 wird also auf1.2.0.192 umgedreht. Wenn wir diese Hostspezifikation als eine Hierarchie hinzufügen, die unter der Domänein-addr.arpa vorhanden ist, kann der spezifische Host als1.2.0.192.in-addr.arpa bezeichnet werden.
Da wir bei Verwendung von DNS einzelne Hosts (wie die führende „1“ hier) in der Zonendatei selbst definieren, wäre die Zone, die wir konfigurieren würden,2.0.192.in-addr.arpa. Wenn unser Netzwerkanbieter uns einen / 24-Adressblock gegeben hätte, z. B.192.0.2.0/24, hätte er diesenin-addr.arpa-Teil an uns delegiert.
Nachdem Sie nun wissen, wie der Name der Rückwärtszone angegeben wird, entspricht die tatsächliche Definition genau der der Vorwärtszone. Erstellen Sie unterhalb der Zonendefinition vonexample.comeine umgekehrte Zone für das Netzwerk, das Sie erhalten haben. Auch dies ist wahrscheinlich nur erforderlich, wenn Sie die Kontrolle über einen Adressblock erhalten haben:
zone "2.0.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.192.0.2";
};Wir haben uns entschieden, die Dateidb.192.0.2 zu benennen. Dies ist spezifisch für die Konfiguration der Zone und besser lesbar als die umgekehrte Schreibweise.
Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Erstellen Sie die Forward-Zonendatei
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.
Wenn Sie sich erinnern, haben wir die Dateispeicherorte in einem Unterverzeichnis namenszones angegeben. Wir müssen dieses Verzeichnis erstellen:
sudo mkdir /etc/bind/zonesJetzt können wir einige der bereits vorhandenen Zonendateien im Bindeverzeichnis als Vorlagen für die zu erstellenden Zonendateien verwenden. Für die Vorwärtszone liegt die Dateidb.localin der Nähe unserer Anforderungen. Kopieren Sie diese Datei in das Unterverzeichniszonesmit dem Namen, der in der Dateinamed.conf.localverwendet wird.
sudo cp /etc/bind/db.local /etc/bind/zones/db.example.comWährenddessen können wir auch eine Vorlage für die Reverse Zone kopieren. Wir werden diedb.127-Datei verwenden, da sie genau unseren Anforderungen entspricht:
sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2Öffnen Sie nun die Forward Zone-Datei mit Sudo-Berechtigungen in Ihrem Texteditor:
sudo nano /etc/bind/zones/db.example.comDie Datei sieht folgendermaßen 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 ::1Als erstes müssen wir den DatensatzSOA (Beginn der Berechtigung) ändern, der mit dem ersten@-Symbol beginnt und bis zur schließenden Klammer fortgesetzt wird.
Wir müssenlocalhost. durch den Namen des FQDN dieser Maschine ersetzen. Dieser Teil des Datensatzes wird verwendet, um einen Nameserver zu definieren, der für die zu definierende Zone autorisierend antwortet. Dies ist die Maschine, die wir jetzt konfigurieren, in unserem Fallns1.example.com. (beachten Sie den nachgestellten Punkt. Dies ist wichtig, damit sich unser Eintrag korrekt anmeldet!).
Wir möchten auch das nächste Stück ändern, bei dem es sich tatsächlich um eine speziell formatierte E-Mail-Adresse handelt, bei der@durch einen Punkt ersetzt werden. Wir möchten, dass unsere E-Mails an eine Verwaltung der Domain gehen, daher lautet die herkömmliche E-Mail[email protected]. Wir würden dies so übersetzen, dass es wieadmin.example.com. aussieht:
@ IN SOA ns1.example.com. admin.example.com. (Das nächste Stück, das wir bearbeiten müssen, ist die Seriennummer. Der Wert der Seriennummer gibt an, wie Bind angibt, ob aktualisierte Informationen an den sekundären Server gesendet werden müssen.
Note: Das Nichterhöhen der Seriennummer ist einer der häufigsten Fehler, der zu Problemen mit Zonenaktualisierungen führt. Jedes Mal, wenn Sie eine Bearbeitung vornehmen, stoßen Siemustan die Seriennummer.
Eine gängige Praxis besteht darin, eine Konvention zum Inkrementieren der Zahl zu verwenden. Ein Ansatz besteht darin, das Datum im Format JJJJMMTT zusammen mit einer Revisionsnummer für den am Ende hinzugefügten Tag zu verwenden. Die erste am 5. Juni 2014 vorgenommene Überarbeitung könnte also eine Seriennummer von 2014060501 haben, und ein späteres Update könnte eine Seriennummer von 2014060502 haben. Der Wert kann eine 10-stellige Zahl sein.
Es lohnt sich, eine Konvention zu verabschieden, um die Verwendung zu vereinfachen. Um die Demonstration zu vereinfachen, setzen wir unsere vorerst nur auf5:
@ IN SOA ns1.example.com. admin.example.com. (
5 ; SerialAls nächstes können wir die letzten drei Zeilen in der Datei (die unteren, die mit@ beginnen) entfernen, da wir unsere eigenen erstellen werden.
Das erste, was wir nach dem SOA-Datensatz einrichten möchten, sind die Nameserver für unsere Zone. Wir geben die Domain und dann unsere beiden Nameserver, die für die Zone maßgeblich sind, namentlich an. Da diese Nameserver Hosts innerhalb der Domäne selbst sind, wirkt sie etwas selbstreferenziell.
Für unseren Guide wird es so aussehen. Achten Sie auch hier auf die Endpunkte !:
; Name servers
example.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, möchte wissen, wo sich die Serverns1 undns2befinden, um auf die autorisierenden Zonen zugreifen zu können.
Als nächstes müssen wir dieA-Datensätze erstellen, die diese Nameservernamen mit den tatsächlichen IP-Adressen unserer Nameserver verknüpfen:
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2Nachdem wir die A-Einträge haben, um unsere Nameserver erfolgreich auf die richtigen IP-Adressen aufzulösen, können wir weitere Einträge hinzufügen. Denken Sie daran, dass wir auf einem unserer Hosts einen Webserver haben, den wir für die Bereitstellung unserer Website verwenden möchten. Wir werden Anfragen für die allgemeine Domain (in unserem Fallexample.com) auf diesen Host sowie Anfragen für den Host vonwwwverweisen. Es wird so aussehen:
; Other A records
@ IN A 192.0.2.3
www IN A 192.0.2.3Sie können alle zusätzlichen Hosts hinzufügen, die Sie definieren müssen, indem Sie zusätzlicheA-Datensätze erstellen. Verweisen Sie auf unsereDNS basics guide, um sich mit einigen Ihrer Optionen zum Erstellen zusätzlicher Datensätze vertraut zu machen.
Wenn Sie fertig sind, sollte Ihre Datei ungefähr 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 servers
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
; Other A records
@ IN A 192.0.2.3
www IN A 192.0.2.3Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Erstellen Sie die Reverse Zone-Datei
Jetzt haben wir die Forward-Zone konfiguriert, aber wir müssen die Reverse-Zone-Datei einrichten, die wir in unserer Konfigurationsdatei angegeben haben. Wir haben die Datei bereits am Anfang des letzten Abschnitts erstellt.
Öffnen Sie die Datei in Ihrem Texteditor mit sudo-Berechtigungen:
sudo nano db.192.0.2Die Datei sollte folgendermaßen 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 die gleiche Prozedur wie bei der Forward-Zone durchführen. Passen Sie zunächst den Domänennamen, die Administrator-E-Mail-Adresse und die Seriennummer so an, dass sie genau mit Ihrer letzten Datei übereinstimmen (die Seriennummer kann unterschiedlich sein, sollte jedoch erhöht werden):
@ IN SOA example.com. admin.example.com. (
5 ; SerialLöschen Sie erneut die Zeilen unter der schließenden Klammer des DatensatzesSOA. Wir werden das letzte Oktett jeder IP-Adresse in unserem Netzwerkbereich nehmen und es mit einemPTR-Datensatz dem vollqualifizierten Domänennamen des Hosts zuordnen. Jede IP-Adresse sollte nur einen einzigenPTR-Datensatz haben, um Probleme in einigen Softwareprogrammen zu vermeiden. Wählen Sie daher den Hostnamen aus, zu dem Sie die Zuordnung rückgängig machen möchten.
Wenn Sie beispielsweise einen Mail-Server eingerichtet haben, möchten Sie wahrscheinlich die umgekehrte Zuordnung zum Mail-Namen einrichten, da viele Systeme die umgekehrte Zuordnung zum Überprüfen von Adressen verwenden.
Zuerst müssen wir unsere Nameserver neu einstellen:
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.Als Nächstes verwenden Sie das letzte Oktett der IP-Adresse, auf die Sie sich beziehen, und verweisen dieses auf den vollständig qualifizierten Domänennamen, mit dem Sie zurückkehren möchten. In unserem Beispiel verwenden wir Folgendes:
; PTR Records
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.Wenn Sie fertig sind, sollte die Datei ungefähr 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 records
1 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 Neustarten des Dienstes
Die Konfiguration für den Primärserver ist nun abgeschlossen, wir müssen jedoch noch Änderungen vornehmen.
Bevor wir unseren Dienst neu starten, sollten wir alle Konfigurationsdateien testen, um sicherzustellen, dass sie richtig konfiguriert sind. Wir haben einige Tools, die die Syntax jeder unserer Dateien überprüfen können.
Zuerst können wir die Dateiennamed.conf.local undnamed.conf.options mit dem Befehlnamed-checkconf überprüfen. Da diese beiden Dateien von dernamed.conf-Skelettdatei stammen, wird die Syntax der von uns geänderten Dateien getestet.
sudo named-checkconfWenn dies ohne Nachrichten zurückgegeben wird, bedeutet dies, dass die Dateiennamed.conf.local undnamed.conf.optionsyntaktisch gültig sind.
Als Nächstes können Sie Ihre einzelnen Zonendateien überprüfen, indem Sie die von der Zone behandelte Domäne und den Speicherort der Zonendatei an den Befehlnamed-checkzoneübergeben. Für unseren Leitfaden können Sie die Forward-Zonendatei also überprüfen, indem Sie Folgendes eingeben:
sudo named-checkzone example.com /etc/bind/zones/db.example.comWenn Ihre Datei keine Probleme aufweist, sollte sie Ihnen mitteilen, dass sie die richtige Seriennummer geladen hat, und die Meldung "OK" anzeigen.
zone example.com/IN: loaded serial 5
OKWenn Sie auf andere Nachrichten stoßen, liegt ein Problem mit Ihrer Zonendatei vor. Normalerweise beschreibt die Nachricht ziemlich genau, welcher Teil ungültig ist.
Sie können die umgekehrte Zone überprüfen, indem Sie die Adresse vonin-addr.arpaund den Dateinamen übergeben. Für unsere Demonstration geben wir Folgendes ein:
sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2Auch dies sollte Ihnen eine ähnliche Meldung zum Laden der richtigen Seriennummer geben:
zone 2.0.192.in-addr.arpa/IN: loaded serial 5
OKWenn alle Ihre Dateien ausgecheckt werden, können Sie Ihren Bindungsdienst neu starten:
sudo service bind9 restartSie sollten die Protokolle überprüfen, indem Sie Folgendes eingeben:
sudo tail -f /var/log/syslogBehalten Sie dieses Protokoll im Auge, um sicherzustellen, dass keine Fehler vorliegen.
Konfigurieren Sie den sekundären Bindungsserver
Nachdem wir den Primärserver konfiguriert haben, können wir fortfahren und den Sekundärserver einrichten. Dies ist erheblich einfacher als der Primärserver.
Konfigurieren der Optionsdatei
Wieder beginnen wir mit der Dateinamed.conf.options. Öffnen Sie es mit sudo-Berechtigungen in Ihrem Texteditor:
sudo nano /etc/bind/named.conf.optionsWir werden genau die Änderungen an dieser Datei vornehmen, die wir an der Datei unseres 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.
Lokale Konfigurationsdatei konfigurieren
Als nächstes konfigurieren wir dienamed.conf.local-Datei auf dem sekundären Server. Öffnen Sie es mit sudo-Berechtigungen in Ihrem Texteditor:
sudo nano /etc/bind/named.conf.localHier erstellen wir jede unserer Zonenspezifikationen wie auf unserem Primärserver. Die Werte und einige Parameter sind jedoch unterschiedlich.
Zuerst werden wir an der Vorwärtszone arbeiten. Starten Sie es so, wie Sie es in der Primärdatei getan haben:
zone "example.com" {
};Dieses Mal setzen wirtype aufslave, da dieser Server als sekundärer Server für diese Zone fungiert. Dies bedeutet lediglich, dass die Zonendateien durch Übertragung und nicht durch eine Datei auf dem lokalen System empfangen werden. Außerdem geben wir nur den relativen Dateinamen anstelle des absoluten Pfads 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 in diesem Verzeichnis gesucht wird, sodass der Pfad nicht angegeben werden muss.
Für unsere Vorwärtszone sehen diese Details folgendermaßen aus:
zone "example.com" {
type slave;
file "db.example.com";
};Schließlich geben wir anstelle der Direktiveallow-transferdie Primärserver nach IP-Adresse an, von denen dieser Server Zonenübertragungen akzeptiert. Dies geschieht in einer Direktive namensmasters:
zone "example.com" {
type slave;
file "db.example.com";
masters { 192.0.2.1; };
};Dies vervollständigt unsere Vorwärtszonenspezifikation. Wir können dasselbe exakte Format verwenden, um unsere Reverse-Zone-Spezifikation zu berücksichtigen:
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 Neustarten des Dienstes
Die eigentliche Erstellung der Zonendatei muss auf dem sekundären Computer nicht durchgeführt werden, da dieser Server, wie bereits erwähnt, die Zonendateien vom primären Server empfängt. Also sind wir bereit zu testen.
Auch hier sollten wir die Syntax der Konfigurationsdatei überprüfen. Da wir keine zu überprüfenden Zonendateien haben, müssen wir nur das Toolnamed-checkconfverwenden:
sudo named-checkconfWenn dies ohne Fehler zurückgegeben wird, bedeutet dies, dass die von Ihnen geänderten Dateien keine Syntaxfehler aufweisen.
In diesem Fall können Sie Ihren Bindungsdienst neu starten:
sudo service bind9 restartÜberprüfen Sie die Protokolle auf dem primären und dem sekundären Server mit:
sudo tail -f /var/log/syslogEs sollten einige Einträge angezeigt werden, die darauf hinweisen, dass die Zonendateien korrekt übertragen wurden.
Delegieren Sie die Berechtigung an Ihre Nameserver
Ihre Nur-Autorisierungs-Nameserver sollten jetzt vollständig konfiguriert sein. Sie müssen jedoch weiterhin Berechtigungen für Ihre Domain an Ihre Nameserver delegieren.
Dazu müssen Sie zu der Website gehen, auf der Sie Ihren Domain-Namen gekauft haben. Die Benutzeroberfläche und möglicherweise die Terminologie unterscheiden sich je nach dem von Ihnen verwendeten Domainnamen-Registrar.
Suchen Sie in Ihren Domain-Einstellungen nach einer Option, mit der Sie die zu verwendenden Nameserver angeben können. Da unsere Nameserverwithinunserer Domain sind, ist dies ein Sonderfall.
Anstatt dass der Registrar lediglich die Berechtigung für die Zone mithilfe von NS-Datensätzen delegiert, muss er einglue record erstellen. Ein Glue-Datensatz ist ein A-Datensatz, der die IP-Adressen für die Nameserver angibt, nachdem er die Nameserver angegeben hat, an die er die Berechtigung delegiert.
Normalerweise listet die Delegierung nur die Nameserver auf, die die Autorität der Domäne verwalten. Befinden sich die Nameserver jedoch in der Domäne selbst, ist ein A-Eintrag für die Nameserver in der übergeordneten Zone erforderlich. Andernfalls würden DNS-Resolver in einer Schleife hängen bleiben, da sie die IP-Adresse der Nameserver der Domäne nicht finden könnten, um dem Delegierungspfad zu folgen.
Sie müssen also einen Abschnitt in der Systemsteuerung Ihres Domain-Registrars finden, in dem Sie die IP-Adressen der Nameserverandangeben können.
Zur Demonstration hat der RegistrarNamecheap zwei verschiedene Nameserverabschnitte.
Es gibt einen Abschnitt namens "Nameserver Registration", in dem Sie die IP-Adressen für Nameserver in Ihrer Domain angeben können:
Im Inneren können Sie die IP-Adressen der in der Domäne vorhandenen Nameserver eingeben:
Hierdurch wird der A-Datensatz erstellt, der als die in der übergeordneten Zonendatei benötigten Klebstoffdatensätze dient.
Nachdem Sie dies getan haben, sollten Sie in der Lage sein, die aktiven Nameserver in die Server Ihrer Domain zu ändern. In NameCheap erfolgt dies über die Menüoption "Domain Name Server Setup":
Hier können Sie festlegen, dass die von Ihnen als autorisierende Server für Ihre Site hinzugefügten Nameserver verwendet werden sollen:
Die Weitergabe der Änderungen kann eine Weile dauern, aber Sie sollten sehen, dass die Daten von Ihren Nameservern für die meisten Registrare innerhalb der nächsten 24-48 Stunden verwendet werden.
Fazit
Sie sollten jetzt zwei DNS-Server haben, die nur für autorisierende Zwecke konfiguriert sind und Ihre Domänen bedienen. Diese können verwendet werden, um Zoneninformationen für zusätzliche Domains zu speichern, wenn Sie mehr erwerben.
Durch Konfigurieren und Verwalten Ihrer eigenen DNS-Server können Sie die Handhabung der DNS-Einträge am besten steuern. Sie können Änderungen vornehmen und sicherstellen, dass alle relevanten DNS-Daten an der Quelle auf dem neuesten Stand sind. Während andere DNS-Lösungen diesen Prozess möglicherweise vereinfachen, ist es wichtig zu wissen, dass Sie über Optionen verfügen, und zu verstehen, was in stärker gepackten Lösungen vor sich geht.