Einführung
Das Einrichten eines DNS-Servers als Verantwortlicher für Domänennamen kann selbst für erfahrene Administratoren eine komplexe Aufgabe sein. Die Verwaltung von DNS-Zonen ist eine wichtige Aufgabe, kann jedoch verwirrend sein, insbesondere, wenn Sie versuchen, loszulegen.
Software wie der DNS-Server vonBindist unglaublich flexibel und kann so konfiguriert werden, dass so viele Komponenten in der gesamten DNS-Hierarchie betrieben werden. Diese Flexibilität bedeutet jedoch auch, dass Bind nicht für eine Aufgabe optimiert ist. Dies hat einige Nebenwirkungen.
Die meiste Zeit gibt es riesige Funktionsblöcke, für die Ihre Konfiguration keinen Bedarf hat. Diese zusätzliche Komplexität erschwert die Verwaltung. Dies bedeutet auch, dass die Software selbst auf eine Aufgabe weniger schnell reagiert.
Um dieses Problem zu lösen, wurden alternative DNS-Server erstellt, die auf einen einzelnen Bereich der DNS-Auflösung spezialisiert sind. Eine alsNSD bekannte Software ist ein nur autorisierender DNS-Server, der sich ideal für die autorisierende Verwaltung von DNS-Zonen eignet. Ohne sich jemals um Rekursion oder Caching kümmern zu müssen, arbeitet dieser Server mit hoher Leistung und geringerem Platzbedarf.
In diesem Handbuch wird gezeigt, wie NSD installiert und konfiguriert wird, um unsere DNS-Zonen auf Ubuntu 14.04-Servern sicher zu verwalten.
Voraussetzungen und Ziele
Bevor Sie mit dieser Anleitung beginnen, sollten Sie mit einigenbasic DNS concepts and terminology vertraut sein. Wenn Sie Hilfe benötigen, um zu verstehen, wofür ein DNS-Server nur mit Berechtigung verwendet wird, lesen Sie unseren Leitfaden zuthe differences between DNS server types.
Als autorisierender DNS-Server bietet NSD keine Caching-, Weiterleitungs- oder rekursiven Funktionen. Es antwortet nur auf iterative Anforderungen für die Zonen, die es steuert. Es kann auch Resolver auf andere Nameserver für Zonen verweisen, die es delegiert hat.
In diesem Handbuch werden zwei Server mit NSD-Software konfiguriert, die als primäre und sekundäre Server für unsere Zonen fungieren. Wir werden auch Konfigurationsdaten bereitstellen, mit denen Clients einen Webserver auf einem dritten Host erreichen können.
Wir werden die Dummy-Domainexample.com für dieses Handbuch verwenden. Sie sollten Ihre eigene Domain ersetzen, um mitzumachen. Die Maschinen, die wir konfigurieren werden, haben die folgenden Eigenschaften:
| 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 |
Nachdem Sie mit diesem Handbuch fertig sind, sollten Sie die ersten beiden Server mit NSD als Nur-Autorisierungsserver für Ihre Zonen konfigurieren. Sie können die von uns konfigurierten Hostnamen verwenden, um Ihre Server über das Internet zu erreichen, und die Hostnamen durch Abfragen der IP-Adressen ermitteln. Jeder auflösende Client, der in der Lage ist, unsere Server zu erreichen, kann die Domänendaten von unseren Servern abrufen.
Festlegen des Hostnamens auf den Nameservern
Der erste Schritt, den wir unternehmen müssen, ist ein vorbereitender. Bevor wir uns um die DNS-Konfiguration kümmern, müssen wir sicherstellen, dass unsere Nameserver ihren eigenen Hostnamen auf die von uns gewünschte Weise korrekt auflösen können.
Bearbeiten Sie auf Ihrem ersten DNS-Server die Datei/etc/hosts, um den vollqualifizierten Domänennamen dieses Computers einzurichten:
sudo nano /etc/hostsIn unserem Fall müssen wir die IP-Adresse von192.0.2.1dem vollständigen Namen unseres Vornamenserversns1.example.com zuordnen. Wir können dies tun, indem wir die Zeile, die unseren Hostnamen angibt, durch unsere öffentliche IP-Adresse, den FQDN und den verkürzten Alias für unseren Host ersetzen:
127.0.0.1 localhost
192.0.2.1 ns1.example.com ns1Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Als nächstes müssen wir die/etc/hostname-Datei überprüfen:
sudo nano /etc/hostnameDies sollte den Wert des Hostnamens vonunqualifiedenthalten. Ändern Sie es bei Bedarf:
ns1Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Wenn Sie die Datei/etc/hostnameoben geändert haben, weisen Sie das System an, die Datei erneut zu lesen:
sudo hostname -F /etc/hostnameWir sind vorerst mit unserem ersten DNS-Server fertig. Wiederholen Sie die Schritte auf dem zweiten Server.
Ändern Sie die Datei/etc/hosts, um den Host des zweiten DNS-Servers anzugeben:
sudo nano /etc/hosts127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2Überprüfen Sie auch die/etc/hostname-Datei. Dies sollte nur den kurzen, nicht qualifizierten Namen haben:
sudo nano /etc/hostnamens2Lassen Sie das System die Datei erneut lesen, wenn Sie Änderungen vornehmen mussten:
sudo hostname -F /etc/hostnameIhre Server können jetzt ihre eigenen Namen auflösen, ohne DNS zu verwenden. Sie können nun NSD auf Ihren Servern einrichten.
Installieren Sie NSD auf beiden Nameservern
Der nächste Schritt besteht darin, die Software tatsächlich auf Ihren Nameservern zu installieren.
Bevor wir beginnen, müssen wir tatsächlich einen weiteren vorbereitenden Schritt unternehmen. Das NSD-Paket im Repository installiert die Software, konfiguriert einige Komponenten und versucht, den Dienst zu starten. Der Dienst wird voraussichtlich als Benutzer mit dem Namennsd ausgeführt, das Paket erstellt dieses Benutzerkonto jedoch nicht.
Um einen Fehler bei der Installation zu vermeiden, erstellen wir diesen Benutzerbefore, mit dem wir die Software installieren. Erstellen Sie auf jedem Ihrer Computer den Systembenutzernsd, indem Sie Folgendes eingeben:
sudo useradd -r nsdDadurch wird das richtige Konto erstellt, das zum erfolgreichen Abschluss der Installation erforderlich ist.
Jetzt müssen wir nur noch die NSD-Software installieren. Glücklicherweise ist NSD in den Ubuntu 14.04-Repositorys enthalten, sodass wir nurapt verwenden können, um es herunterzuziehen. Wir aktualisieren unseren lokalen Paketindex und laden dann das entsprechende Paket herunter:
sudo apt-get update
sudo apt-get install nsdDadurch wird die Software installiert und eine Erstkonfiguration durchgeführt. Der Dienst wird auch gestartet, obwohl wir ihn noch nicht für die Bereitstellung konfiguriert haben.
Konfigurieren Sie den primären NSD-Server
Wir beginnen mit der Einrichtung unseresns1-Servers, der als primärer DNS-Server für unsere Zonen konfiguriert wird.
Als Erstes sollten wir sicherstellen, dass alle SSL-Schlüssel und -Zertifikate generiert werden, mit denen NSD sicher zwischen dem Daemon-Teil der Anwendung und dem Controller kommuniziert.
Geben Sie dazu Folgendes ein:
sudo nsd-control-setupIm Verzeichnis/etc/nsdind wahrscheinlich bereits Schlüssel und Zertifikate vorhanden, aber dieser Befehl generiert alles, was fehlt.
Konfigurieren Sie die Datei nsd.conf
Die Hauptkonfigurationsdatei für NSD ist eine Datei mit dem Namennsd.conf im Verzeichnis/etc/nsd.
In diesem Verzeichnis befindet sich bereits eine Datei mit nur wenigen Kommentaren. Wir verwenden jedoch eine ausführlichere Beispieldatei als Vorlage. Kopieren Sie dies jetzt, um die aktuelle Datei zu überschreiben:
sudo cp /usr/share/doc/nsd/examples/nsd.conf /etc/nsd/nsd.confÖffnen Sie jetzt die neue Datei in Ihrem Texteditor mit sudo-Berechtigungen:
sudo nano /etc/nsd/nsd.confIm Inneren sehen Sie eine Reihe kommentierter Konfigurationszeilen, die in Abschnitte unterteilt sind. Die Hauptabschnitte sindserver,remote-control,key,pattern undzone. Wir werden die meisten davon für unsere Konfiguration verwenden.
Zunächst sollten wir die grundlegenden Eigenschaften unseres DNS-Servers im Abschnittserverkonfigurieren. Wir werden den grundlegenden IPv4-Verkehr auf dem Standard-DNS-Port 53 verarbeiten. Wir werden den Benutzer vonnsdverwenden, den wir zuvor eingerichtet haben. Die meisten davon sind die Standardwerte, aber wir werden die zugehörigen Zeilen auskommentieren, um ihre Werte explizit zu machen.
Wir möchten auch explizit das Verzeichnis festlegen, das unsere Zonendaten sowie unsere Speicherorte für Protokoll- und PID-Dateien enthält. Es gibt viele andere Konfigurationsoptionen, die Sie für diesen Abschnitt festlegen können, aber wir werden es relativ einfach halten. Sie können jederzeit weitere Änderungen vornehmen.
Unser Server-Bereich sieht dann so aus:
server:
do-ip4: yes
port: 53
username: nsd
zonesdir: "/etc/nsd"
logfile: "/var/log/nsd.log"
pidfile: "/run/nsd/nsd.pid"Schauen wir uns als nächstes den Abschnittremote-controlan. Dieser Abschnitt ist etwas falsch, da er nicht nur zur Fernsteuerung unseres Daemons verwendet wird. Wir werden dies konfigurieren, um den Daemon lokal zu steuern.
Zuerst müssen wir die Ressource aktivieren und ihre Schnittstelle und Portnummer festlegen. Dies kann alles geschehen, indem Sie die entsprechenden Zeilen auskommentieren und die Direktivecontrol-enablein "yes" ändern.
Als Nächstes können Sie die Zeilen auskommentieren, in denen der Schlüssel und die Zertifikatdateien angegeben sind. Diese stimmen mit den Dateinamen überein, die beim Ausführen des Befehlsnsd-control-setupgeneriert wurden, und sollten nicht geändert werden müssen, sobald sie nicht mehr kommentiert sind.
Unsere Werte für diesen Abschnitt sollten folgendermaßen aussehen:
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: "/etc/nsd/nsd_server.key"
server-cert-file: "/etc/nsd/nsd_server.pem"
control-key-file: "/etc/nsd/nsd_control.key"
control-cert-file: "/etc/nsd/nsd_control.pem"Als nächstes konfigurieren wir den Abschnittkey. Dieser Abschnitt enthält die geheimen Schlüssel, die NSD zur sicheren Ausführung von Zonenübertragungen zwischen unseren primären und sekundären Servern verwendet.
Wir müssen den Namen und den Algorithmus festlegen, der verwendet werden soll. Wir werden den Namendemokey für unser Beispiel verwenden. Wir werden auch den von ihnen ausgewählten Standardalgorithmus (hmac-sha256) verwenden.
Für das Geheimnis selbst werden wir den Ratschlag im Kommentar zur sicheren Generierung eines solchen übernehmen. Beenden Sie den Texteditor. Führen Sie in Ihrem Terminal den folgenden Befehl aus:
dd if=/dev/random of=/dev/stdout count=1 bs=32 | base64Sie erhalten einen zufällig generierten Schlüssel in der Ausgabe des Befehls:
0+1 records in
0+1 records out
19 bytes (19 B) copied, 0.000571766 s, 33.2 kB/s
+kO0Vu6gC+9bxzMy3TIZVLH+fg==Kopieren Sie die Ausgabe in rot oben und öffnen Sie Ihre Konfigurationsdatei erneut. Verwenden Sie die kopierte Ausgabe als Wert für den Parametersecret. Dieser Abschnitt sollte folgendermaßen aussehen:
key:
name: "demokey"
algorithm: hmac-sha256
secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="Als Nächstes richten wir ein einfaches Muster ein, da wir einige sich wiederholende Informationen zu unserem Sekundärserver haben. Wir werden unsere Zonen jedes Mal benachrichtigen und auf dieselbe sekundäre Zone übertragen, daher ist es sinnvoll, ein Muster zu erstellen.
Wir werden unser Mustertosecondary aufrufen, um zu beschreiben, wofür das Muster verwendet wird. Wir werden den Namen und die Datei für jede Zone einzeln festlegen, damit wir uns im Muster nicht darum kümmern müssen.
Wir möchten den Parameternotifyin unserem Muster festlegen, um auf die IP-Adresse unseres sekundären Servers zu verweisen. Wir möchten auch den von uns angegebenen Schlüssel verwenden, um die Zonen mit TSIG sicher zu übertragen. Wir werden denprovide-xfr-Parameter genauso einrichten.
Am Ende sollte unser Abschnittpatternfolgendermaßen aussehen:
pattern:
name: "tosecondary"
notify: 192.0.2.2 demokey
provide-xfr: 192.0.2.2 demokeySchließlich kommen wir zu unserem Abschnittzone. Hier konfigurieren wir, wie NSD mit unseren spezifischen Zonen und den zugehörigen Dateien umgehen soll.
Zuerst konfigurieren wir unsere Forward-Zone. Wir müssen die Zone für unsereexample.com-Zone einrichten. Dies ist so einfach wie die Angabe der Domäne selbst unter dem Parametername, die Angabe des Namens, den wir für die Zonendatei verwenden, und die Angabe des oben erstellten Musters, um dies auf unseren sekundären Server zu übertragen.
Die fertige Forward-Zone für unsere Demo sollte folgendermaßen aussehen:
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "tosecondary"Als nächstes können wir uns um die Reverse Zone kümmern. Eine Reverse Zone ist im Grunde eine Zonendatei, mit der DNS-Software eine IP-Adresse wieder einem Hostnamen für Clients zuordnen kann. Im Allgemeinen wird dies beim Hosting wie DigitalOcean vom Hosting-Anbieter erledigt.
Bei DigitalOcean wird Ihnen beispielsweise nicht die Verantwortung für einen Bereich von IP-Adressen übertragen, um umgekehrte Zuordnungen einzurichten. Stattdessen erstellt DigitalOcean automatisch die erforderlichen umgekehrten Zuordnungen, wenn Sie den Hostnamen des Servers in der Systemsteuerung auf den FQDN setzen, dem er wieder zugeordnet werden soll.
Weitere Informationen zu umgekehrten Zuordnungen finden Sie im Abschnitt „Ein bisschen über umgekehrte Zonen“ inBind authoritative-only guide. Wir zeigen Ihnen, wie Sie die Reverse-Zonen für NSD zu Informationszwecken und zur Erhöhung der Flexibilität einrichten, auch wenn dies nur in Situationen relevant ist, in denen Sie die Kontrolle über die Reverse-Zuordnungen für einen IP-Block erhalten haben.
Für eine Reverse-Zone nehmen wir die ersten drei Oktette der IP-Adresse, kehren sie um und fügen sie als Subdomain-Delegierungen zur speziellen Domainin-addr.arpa hinzu. Auf diese Weise sucht das DNS-System nach IP-Adressen mit denselben Suchmethoden wie normale Domänen. In unserem Fall erstellen wir eine umgekehrte Zone, die die Zuordnung von2.0.192.in-addr.arpadefiniert. Dies sieht der Forward-Zone-Spezifikation sehr ähnlich:
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "tosecondary"Speichern und schließen Sie die Datei, wenn Sie fertig sind.
Erstellen Sie die Forward-Zonendatei
Jetzt müssen wir die Forward-Zone-Datei erstellen. In unserer Konfiguration haben wir die Zonendatei als "example.com.zone" bezeichnet. Wir müssen eine Datei mit diesem Namen in unserem Verzeichnis/etc/nsderstellen.
Öffnen Sie diese Datei in Ihrem Texteditor mit sudo-Berechtigungen:
sudo nano /etc/nsd/example.com.zoneAls erstes müssen wir oben einige Parameter einstellen. Wir setzen den Parameter$ORIGIN, der auf die Domäne verweist, die wir im FQDN-Format konfigurieren (komplett mit dem Endpunkt). Wir möchten auch die Standard-Lebensdauer festlegen. Wir werden 1800 Sekunden oder 30 Minuten verwenden:
$ORIGIN example.com.
$TTL 1800Als nächstes benötigen wir unsere SOA oder den Beginn des Berechtigungsnachweises. Das wird so aussehen:
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)Dies definiert einige zonenweite Werte. Der Wertns1.example.com.wird verwendet, um den Domänenspeicherort eines der autorisierenden Server für diese Zone anzugeben. Mitadmin.example.com. wird eine E-Mail-Adresse angegeben, unter der die Zonenadministratoren erreichbar sind.
Die E-Mail-Adresse lautet in diesem Fall[email protected]. In einer DNS-Zonendatei muss das Symbol „@“ in einen Punkt geändert werden. Der Endpunkt ist ebenfalls wichtig, da dies immer der Fall ist, wenn ein FQDN angegeben wird.
Die Werte in Klammern definieren einige der Werte für unsere Zone. Das einzige, was wir hier erwähnen werden, ist die Seriennummer. Dieser Wertmustwird jedes Mal erhöht, wenn Sie Änderungen an der Zonendatei vornehmen. Hier demonstrieren wir mit dem Datum dieses Schreibens (2. Juli 2014) plus einer Revisionsnummer.
Als Nächstes müssen NS-Einträge verwendet werden, um die für diese Zone maßgeblichen Nameserver zu definieren. Denken Sie daran, den FQDN für Ihre Domain zu verwenden, einschließlich des Endpunkts:
IN NS ns1.example.com.
IN NS ns2.example.com.Als Nächstes müssen wir die A-Datensätze einrichten, die den Clients mitteilen, wie sie die von uns angegebenen Nameserver erreichen sollen. So ordnen Sie unsere Hostnamen ihren tatsächlichen IP-Adressen zu:
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2Schließlich möchten wir noch weitere A-Einträge für unsere anderen Hosts hinzufügen. In unserem Fall richten wir unsere Basisdomäne (example.com) und den Hostnamenwwwein, um sie unserem Webserver zuzuordnen:
@ IN A 192.0.2.3
www IN A 192.0.2.3Wenn Sie fertig sind, sollte Ihre fertige Datei folgendermaßen aussehen:
$ORIGIN example.com.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
; Name servers
IN NS ns1.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
; Additional 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
Als nächstes erstellen wir eine ähnliche Datei für unsere Reverse Zone. Beachten Sie, dass dies nur erforderlich ist, wenn Ihnen die Verantwortung für die umgekehrte Zuordnung eines Adressblocks übertragen wurde.
Erstellen Sie die Reverse-Zone-Datei, auf die Sie in Ihrernsd.conf-Datei verwiesen haben, und öffnen Sie sie mit Sudo-Berechtigungen in Ihrem Texteditor:
sudo nano /etc/nsd/192.0.2.zoneWieder beginnen wir mit der Definition der Parameter$ORIGIN und$TTL. Denken Sie diesmal daran, den Ursprung auf die Subdomainin-addr.arpafür Ihre Zone festzulegen. In unserem Fall sieht das so aus:
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800Als Nächstes müssen wir die SOA-Datensätze wie zuvor festlegen. Wir können für diese Datei ziemlich genau dieselben Werte verwenden, da für beide Zonen derselbe E-Mail- und derselbe autorisierende Nameserver verantwortlich sind. Darüber hinaus sollten die numerischen Werte auch in diesem Fall funktionieren. Denken Sie daran, die Seriennummer bei jeder Änderung zu ändern:
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)Wenn Sie fertig sind, sollte die Datei folgendermaßen aussehen:
Auch hier müssen wir die Nameserver definieren, die für die Zone maßgeblich sind. Dies werden wieder dieselben Server sein:
IN NS ns1.example.com.
IN NS ns2.example.com.Schließlich müssen wir die tatsächlichen Reverse-Domain-Zuordnungen bereitstellen, indem wir das letzte Oktett jeder IP-Adresse mithilfe von PTR-Einträgen an den FQDN des zugeordneten Hosts weiterleiten:
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 folgendermaßen aussehen:
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; 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
Nachdem wir unseren Primärserver konfiguriert haben, können wir unsere Konfigurationsdatei testen und unsere Änderungen implementieren.
Sie können die Syntax der Hauptkonfigurationsdatei mit dem mitgelieferten Toolnsd-checkconfüberprüfen. Richten Sie das Tool einfach auf Ihre Hauptkonfigurationsdatei:
sudo nsd-checkconf /etc/nsd/nsd.confWenn dies sofort ohne Ausgabe zurückgegeben wird, bedeutet dies, dass die Syntax Ihrer Hauptkonfigurationsdatei gültig ist. Wenn Sie eine Fehlermeldung erhalten, überprüfen Sie die Syntax Ihrer Konfigurationsdatei, um eventuelle Fehler zu beheben.
Nachdem Sie die Prüfung ordnungsgemäß ausgeführt haben, können Sie den Dienst neu starten, indem Sie Folgendes eingeben:
sudo service nsd restartDadurch wird der NSD-Dämon gestoppt und gestartet.
Überprüfen Sie die Protokolle auf Nachrichten:
sudo tail -f /var/log/nsd.logSie sollten eine Reihe von Fehlern sehen, die so aussehen:
. . .
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: received notify response error NAME ERROR from 192.0.2.2
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: max notify send count reached, 192.0.2.2 unreachableDies liegt daran, dass NSD versucht, die Zone auf den noch nicht konfigurierten sekundären Server zu übertragen.
Konfigurieren Sie den sekundären NSD-Server
Nachdem wir den Primärserver eingerichtet haben, können wir auch den Sekundärserver bereitstellen.
Auch hier möchten wir sicherstellen, dass alle unsere SSL-Zertifikate und -Schlüssel generiert und verfügbar sind. Geben Sie dazu den folgenden Befehl ein:
sudo nsd-control-setupDadurch wird sichergestellt, dass alle für die Steuerung des Daemons erforderlichen Anmeldeinformationsdateien für uns verfügbar sind.
Konfigurieren Sie die Datei nsd.conf
Diensd.conf-Datei für den sekundären Server entspricht größtenteils der des primären Servers. Es gibt nur wenige Dinge, die wir ändern müssen. Kopieren Sie zunächst die/etc/nsd/nsd.conf-Datei des Primärservers in die/etc/nsd/nsd.conf-Datei des Sekundärservers.
Die Datei dieses sekundären Servers sollte nun folgendermaßen aussehen:
server:
do-ip4: yes
port: 53
username: nsd
zonesdir: "/etc/nsd"
logfile: "/var/log/nsd.log"
pidfile: "/run/nsd/nsd.pid"
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: "/etc/nsd/nsd_server.key"
server-cert-file: "/etc/nsd/nsd_server.pem"
control-key-file: "/etc/nsd/nsd_control.key"
control-cert-file: "/etc/nsd/nsd_control.pem"
key:
name: "demokey"
algorithm: hmac-sha256
secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="
pattern:
name: "tosecondary"
notify: 192.0.2.2 demokey
provide-xfr: 192.0.2.2 demokey
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "tosecondary"
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "tosecondary"Das ist fast genau das, was wir brauchen.
Die Abschnitteserver,remote-control undkey sind bereits vollständig konfiguriert. Das „Geheimnis“ im Abschnittmustmust entspricht dem Wert des Primärservers. Wenn Sie also den gesamten Dateiinhalt kopieren, können Sie diese Anforderung problemlos erfüllen.
Das erste, was wir ändern müssen, ist der Abschnittpattern. Der kopierte Abschnitt ist spezifisch für den Primärserver. Daher möchten wir ihn so ändern, dass er die Dinge aus Sicht des Sekundärservers anspricht.
Ändern Sie zunächst den Namen in einen aussagekräftigeren Namen. Wir werden dieselbe Konvention verwenden und diesefromprimary nennen. Wir müssen auch die darin enthaltenen Richtlinien ändern. Anstelle des Parametersnotify benötigen sekundäre Server einen Parameterallow-notify, der die Server angibt, die ihn benachrichtigen dürfen. Wir werden weiterhin denselben Schlüssel verwenden, daher müssen wir nur den Namen und die entsprechende IP-Adresse ändern.
In ähnlicher Weise müssen wir den Parameterprovide-xfr inrequest-xfr ändern. Das Format ändert sich geringfügig. Wir müssen angeben, dass wir eine AXFR-Übertragung wünschen (die einzige Art, zu der NSD-Primärdaten fähig sind), und wir müssen die IP-Adresseand der Portnummer der Primärdatenbank angeben.
Der Abschnittpattern sieht ungefähr so aus, wenn Sie fertig sind:
pattern:
name: "fromprimary"
allow-notify: 192.0.2.1 demokey
request-xfr: AXFR 192.0.2.1@53 demokeyFür die Abschnitte vonzonemüssen wir nur dieinclude-patternändern, um sie an das neue Muster anzupassen, das wir gerade erstellt haben:
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "fromprimary"
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "fromprimary"Wenn Sie fertig sind, speichern und schließen Sie die Datei.
Testen der Dateien und Neustarten des Dienstes
Da unser sekundärer Server alle seine Zonendaten durch Übertragungen vom primären Server erhält, müssen wir die Zonendateien auf diesem Host nicht konfigurieren.
Auch hier sollten wir die Syntax unserer Hauptkonfigurationsdatei überprüfen, indem wir Folgendes eingeben:
sudo nsd-checkconf /etc/nsd/nsd.confWenn Sie Fehler erhalten, müssen Sie diensd.conf-Datei erneut überprüfen, um die Syntaxprobleme zu beheben. Wenn der Befehl ohne Ausgabe zurückgegeben wird, bedeutet dies, dass Ihre Syntax in der Datei gültig ist.
Wenn Ihre Konfigurationsdatei den Test besteht, können Sie den Dienst neu starten, indem Sie Folgendes eingeben:
sudo service nsd restartÜberprüfen Sie die Protokolle, um sicherzustellen, dass alles in Ordnung ist:
sudo tail -f /var/log/nsd.logDelegieren Sie die Berechtigung an Ihre Nameserver
Jetzt sollten Ihre autorisierenden NSD-Server konfiguriert und bereit sein, DNS-Informationen zu Ihrer Domain bereitzustellen. Wir müssen Ihre Domain noch konfigurieren, damit sie Ihre Nameserver verwenden kann.
Dazu müssen Sie einige Einstellungen unter dem Registrar vornehmen, bei dem Sie Ihren Domainnamen gekauft haben. Einige der Begriffe und sicherlich die Benutzeroberfläche variieren von Registrar zu Registrar, aber Sie sollten in der Lage sein, die Einstellungen zu finden, wenn Sie genau hinschauen.
Ich werde zeigen, wie dies mitNamecheap, einem ziemlich normalen Domainnamen-Registrar, gemacht wird.
Wir müssen Ihre Nameserver so anpassen, dass wirglue records beim übergeordneten Element der Domäne festlegen können. Dies ist immer dann erforderlich, wenn die Nameserverwithinder Domäne selbst sind.
Wenn Sie eine Subdomain delegieren (z. B.example.com aus der Domänecom), müssen Sie die Nameserver angeben, die für die Domäne maßgeblich sind. Wenn sich die Nameserver innerhalb der Domäne befinden, müssen Siealso einen Klebedatensatz enthalten, der einfach ein A-Datensatz für jeden der Nameserver ist, die für die delegierte Zone maßgeblich sind.
Wir brauchen dies, weil DNS-Lookups in einer Schleife hängen bleiben würden, wenn die Leimdatensätze nicht enthalten wären. Kunden würden unseren Registrar fragen, wer für die Domainexample.com maßgeblich ist, und unser Registrar würde (nachdem wir dies konfiguriert haben)ns1.example.com undns2.example.com zurückgeben. Wenn wir keine A-Datensätze zur Auflösung dieser in IP-Adressen aufnehmen, kann der Client diesen Punkt nie überschreiten. Es hätte keine Möglichkeit, die IP-Adressen der benötigten Nameserver zu finden, da diese normalerweise in den Nameservern selbst definiert sind.
Der Speicherort in der Benutzeroberfläche des Registrars, an dem Sie die zugehörigen IP-Adressen Ihrer Nameserverandkonfigurieren können, hängt von Ihrem Anbieter ab. In Namecheap gibt es einen Abschnitt namens "Nameserver Registration", in dem Sie die IP-Adressen von Nameservern zum Erstellen von Leimdatensätzen festlegen können:
Hier können Sie die Nameserver einrichten und einer bestimmten IP-Adresse zuordnen:
Wenn Sie damit fertig sind, müssen Sie die aktiven Nameserver festlegen, die für Ihre Domain verwendet werden. Namecheap verfügt über eine Option namens "Domain Name Server Setup", die dies ermöglicht:
In der Oberfläche, die Sie bei Auswahl dieser Option erhalten, können Sie die Hostnamen Ihrer gerade registrierten Nameserver eingeben:
Die Änderungen, die Sie bei Ihrem Registrar vornehmen, können einige Zeit in Anspruch nehmen, um sie zu verbreiten. Die Daten benötigen außerdem zusätzliche Zeit, um sich auf den restlichen DNS-Servern der Welt zu verbreiten. In der Regel sollte dieser Vorgang in den nächsten 24 bis 48 Stunden abgeschlossen sein.
Fazit
Wenn Sie dieses Handbuch verwenden, sollten Sie jetzt über einen primären und einen sekundären autorisierenden DNS-Server verfügen, auf denen DNS-Informationen zu Ihren Domänen bereitgestellt werden können. Im Gegensatz zu Bind ist NSD für autorisierendes Verhalten bei hoher Leistung optimiert, sodass Sie eine höhere Leistung erzielen können, die speziell auf Ihre Bedürfnisse abgestimmt ist.