BIND als privaten Netzwerk-DNS-Server unter Ubuntu 22.04 konfigurieren

Einführung

Ein wichtiger Teil der Verwaltung von Serverkonfigurationen und Infrastruktur besteht darin, einen Weg zu finden, Netzwerkschnittstellen und IP-Adressen nach Namen zu finden. Eine Möglichkeit, dies zu tun, besteht darin, ein ordnungsgemäßes Domain Name System (DNS) einzurichten. Durch die Verwendung von voll qualifizierten Domänennamen (FQDNs) anstelle von IP-Adressen zur Angabe von Netzwerkadressen wird die Konfiguration von Diensten und Anwendungen optimiert und die Wartbarkeit von Konfigurationsdateien erhöht. Die Einrichtung Ihres eigenen DNS für Ihr privates Netzwerk ist eine großartige Möglichkeit, das Management Ihrer Server zu verbessern.

In diesem Tutorial richten Sie einen internen DNS-Server mit zwei Ubuntu 22.04-Servern ein. Sie verwenden die BIND-Nameserver-Software (BIND9), um private Hostnamen und private IP-Adressen aufzulösen. Dies bietet eine zentrale Möglichkeit, Ihre internen Hostnamen und privaten IP-Adressen zu verwalten, was unverzichtbar ist, wenn Ihre Umgebung auf mehr als nur wenige Hosts erweitert wird.

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie die folgende Infrastruktur. Stellen Sie sicher, dass Sie jeden Server im selben Rechenzentrum mit aktivierter privater Netzwerkanbindung erstellen:

• A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
• (Empfohlen) Ein zweiter Ubuntu 22.04-Server, der als sekundärer DNS-Server ns2 dient.
• Mindestens ein zusätzlicher Server. Dieser Leitfaden geht davon aus, dass Sie zwei zusätzliche Server haben, die als Client-Server bezeichnet werden. Diese Client-Server müssen im selben Rechenzentrum erstellt werden, in dem sich Ihre DNS-Server befinden.

Auf jedem dieser Server konfigurieren Sie einen administrativen sudo-Benutzer und richten eine Firewall ein, indem Sie unserem Anleitung zum Einrichten eines Ubuntu 22.04-Initialservers folgen.

Wenn Sie mit DNS-Konzepten nicht vertraut sind, empfehlen wir Ihnen, zumindest die ersten drei Teile unserer Einführung in die DNS-Verwaltung

Beispielinfrastruktur und -ziele

Für diesen Artikel gehen wir von folgendem aus:

• Sie haben zwei Server, die als Ihre DNS-Nameserver bezeichnet werden. In diesem Leitfaden werden diese als ns1 und ns2 bezeichnet.
• Du hast zwei zusätzliche Client-Server, die die von dir erstellte DNS-Infrastruktur nutzen werden, die in diesem Handbuch als host1 und host2 bezeichnet werden. Du kannst beliebig viele Client-Server hinzufügen.
• Alle diese Server befinden sich im selben Rechenzentrum. Dieses Tutorial geht davon aus, dass dieses Rechenzentrum nyc3 genannt wird.
• Alle diese Server haben das private Netzwerk aktiviert und befinden sich im Subnetz 10.128.0.0/16 (du musst dies wahrscheinlich für deine Server anpassen).
• Alle Server sind mit einem Projekt verbunden, das unter example.com läuft. Dieses Handbuch erläutert, wie du ein internes privates DNS-System einrichtest, sodass du einen beliebigen Domainnamen anstelle von example.com verwenden kannst. Die DNS-Server versuchen immer zuerst, Anfragen intern zu routen, das heißt, sie versuchen nicht, auf die angegebene Domain im öffentlichen Internet zuzugreifen. Die Verwendung einer eigenen Domain kann jedoch Konflikte mit öffentlich routbaren Domänen vermeiden.

Mit diesen Annahmen im Hinterkopf wird in diesem Handbuch für die Beispiele ein Namensschema verwendet, das auf der Subdomäne nyc3.example.com basiert, um auf das Beispiel-Private-Subnetz oder die Zone zu verweisen. Daher wird der private Fully-Qualified Domain Name (FQDN) von host1 host1.nyc3.example.com sein. Die folgende Tabelle enthält die relevanten Details, die in Beispielen in diesem Handbuch verwendet werden:

Am Ende dieses Tutorials wirst du einen primären DNS-Server, ns1, und optional einen sekundären DNS-Server, ns2, haben, der als Backup dient.

Wenn du diesem Tutorial folgst, gibt es Zeiten, in denen du bestimmte Befehle auf einem spezifischen Server in dieser Einrichtung ausführen musst. Alle Befehle, die auf ns1 ausgeführt werden müssen, haben einen blauen Hintergrund, so wie dies:

Ebenso werden alle Befehle, die auf ns2 ausgeführt werden müssen, einen roten Hintergrund haben:

Und alle Befehle, die auf einem deiner Client-Server ausgeführt werden müssen, werden einen grünen Hintergrund haben:

Und alle Befehle, die auf mehreren Servern ausgeführt werden müssen, werden einen standardmäßigen marineblauen Hintergrund haben:

Zuletzt sei darauf hingewiesen, dass jedes Mal, wenn ein Befehl oder Code-Block Text enthält, der so markiert ist, dies bedeutet, dass dieser Text wichtig ist. Diese Art der Hervorhebung wird im gesamten Leitfaden verwendet, um Details zu kennzeichnen, die durch eigene Einstellungen ersetzt oder in einer Konfigurationsdatei modifiziert oder hinzugefügt werden müssen. Zum Beispiel, wenn ein Beispiel etwas wie host1.nyc3.example.com enthält, ersetzen Sie es durch den FQDN Ihres eigenen Servers.

Beginnen wir mit der Installation von BIND auf beiden DNS-Servern, ns1 und ns2.

Schritt 1 — BIND auf DNS-Servern installieren

Auf beiden DNS-Servern, ns1 und ns2, aktualisieren Sie den apt-Paket-Cache, indem Sie Folgendes eingeben:

sudo apt update

Installieren Sie dann BIND auf jeder Maschine:

sudo apt install bind9 bind9utils bind9-doc

Das private Netzwerk von DigitalOcean verwendet ausschließlich IPv4. Wenn dies bei Ihnen der Fall ist, stellen Sie BIND auf den IPv4-Modus ein. Bearbeiten Sie auf beiden Servern die Standardkonfigurationsdatei von named mit Ihrem bevorzugten Texteditor. Das folgende Beispiel verwendet nano:

sudo nano /etc/default/named

Fügen Sie -4 zum Ende des OPTIONS-Parameters hinzu:

. . .
OPTIONS="-u bind -4"

Speichern Sie die Datei und schließen Sie sie, wenn Sie fertig sind. Wenn Sie nano zum Bearbeiten der Datei verwendet haben, können Sie dies tun, indem Sie CTRL + X, Y, dann ENTER drücken.

Starten Sie BIND neu, um die Änderungen zu implementieren:

sudo systemctl restart bind9

Jetzt, da BIND installiert ist, konfigurieren wir den primären DNS-Server.

Schritt 2 — Konfigurieren des primären DNS-Servers

Die Konfiguration von BIND besteht aus mehreren Dateien, die aus der Hauptkonfigurationsdatei named.conf eingeschlossen werden. Diese Dateinamen beginnen mit named, weil das der Name des Prozesses ist, den BIND ausführt (wobei named eine Abkürzung für „Name daemon“ ist, wie in „Domain Name Daemon“). Wir beginnen mit der Konfiguration der Datei named.conf.options.

Konfigurieren der Optionsdatei

Auf ns1 öffnen Sie die Datei named.conf.options zum Bearbeiten:

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

Über dem vorhandenen options-Block erstellen Sie einen neuen ACL (Zugriffskontrollliste)-Block namens trusted. Hier definieren Sie eine Liste von Clients, von denen aus Sie rekursive DNS-Abfragen zulassen möchten (d. h. Ihre Server, die sich im selben Rechenzentrum wie ns1 befinden). Fügen Sie die folgenden Zeilen hinzu, um ns1, ns2, host1 und host2 zu Ihrer Liste vertrauenswürdiger Clients hinzu, wobei Sie die Beispiel-Privat-IP-Adressen durch die Ihrer eigenen Server ersetzen:

acl "trusted" {
        10.128.10.11;    # ns1 
        10.128.20.12;    # ns2
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

Jetzt, da Sie Ihre Liste vertrauenswürdiger DNS-Clients haben, können Sie den options-Block bearbeiten. Dies ist aktuell der Beginn des Blocks:

        . . .
};

options {
        directory "/var/cache/bind";
        . . .
}

Unter der directory-Direktive fügen Sie die markierten Konfigurationszeilen hinzu (und ersetzen Sie die entsprechende ns1-Privat-IP-Adresse ein):

        . . .

};

options {
        directory "/var/cache/bind";
        
        recursion yes;                 # enables recursive queries
        allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
        listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
        allow-transfer { none; };      # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

        . . .
};

Beachten Sie den forwarders-Block, der zwei IP-Adressen enthält: 8.8.8.8 und 8.8.4.4. Dieser Block definiert forwarders, einen speziellen Mechanismus, den BIND verwendet, um den Datenverkehr über Verbindungen zu externen Nameservern zu reduzieren. BIND kann auch Forwarders verwenden, um Abfragen von Servern zu ermöglichen, die keinen direkten Zugang zum Internet haben. Dies kann dazu beitragen, die Antwortzeiten auf diese Abfragen zu verkürzen, indem die Last im lokalen Netzwerk reduziert wird.

Die beiden IP-Adressen in diesem Block repräsentieren die öffentlichen DNS-Auflösungsstellen von Google, aber die IP-Adresse eines öffentlichen rekursiven Nameservers funktioniert hier genauso. Sie könnten beispielsweise die IP-Adresse des DNS-Servers von Cloudflare (1.1.1.1) verwenden.

Wenn Sie fertig sind, speichern und schließen Sie die Datei `named.conf.options`. Die obige Konfiguration legt fest, dass nur Ihre eigenen Server (die vertrauenswürdigen) Ihren DNS-Server für externe Domänen abfragen können.

Als nächstes geben Sie Ihre DNS-Zonen an, indem Sie die Datei `named.conf.local` konfigurieren.

Konfigurieren der lokalen Datei

Öffnen Sie auf ns1 die Datei `named.conf.local` zum Bearbeiten:

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

Abgesehen von einigen Kommentaren wird die Datei leer sein. Hier geben Sie Ihre Vorwärts- und Rückwärtszonen an. DNS-Zonen definieren einen spezifischen Bereich zur Verwaltung und Definition von DNS-Einträgen. Da die Beispieldomänen dieses Leitfadens alle innerhalb der Subdomäne `nyc3.example.com` liegen, verwenden wir diese als unsere Vorwärtszone. Da sich die privaten IP-Adressen unserer Beispielserver jeweils im IP-Bereich `10.128.0.0/16` befinden, wird das folgende Beispiel eine Rückwärtszone einrichten, damit wir Rückwärtsauflösungen in diesem Bereich definieren können.

Fügen Sie die Vorwärtszone mit den folgenden Zeilen hinzu, wobei Sie den Zonennamen durch Ihren eigenen und die private IP-Adresse des sekundären DNS-Servers im `allow-transfer`-Direktiv substituieren:

. . .

zone "nyc3.example.com" {
    type primary;
    file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
    allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
};

Annehmen, dass unser privates Subnetz `10.128.0.0/16` ist, fügen Sie die Rückwärtszone mit den folgenden Zeilen hinzu (beachten Sie, dass unser Rückwärtszonenname mit `128.10` beginnt, was die Umkehrung der Oktette von `10.128` ist):

    . . .
};

zone "128.10.in-addr.arpa" {
    type primary;
    file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
    allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
};

Wenn Ihre Server mehrere private Subnetze umfassen, aber sich im selben Rechenzentrum befinden, stellen Sie sicher, dass für jedes einzelne Subnetz eine zusätzliche Zone und Zonendatei angegeben sind. Wenn Sie alle gewünschten Zonen hinzugefügt haben, speichern Sie die named.conf.local-Datei und schließen Sie sie.

Jetzt, da Ihre Zonen in BIND angegeben sind, müssen Sie die entsprechenden Vorwärts- und Rückwärtszonen-Dateien erstellen.

Erstellen der Vorwärts-Zonendatei

Die Vorwärts-Zonendatei ist der Ort, an dem Sie DNS-Einträge für Vorwärts-DNS-Lookups definieren. Wenn also der DNS eine Namensabfrage, beispielsweise host1.nyc3.example.com, erhält, wird er in der Vorwärts-Zonendatei nach dem zugehörigen privaten IP-Adresse von host1 suchen.

Erstellen Sie das Verzeichnis, in dem sich Ihre Zonendateien befinden werden. Gemäß der Konfiguration der named.conf.local sollte dieser Ort /etc/bind/zones sein:

sudo mkdir /etc/bind/zones

Wir werden unsere Beispiel-Vorwärts-Zonendatei auf der Muster-db.local-Zonendatei basieren. Kopieren Sie sie mit den folgenden Befehlen an den richtigen Ort:

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

Bearbeiten Sie nun Ihre Vorwärts-Zonendatei:

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

Zu Beginn wird sie Inhalte wie die folgenden enthalten:

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

Zuerst müssen Sie den SOA-Eintrag bearbeiten. Ersetzen Sie das erste localhost durch den FQDN von ns1 und ersetzen Sie dann root.localhost durch admin.nyc3.example.com. Jedes Mal, wenn Sie eine Zonendatei bearbeiten, müssen Sie den Serial-Wert erhöhen, bevor Sie den named-Prozess neu starten. Hier erhöhen Sie ihn auf 3:

. . .
;
$TTL    604800
@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

Als Nächstes löschen Sie die drei Einträge am Ende der Datei (nach dem SOA-Eintrag). Wenn Sie nicht sicher sind, welche Zeilen gelöscht werden sollen, sind sie in dem vorherigen Beispiel mit Kommentaren markiert, die delete this line lesen.

Am Ende der Datei fügen Sie Ihre Nameserver-Einträge mit den folgenden Zeilen hinzu (ersetzen Sie die Namen durch Ihre eigenen). Beachten Sie, dass die zweite Spalte angibt, dass es sich um NS-Einträge handelt:

. . .

; name servers - NS records
    IN      NS      ns1.nyc3.example.com.
    IN      NS      ns2.nyc3.example.com.

Jetzt fügen Sie die A-Einträge für Ihre Hosts hinzu, die in diese Zone gehören. Dazu gehören alle Server, deren Namen Sie mit .nyc3.example.com enden möchten (ersetzen Sie die Namen und privaten IP-Adressen). Unter Verwendung unserer Beispielnamen und privaten IP-Adressen fügen wir A-Einträge für ns1, ns2, host1 und host2 hinzu, wie folgt:

. . .

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

Unsere abschließende Beispiel-Vorwärtszonen-Datei wird den folgenden Inhalt enthalten:

$TTL    604800
@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                  3     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;
; name servers - NS records
     IN      NS      ns1.nyc3.example.com.
     IN      NS      ns2.nyc3.example.com.

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

Speichern und schließen Sie die Datei db.nyc3.example.com.

Jetzt gehen wir zur Erstellung der Rückwärts-Zonendatei(en) über.

Erstellen der Rückwärts-Zonendatei(en)

Reverse-Zonen-Dateien sind Dateien, in denen Sie DNS-PTR-Einträge für Reverse-DNS-Nachschlagen definieren. Wenn das DNS also eine Anfrage per IP-Adresse erhält, zum Beispiel 10.128.100.101, sucht es in den Reverse-Zonen-Dateien, um den entsprechenden FQDN, in diesem Fall host1.nyc3.example.com, aufzulösen.

Auf ns1 erstellen Sie für jede im named.conf.local-Datei angegebene Reverse-Zone eine Reverse-Zonen-Datei. Unsere Beispiel-Reverse-Zonen-Dateien basieren auf der Musterzone db.127. BIND verwendet diese Datei, um Informationen für die lokale Loopback-Schnittstelle zu speichern; 127 ist der erste Oktett der IP-Adresse, die localhost darstellt (127.0.0.1). Kopieren Sie diese Datei mit den folgenden Befehlen an den richtigen Speicherort (ersetzen Sie den Zieldateinamen, damit er Ihrer Reverse-Zonen-Definition entspricht):

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

Bearbeiten Sie die Reverse-Zonen-Datei, die der in named.conf.local definierten Reverse-Zone bzw. Reverse-Zonen entspricht:

sudo nano /etc/bind/zones/db.10.128

Zunächst enthält die Datei Inhalte wie folgt:

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

Genauso wie bei der Vorwärts-Zonen-Datei möchten Sie den SOA-Eintrag bearbeiten und den Wert serial erhöhen:

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

Löschen Sie nun die beiden Einträge am Ende der Datei (nach dem SOA-Eintrag). Wenn Sie nicht sicher sind, welche Zeilen gelöscht werden sollen, sind sie in unserem vorherigen Beispiel mit einem Kommentar delete this line markiert.

Fügen Sie am Ende der Datei Ihre Nameserver-Einträge mit den folgenden Zeilen hinzu (ersetzen Sie die Namen durch Ihre eigenen). Beachten Sie, dass in der zweiten Spalte angegeben ist, dass es sich um NS-Einträge handelt:

. . .

; name servers - NS records
      IN      NS      ns1.nyc3.example.com.
      IN      NS      ns2.nyc3.example.com.

Dann fügen Sie PTR-Datensätze für alle Ihre Server hinzu, deren IP-Adressen sich im Subnetz der Zonendatei befinden, die Sie bearbeiten. In unserem Beispiel umfasst dies alle unsere Hosts, da sie sich alle im Subnetz 10.128.0.0/16 befinden. Beachten Sie, dass die erste Spalte aus den letzten beiden Oktetten der privaten IP-Adressen Ihrer Server in umgekehrter Reihenfolge besteht. Stellen Sie sicher, dass Sie Namen und private IP-Adressen austauschen, um Ihren Servern zu entsprechen:

. . .

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Ihre endgültige Beispiel-Zonendatei für die Umkehrung wird ähnlich wie folgt sein:

$TTL    604800
@       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; name servers
      IN      NS      ns1.nyc3.example.com.
      IN      NS      ns2.nyc3.example.com.

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Speichern Sie die Umkehrungszonendatei und schließen Sie sie. Wenn Sie weitere Umkehrungszonendateien hinzufügen müssen, wiederholen Sie diesen Abschnitt.

Sie haben Ihre Dateien bearbeitet, also können Sie als nächstes Ihre Dateien auf Fehler überprüfen.

Überprüfen der BIND-Konfigurationssyntax

Führen Sie den folgenden Befehl aus, um die Syntax der named.conf*-Dateien zu überprüfen:

sudo named-checkconf

Wenn Ihre benannten Konfigurationsdateien keine Syntaxfehler enthalten, werden keine Fehlermeldungen angezeigt, und Sie kehren zu Ihrem Shell-Prompt zurück. Wenn Probleme mit Ihren Konfigurationsdateien auftreten, überprüfen Sie die Fehlermeldung und den Abschnitt Primären DNS-Server konfigurieren, und versuchen Sie es erneut mit named-checkconf.

Der Befehl named-checkzone kann verwendet werden, um die Korrektheit Ihrer Zonendateien zu überprüfen. Das erste Argument gibt den Zonennamen an, und das zweite Argument gibt die entsprechende Zonendatei an, die beide in named.conf.local definiert sind.

Zum Beispiel, um die Konfiguration der Vorwärtszone nyc3.example.com zu überprüfen, führen Sie den folgenden Befehl aus (ändern Sie die Namen entsprechend Ihrer Vorwärtszone und Datei):

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

Output
zone nyc3.example.com/IN: loaded serial 3
OK

Und um die Konfiguration der Rückwärtszone 128.10.in-addr.arpa zu überprüfen, führen Sie den folgenden Befehl aus (ändern Sie die Zahlen entsprechend Ihrer Rückwärtszone und Datei):

sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

Wenn alle Konfigurations- und Zonendateien keine Fehler enthalten, sind Sie bereit, den BIND-Dienst neu zu starten.

Neustart von BIND

Neustarten von BIND:

sudo systemctl restart bind9

Wenn Sie die UFW-Firewall konfiguriert haben, öffnen Sie den Zugriff auf BIND, indem Sie folgendes eingeben:

sudo ufw allow Bind9

Ihr primärer DNS-Server ist jetzt eingerichtet und bereit, auf DNS-Anfragen zu antworten. Lassen Sie uns zur Konfiguration des sekundären DNS-Servers übergehen.

Schritt 3 — Konfiguration des sekundären DNS-Servers

In den meisten Umgebungen ist es eine gute Idee, einen sekundären DNS-Server einzurichten, der auf Anfragen antwortet, wenn der primäre Server nicht verfügbar ist. Glücklicherweise ist die Konfiguration des sekundären DNS-Servers viel weniger kompliziert als die Einrichtung des Primärservers.

Auf ns2 bearbeiten Sie die Datei named.conf.options:

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

Am Anfang der Datei fügen Sie die ACL mit den privaten IP-Adressen aller vertrauenswürdigen Server hinzu:

acl "trusted" {
        10.128.10.11;   # ns1
        10.128.20.12;   # ns2 
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

Unterhalb der Anweisung directory fügen Sie die folgenden Zeilen hinzu:

    . . .

        recursion yes;
        allow-recursion { trusted; };
        listen-on { 10.128.20.12; };      # ns2 private IP address
        allow-transfer { none; };          # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

    . . .

Speichern und schließen Sie die Datei named.conf.options. Diese Datei sollte identisch mit der named.conf.options-Datei von ns1 sein, außer dass sie so konfiguriert sein sollte, dass sie auf die private IP-Adresse von ns2 hört.

Bearbeiten Sie nun die Datei named.conf.local:

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

Definieren Sie sekundäre Zonen, die den primären Zonen auf dem primären DNS-Server entsprechen. Beachten Sie, dass der Typ secondary ist, die Datei keinen Pfad enthält und es eine Anweisung primaries gibt, die auf die private IP-Adresse des primären DNS-Servers gesetzt werden sollte. Wenn Sie mehrere Reverse-Zonen auf dem primären DNS-Server definiert haben, stellen Sie sicher, dass Sie sie alle hier hinzufügen:

zone "nyc3.example.com" {
    type secondary;
    file "db.nyc3.example.com";
    primaries { 10.128.10.11; };  # ns1 private IP
};

zone "128.10.in-addr.arpa" {
    type secondary;
    file "db.10.128";
    primaries { 10.128.10.11; };  # ns1 private IP
};

Speichern und schließen Sie dann die Datei named.conf.local.

Führen Sie den folgenden Befehl aus, um die Gültigkeit Ihrer Konfigurationsdateien zu überprüfen:

sudo named-checkconf

Wenn dieser Befehl keine Fehler zurückgibt, starten Sie BIND neu:

sudo systemctl restart bind9

Ändern Sie dann die UFW-Firewallregeln, um DNS-Verbindungen zum Server zuzulassen:

sudo ufw allow Bind9

Mit diesem haben Sie nun primäre und sekundäre DNS-Server für die Auflösung von privaten Netzwerknamen und IP-Adressen. Jetzt müssen Sie Ihre Client-Server so konfigurieren, dass sie Ihre privaten DNS-Server verwenden.

Schritt 4 — Konfigurieren von DNS-Clients

Bevor alle Ihre Server im trusted-ACL Ihre DNS-Server abfragen können, müssen Sie jeden von ihnen so konfigurieren, dass er ns1 und ns2 als Nameserver verwendet.

Angenommen, Ihre Client-Server laufen unter Ubuntu, müssen Sie herausfinden, welches Gerät mit Ihrem privaten Netzwerk verbunden ist. Sie können dies tun, indem Sie das private Subnetz mit dem Befehl ip address abfragen. Führen Sie den folgenden Befehl auf jedem Ihrer Client-Maschinen aus und ersetzen Sie das markierte Subnetz durch Ihr eigenes:

ip address show to 10.128.0.0/16

Output
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enp0s4
    altname ens4
    inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
       valid_lft forever preferred_lft forever

In diesem Beispiel ist die private Schnittstelle eth1. Die Beispiele in diesem Abschnitt beziehen sich auf eth1 als die private Schnittstelle, aber Sie sollten diese Beispiele ändern, um die privaten Schnittstellen Ihrer eigenen Server widerzuspiegeln.

Auf Ubuntu 22.04 wird die Netzwerkkonfiguration mit Netplan konfiguriert, einer Abstraktion, die es Ihnen ermöglicht, standardisierte Netzwerkkonfigurationen zu schreiben und auf kompatible Backend-Netzwerksoftware anzuwenden. Um DNS zu konfigurieren, müssen Sie eine Netplan-Konfigurationsdatei schreiben.

Erstellen Sie eine neue Datei in /etc/netplan mit dem Namen 00-private-nameservers.yaml:

sudo nano /etc/netplan/00-private-nameservers.yaml

Innerhalb fügen Sie bitte folgende Inhalte hinzu. Sie müssen die Schnittstelle des privaten Netzwerks, die Adressen Ihrer \(\text{ns1}\) und \(\text{ns2}\) DNS-Server sowie die DNS-Zone ändern: \(\text{

network:
    version: 2
    ethernets:
        eth1:                                    # Private network interface
            nameservers:
                addresses:
                - 10.128.10.11                # Private IP for ns1
                - 10.132.20.12                # Private IP for ns2
                search: [ nyc3.example.com ]    # DNS zone

}\) Speichern und schließen Sie die Datei, wenn Sie fertig sind. \(\text{

}\) Als nächstes teilen Sie Netplan mit, dass es versuchen soll, die neue Konfigurationsdatei zu verwenden, indem Sie netplan try verwenden. Wenn es Probleme gibt, die einen Verlust der Netzwerkverbindung verursachen, wird Netplan automatisch die Änderungen nach einem Timeout zurückrollen. \(\text{

sudo netplan try

Output
Warning: Stopping systemd-networkd.service, but it can still be activated by:
  systemd-networkd.socket
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 120 seconds

}\) Wenn der Countdown am unteren Rand korrekt aktualisiert wird, ist die neue Konfiguration mindestens funktionsfähig genug, um Ihre SSH-Verbindung nicht zu unterbrechen. Drücken Sie ENTER, um die neue Konfiguration zu akzeptieren. \(\text{

}\) Überprüfen Sie nun den DNS-Resolver des Systems, um festzustellen, ob Ihre DNS-Konfiguration angewendet wurde. \(\text{

sudo resolvectl status

}\) Scrollen Sie nach unten, bis Sie den Abschnitt für Ihre private Netzwerkschnittstelle finden. Die privaten IP-Adressen Ihrer DNS-Server sollten zuerst aufgeführt sein, gefolgt von einigen Rückfallwerten. Ihre Domain sollte nach DNS Domain aufgeführt sein: \(\text{

Output
. . .

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
       DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
        DNS Domain: nyc3.example.com

}\) Ihr Ubuntu-Client ist nun konfiguriert, um Ihre internen DNS-Server zu verwenden.

Schritt 5 — Testen von Clients

Verwenden Sie nslookup, um zu testen, ob Ihre Clients Ihre Nameserver abfragen können. Sie sollten dies auf allen Clients durchführen können, die Sie konfiguriert haben und sich im trusted-ACL befinden.

Sie können damit beginnen, eine Vorwärtssuche durchzuführen.

Vorwärtssuche

Um eine Vorwärtssuche durchzuführen und die IP-Adresse von host1.nyc3.example.com abzurufen, führen Sie den folgenden Befehl aus:

nslookup host1

Die Abfrage von host1 erweitert sich zu host1.nyc3.example.com, da die search-Option auf Ihre private Subdomain eingestellt ist und DNS-Anfragen versuchen werden, auf dieser Subdomain zu suchen, bevor sie den Host anderswo suchen. Der vorherige Befehl gibt eine Ausgabe wie folgt zurück:

Output
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   host1.nyc3.example.com
Address: 10.128.100.101

Anschließend können Sie Rückwärtssuchen überprüfen.

Rückwärtssuche

Um die Rückwärtssuche zu testen, fragen Sie den DNS-Server mit der privaten IP-Adresse von host1 ab:

nslookup 10.128.100.101

Dies sollte eine Ausgabe wie folgt zurückgeben:

Output
11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

Authoritative answers can be found from:

Wenn alle Namen und IP-Adressen die richtigen Werte auflösen, bedeutet das, dass Ihre Zonendateien ordnungsgemäß konfiguriert sind. Wenn Sie unerwartete Werte erhalten, überprüfen Sie die Zonendateien auf Ihrem primären DNS-Server (z.B. db.nyc3.example.com und db.10.128).

Als abschließender Schritt wird dieses Tutorial erklären, wie Sie Ihre Zonendatensätze pflegen können.

Schritt 6 — Pflege von DNS-Einträgen

Da Sie nun über ein funktionierendes internes DNS verfügen, müssen Sie Ihre DNS-Einträge pflegen, damit sie Ihre Serverumgebung genau widerspiegeln.

Hinzufügen eines Hosts zu DNS

Immer wenn Sie einen Host zu Ihrer Umgebung hinzufügen (im selben Rechenzentrum), sollten Sie ihn zu DNS hinzufügen. Hier ist eine Liste von Schritten, die Sie befolgen müssen:

Primärer Nameserver

• Forward-Zonendatei: Fügen Sie einen A-Eintrag für den neuen Host hinzu und erhöhen Sie den Wert von Serial
• Reverse-Zonendatei: Fügen Sie einen PTR-Eintrag für den neuen Host hinzu und erhöhen Sie den Wert von Serial
• Fügen Sie die private IP-Adresse Ihres neuen Hosts zur trusted-ACL hinzu (named.conf.options)

Testen Sie Ihre Konfigurationsdateien:

sudo named-checkconf
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

Dann laden Sie BIND neu:

sudo systemctl reload bind9

Ihr primärer Server sollte jetzt für den neuen Host konfiguriert sein.

Sekundärer Nameserver

• Fügen Sie die private IP-Adresse Ihres neuen Hosts zur trusted-ACL (named.conf.options) hinzu

Überprüfen Sie die Konfigurationssyntax:

sudo named-checkconf

Dann laden Sie BIND neu:

sudo systemctl reload bind9

Ihr sekundärer Server wird jetzt Verbindungen vom neuen Host akzeptieren.

Konfigurieren Sie den neuen Host, um Ihre DNS zu verwenden

• Konfigurieren Sie /etc/resolv.conf, um Ihre DNS-Server zu verwenden
• Testen Sie mit nslookup

Entfernen eines Hosts aus dem DNS

Wenn Sie einen Host aus Ihrer Umgebung entfernen oder ihn einfach aus dem DNS entfernen möchten, entfernen Sie einfach alle Dinge, die hinzugefügt wurden, als Sie den Server zum DNS hinzugefügt haben (d. h. das Gegenteil der vorherigen Schritte).

Abschluss

Jetzt können Sie auf die Netzwerk-Schnittstellen Ihrer Server über den Namen statt über die IP-Adresse zugreifen. Dies erleichtert die Konfiguration von Diensten und Anwendungen, da Sie sich nicht mehr an die privaten IP-Adressen erinnern müssen und die Dateien leichter lesbar und verständlich sind. Außerdem können Sie Ihre Konfigurationen nun an einen neuen Server über einen zentralen Ort, Ihren primären DNS-Server, ändern, anstatt eine Vielzahl von verteilten Konfigurationsdateien bearbeiten zu müssen, was die Wartung optimiert.

Nachdem Sie Ihre interne DNS eingerichtet haben und Ihre Konfigurationsdateien private FQDNs zur Spezifizierung von Netzwerkverbindungen verwenden, ist es wichtig, dass Ihre DNS-Server ordnungsgemäß gewartet werden. Wenn beide nicht verfügbar sind, funktionieren Ihre Dienste und Anwendungen, die auf sie angewiesen sind, nicht mehr ordnungsgemäß. Aus diesem Grund wird empfohlen, Ihren DNS mit mindestens einem sekundären Server einzurichten und funktionierende Backups aller Server zu erstellen.

Wenn Sie mehr über DNS erfahren möchten, empfehlen wir Ihnen unseren Artikel Eine Einführung in die Terminologie, Komponenten und Konzepte von DNS zu lesen.