TOC

So konfigurieren Sie BIND als privaten Netzwerk-DNS-Server unter Debian 9

Einführung

Ein wichtiger Teil der Verwaltung der Serverkonfiguration und -infrastruktur besteht darin, Netzwerkschnittstellen und IP-Adressen auf einfache Weise nach Namen zu suchen, indem ein ordnungsgemäßes Domain Name System (DNS) eingerichtet wird. Die Verwendung von vollqualifizierten Domänennamen (FQDNs) anstelle von IP-Adressen zur Angabe von Netzwerkadressen vereinfacht die Konfiguration von Diensten und Anwendungen und verbessert die Wartbarkeit von Konfigurationsdateien. Das Einrichten eines eigenen DNS für Ihr privates Netzwerk ist eine hervorragende Möglichkeit, die Verwaltung Ihrer Server zu verbessern.

In diesem Tutorial wird beschrieben, wie Sie mit der BIND-Nameserver-Software (BIND9) unter Debian 9 einen internen DNS-Server einrichten, mit dem Ihre Server private Hostnamen und private IP-Adressen auflösen können. Auf diese Weise können Sie Ihre internen Hostnamen und privaten IP-Adressen zentral verwalten. Dies ist unverzichtbar, wenn Ihre Umgebung auf mehrere Hosts erweitert wird.

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie die folgende Infrastruktur. Erstellen Sie jeden Server * im selben Datencenter * mit * https://www.digitalocean.com/docs/networking/private-networking/quickstart/ [privates Netzwerk aktiviert] *:

  • Ein neuer Debian 9-Server als primärer DNS-Server, * ns1 *

  • (Empfohlen) Ein zweiter Debian 9-Server als sekundärer DNS-Server, * ns2 *

  • Zusätzliche Server im selben Datencenter, die Ihre DNS-Server verwenden

Konfigurieren Sie auf jedem dieser Server den Administratorzugriff über einen "+ sudo +" - Benutzer und eine Firewall, indem Sie unserer Debian 9 folgen Anleitung zur Ersteinrichtung des Servers.

Wenn Sie mit DNS-Konzepten nicht vertraut sind, sollten Sie mindestens die ersten drei Teile unserer Einführung in die DNS-Verwaltung lesen .

Beispiel Infrastruktur und Ziele

Für die Zwecke dieses Artikels gehen wir von Folgendem aus:

  • Wir haben zwei Server, die als unsere DNS-Nameserver festgelegt werden. In diesem Handbuch werden diese als * ns1 * und * ns2 * bezeichnet.

  • Wir haben zwei zusätzliche Client-Server, die die von uns erstellte DNS-Infrastruktur verwenden. Wir werden diese * host1 * und * host2 * in diesem Handbuch nennen. Sie können beliebig viele für Ihre Infrastruktur hinzufügen.

  • Alle diese Server befinden sich im selben Datencenter. Wir gehen davon aus, dass dies das * nyc3 * -Datencenter ist.

  • Für alle diese Server ist das private Netzwerk aktiviert (und sie befinden sich im Subnetz "+ 10.128.0.0 / 16 +". Sie müssen dies wahrscheinlich für Ihre Server anpassen).

  • Alle Server sind mit einem Projekt verbunden, das auf "example.com" ausgeführt wird. Da unser DNS-System vollständig intern und privat ist, müssen Sie keinen Domainnamen erwerben. Die Verwendung einer eigenen Domain kann jedoch dazu beitragen, Konflikte mit öffentlich routbaren Domains zu vermeiden.

Mit diesen Annahmen entscheiden wir, dass es sinnvoll ist, ein Namensschema zu verwenden, das "nyc3.example.com" verwendet, um auf unser privates Subnetz oder unsere private Zone zu verweisen. Daher lautet der private vollqualifizierte Domänenname (FQDN) von * host1 * * host1.nyc3.example.com *. In der folgenden Tabelle finden Sie die relevanten Details:

Host Role Private FQDN Private IP Address

ns1

Primary DNS Server

ns1.nyc3.example.com

10.128.10.11

ns2

Secondary DNS Server

ns2.nyc3.example.com

10.128.20.12

host1

Generic Host 1

host1.nyc3.example.com

10.128.100.101

host2

Generic Host 2

host2.nyc3.example.com

10.128.200.102

Note

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

Beginnen wir mit der Installation unseres primären DNS-Servers ns1.

Installieren von BIND auf DNS-Servern

Note

Aktualisieren Sie auf beiden DNS-Servern * ns1 * und * ns2 * den + apt + - Paketcache, indem Sie Folgendes eingeben:

sudo apt update

Installieren Sie nun BIND:

sudo apt install bind9 bind9utils bind9-doc

Einstellen der Bindung an den IPv4-Modus

Bevor Sie fortfahren, stellen Sie BIND auf den IPv4-Modus ein, da unser privates Netzwerk ausschließlich IPv4 verwendet. Bearbeiten Sie auf beiden Servern die Standardeinstellungsdatei + bind9 +, indem Sie Folgendes eingeben:

sudo nano /etc/default/bind9

Fügen Sie "-4" am Ende des Parameters "+ OPTIONS +" hinzu. Es sollte wie folgt aussehen:

/ etc / default / bind9

. . .
OPTIONS="-u bind "

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

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

sudo systemctl restart bind9

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

Konfigurieren des primären DNS-Servers

Die Konfiguration von BIND besteht aus mehreren Dateien, die in der Hauptkonfigurationsdatei "+ named.conf " enthalten sind. Diese Dateinamen beginnen mit " named +", da dies der Name des Prozesses ist, den BIND ausführt (kurz für "Domain Name Daemon"). Wir beginnen mit der Konfiguration der Optionsdatei.

Konfigurieren der Optionsdatei

Öffnen Sie auf * ns1 * die Datei + named.conf.options + zum Bearbeiten:

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

Erstellen Sie über dem vorhandenen "+ options +" - Block einen neuen ACL-Block (Access Control List) mit dem Namen "trusted". Hier definieren wir eine Liste von Clients, von denen wir rekursive DNS-Abfragen zulassen (d. H. Ihre Server, die sich im selben Datencenter befinden wie * ns1 *). Anhand unserer privaten IP-Beispieladressen fügen wir unserer Liste vertrauenswürdiger Clients * ns1 *, * ns2 *, * host1 * und * host2 * hinzu:

/etc/bind/named.conf.options - 1 von 3

acl "trusted" {
       ;    # ns1 - can be set to localhost
       ;    # ns2
       ;  # host1
       ;  # host2
};

options {

       . . .

Nun, da wir unsere Liste der vertrauenswürdigen DNS-Clients haben, werden wir den + options + Block bearbeiten wollen. Derzeit sieht der Beginn des Blocks folgendermaßen aus:

/etc/bind/named.conf.options - 2 von 3

       . . .
};

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

Fügen Sie unter der Direktive "+ directory +" die hervorgehobenen Konfigurationszeilen hinzu (und ersetzen Sie sie durch die richtige * ns1 * -IP-Adresse), sodass sie ungefähr so ​​aussieht:

/etc/bind/named.conf.options - 3 von 3

       . . .

};

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

                        # enables resursive queries
         # allows recursive queries from "trusted" clients
          # ns1 private IP address - listen on private network only
             # disable zone transfers by default






       . . .
};

Wenn Sie fertig sind, speichern und schließen Sie die Datei + named.conf.options +. Die obige Konfiguration gibt an, dass nur Ihre eigenen Server (die "vertrauenswürdigen") Ihren DNS-Server nach externen Domänen abfragen können.

Als Nächstes konfigurieren wir die lokale Datei, um unsere DNS-Zonen anzugeben.

Lokale Datei konfigurieren

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

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

Abgesehen von ein paar Kommentaren sollte die Datei leer sein. Hier legen wir unsere Vorwärts- und Rückwärtszonen fest. * DNS-Zonen * legen einen bestimmten Bereich für die Verwaltung und Definition von DNS-Einträgen fest. Da sich unsere Domains alle in der Subdomain "nyc3.example.com" befinden, verwenden wir diese als Forward-Zone. Da sich die privaten IP-Adressen unserer Server jeweils im IP-Bereich "+ 10.128.0.0 / 16 +" befinden, richten wir eine Reverse-Zone ein, damit wir Reverse-Lookups in diesem Bereich definieren können.

Fügen Sie die Weiterleitungszone mit den folgenden Zeilen hinzu und ersetzen Sie den Zonennamen durch Ihren eigenen und die private IP-Adresse des * sekundären DNS-Servers * in der Direktive + allow-transfer +:

/etc/bind/named.conf.local - 1 von 2

zone "" {
   type master;
   file "/etc/bind/zones/db."; # zone file path
   allow-transfer { ; };           # ns2 private IP address - secondary
};

Angenommen, unser privates Subnetz ist "+ 10.128.0.0 / 16 +", fügen Sie die umgekehrte Zone mit den folgenden Zeilen hinzu (* Beachten Sie, dass unser Name der umgekehrten Zone mit "128.10" beginnt, was die Umkehrung des Oktetts von "10.128" * bedeutet):

/etc/bind/named.conf.local - 2 von 2

   . . .
};

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

Wenn sich Ihre Server über mehrere private Subnetze erstrecken, sich jedoch im selben Datencenter befinden, müssen Sie für jedes einzelne Subnetz eine zusätzliche Zone und Zonendatei angeben. Wenn Sie alle gewünschten Zonen hinzugefügt haben, speichern und schließen Sie die Datei + named.conf.local +.

Nachdem unsere Zonen in BIND angegeben wurden, müssen die entsprechenden Vorwärts- und Rückwärtszonendateien erstellt werden.

Erstellen der Forward-Zonendatei

In der Forward-Zonendatei definieren wir DNS-Einträge für Forward-DNS-Lookups. Das heißt, wenn der DNS eine Namensabfrage empfängt, z. B. "host1.nyc3.example.com", sucht er in der Weiterleitungszonendatei, um die entsprechende private IP-Adresse von * host1 * aufzulösen.

Erstellen wir das Verzeichnis, in dem sich unsere Zonendateien befinden. Gemäß unserer * named.conf.local * -Konfiguration sollte dieser Speicherort "+ / etc / bind / zones +" sein:

sudo mkdir /etc/bind/zones

Wir werden unsere Forward-Zonendatei auf der Beispieldatei + db.local + zone basieren. Kopieren Sie es mit den folgenden Befehlen an den richtigen Speicherort:

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

Bearbeiten wir nun unsere Forward-Zone-Datei:

sudo nano /etc/bind/zones/db.

Zunächst sieht es ungefähr so ​​aus:

/etc/bind/zones/db.nyc3.example.com - original

$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

Zunächst möchten Sie den SOA-Datensatz bearbeiten. Ersetzen Sie den ersten "localhost" durch den FQDN von * ns1 * und dann "root.localhost" durch "admin.nyc3.example.com". Jedes Mal, wenn Sie eine Zonendatei bearbeiten, müssen Sie den Wert * serial * erhöhen, bevor Sie den Vorgang + named + neu starten. Wir werden es auf "3" erhöhen. Es sollte jetzt ungefähr so ​​aussehen:

/etc/bind/zones/db.nyc3.example.com - aktualisiert 1 von 3

@       IN      SOA     . .. (
                                      ; Serial

                             . . .

Löschen Sie als Nächstes die drei Datensätze am Ende der Datei (nach dem SOA-Datensatz). Wenn Sie sich nicht sicher sind, welche Zeilen gelöscht werden sollen, sind sie oben mit einem Kommentar zum Löschen dieser Zeile gekennzeichnet.

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 dies "NS" -Datensätze sind:

/etc/bind/zones/db.nyc3.example.com - aktualisiert 2 von 3

. . .

; name servers - NS records
   IN      NS      ns1..
   IN      NS      ns2..

Fügen Sie nun die A-Datensätze für Ihre Hosts hinzu, die zu dieser Zone gehören. Dies schließt jeden Server ein, dessen Name mit ".nyc3.example.com" enden soll (ersetzen Sie die Namen und privaten IP-Adressen). Anhand unserer Beispielnamen und privaten IP-Adressen fügen wir A-Datensätze für * ns1 *, * ns2 *, * host1 * und * host2 * wie folgt hinzu:

/etc/bind/zones/db.nyc3.example.com - aktualisiert 3 von 3

. . .

; name servers - A records
ns1..          IN      A
ns2..          IN      A

; 10.128.0.0/16 - A records
.        IN      A
.        IN      A

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

Unser letztes Beispiel für eine Forward Zone-Datei sieht folgendermaßen aus:

/etc/bind/zones/db.nyc3.example.com - aktualisiert

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

; name servers - A records
ns1..          IN      A
ns2..          IN      A

; 10.128.0.0/16 - A records
.        IN      A
.        IN      A

Gehen wir nun zu den Reverse-Zone-Dateien über.

Reverse-Zone-Datei (en) erstellen

In Reverse-Zone-Dateien definieren wir DNS-PTR-Einträge für Reverse-DNS-Lookups. Das heißt, wenn der DNS eine Abfrage nach der IP-Adresse "10.128.100.101" empfängt, sucht er in den Reverse-Zonendateien, um den entsprechenden vollqualifizierten Domänennamen "host1.nyc3.example.com" in diesem Fall aufzulösen .

Erstellen Sie auf * ns1 * für jede in der Datei + named.conf.local + angegebene Reverse-Zone eine Reverse-Zone-Datei. Wir werden unsere Reverse-Zone-Datei (en) auf der Beispiel-Zone-Datei + db.127 + basieren. Kopieren Sie es mit den folgenden Befehlen an den richtigen Speicherort (wobei Sie den Dateinamen des Ziels so ersetzen, dass er Ihrer Reverse-Zonendefinition entspricht):

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

Bearbeiten Sie die Reverse-Zone-Datei, die der oder den in + named.conf.local + definierten Reverse-Zone (n) entspricht:

sudo nano /etc/bind/zones/db.

Zunächst sieht es ungefähr so ​​aus:

/etc/bind/zones/db.10.128 - original

$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

Auf dieselbe Weise wie in der Forward-Zonendatei möchten Sie den SOA-Datensatz bearbeiten und den Wert * serial * erhöhen. Es sollte ungefähr so ​​aussehen:

/etc/bind/zones/db.10.128 - aktualisiert 1 von 3

@       IN      SOA     . .. (
                                      ; Serial

                             . . .

Löschen Sie nun die beiden Datensätze am Ende der Datei (nach dem SOA-Datensatz). Wenn Sie sich nicht sicher sind, welche Zeilen gelöscht werden sollen, sind sie oben mit einem Kommentar zum Löschen dieser Zeile gekennzeichnet.

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 dies "NS" -Datensätze sind:

/etc/bind/zones/db.10.128 - aktualisiert 2 von 3

. . .

; name servers - NS records
     IN      NS      ns1..
     IN      NS      ns2..

Fügen Sie dann "+ PTR " - Datensätze für alle Ihre Server hinzu, deren IP-Adressen sich im Subnetz der Zonendatei befinden, die Sie bearbeiten. In unserem Beispiel sind alle unsere Hosts eingeschlossen, 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 entsprechend Ihren Servern einsetzen:

/etc/bind/zones/db.10.128 - aktualisiert 3 von 3

. . .

; PTR Records
  IN      PTR     ns1..    ; 10.128.10.11
  IN      PTR     ns2..    ; 10.128.20.12
IN      PTR     .  ; 10.128.100.101
IN      PTR     .  ; 10.128.200.102

Speichern und schließen Sie die Reverse-Zone-Datei (wiederholen Sie diesen Abschnitt, wenn Sie weitere Reverse-Zone-Dateien hinzufügen müssen).

Unser letztes Beispiel für eine Reverse Zone-Datei sieht folgendermaßen aus:

/etc/bind/zones/db.10.128 - aktualisiert

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

; PTR Records
  IN      PTR     ns1..    ; 10.128.10.11
  IN      PTR     ns2..    ; 10.128.20.12
IN      PTR     .  ; 10.128.100.101
IN      PTR     .  ; 10.128.200.102

Wir haben die Bearbeitung unserer Dateien abgeschlossen. Als Nächstes können wir unsere Dateien auf Fehler überprüfen.

Überprüfen der BIND-Konfigurationssyntax

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

sudo named-checkconf

Wenn Ihre benannten Konfigurationsdateien keine Syntaxfehler aufweisen, kehren Sie zur Shell-Eingabeaufforderung zurück und sehen keine Fehlermeldungen. Wenn es Probleme mit Ihren Konfigurationsdateien gibt, überprüfen Sie die Fehlermeldung und den Abschnitt "Configure Primary DNS Server" (Primärer DNS-Server konfigurieren) und wiederholen Sie dann "+ named-checkconf +".

Mit dem Befehl "+ named-checkzone " können Sie die Richtigkeit Ihrer Zonendateien überprüfen. Das erste Argument gibt einen Zonennamen an, und das zweite Argument gibt die entsprechende Zonendatei an, die beide in ` named.conf.local +` definiert sind.

Um beispielsweise die Forward-Zonenkonfiguration zu überprüfen, führen Sie den folgenden Befehl aus (ändern Sie die Namen entsprechend Ihrer Forward-Zone und Datei):

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

Führen Sie den folgenden Befehl aus, um die Konfiguration der Reverse Zone ".in-addr.arpa" zu überprüfen (ändern Sie die Nummern entsprechend Ihrer Reverse Zone und Datei):

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

Wenn alle Konfigurations- und Zonendateien fehlerfrei sind, sollten Sie bereit sein, den BIND-Dienst neu zu starten.

BIND neu starten

BIND neu starten:

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 kann auf DNS-Anfragen antworten. Fahren wir mit der Erstellung des sekundären DNS-Servers fort.

Konfigurieren des sekundären DNS-Servers

In den meisten Umgebungen empfiehlt es sich, einen sekundären DNS-Server einzurichten, der auf Anforderungen reagiert, wenn der primäre Server nicht mehr verfügbar ist. Glücklicherweise ist der sekundäre DNS-Server viel einfacher zu konfigurieren.

Bearbeiten Sie auf * ns2 * die Datei + named.conf.options +:

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

Fügen Sie oben in der Datei die ACL mit den privaten IP-Adressen aller Ihrer vertrauenswürdigen Server hinzu:

/etc/bind/named.conf.options - aktualisiert 1 von 2 (sekundär)

acl "trusted" {
       ;   # ns1
       ;   # ns2 - can be set to localhost
       ;  # host1
       ;  # host2
};

options {

       . . .

Fügen Sie unter der Direktive + directory + die folgenden Zeilen hinzu:

/etc/bind/named.conf.options - aktualisiert 2 von 2 (sekundär)

       recursion yes;
       allow-recursion { trusted; };
       listen-on { ; };      # 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 genau wie die Datei "+ named.conf.options +" von * ns1 * aussehen, mit der Ausnahme, dass sie so konfiguriert sein sollte, dass sie die private IP-Adresse von * ns2 * überwacht.

Bearbeiten Sie nun die Datei + named.conf.local +:

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

Definieren Sie Slave-Zonen, die den Master-Zonen auf dem primären DNS-Server entsprechen. Beachten Sie, dass der Typ "Slave" ist, die Datei keinen Pfad enthält und die Anweisung "+ masters +" auf die private IP-Adresse des primären DNS-Servers gesetzt werden sollte. Wenn Sie im primären DNS-Server mehrere Reverse-Zonen definiert haben, müssen Sie diese hier hinzufügen:

/etc/bind/named.conf.local - aktualisiert (sekundär)

zone "" {
   type slave;
   file "db.";
   masters { ; };  # ns1 private IP
};

zone ".in-addr.arpa" {
   type slave;
   file "db.";
   masters { ; };  # ns1 private IP
};

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

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

sudo named-checkconf

Sobald das ausgecheckt ist, starte BIND neu:

sudo systemctl restart bind9

Zulassen von DNS-Verbindungen zum Server durch Ändern der UFW-Firewallregeln:

sudo ufw allow Bind9

Jetzt haben Sie 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 für die Verwendung Ihrer privaten DNS-Server konfigurieren.

DNS-Clients konfigurieren

Bevor alle Server in der "vertrauenswürdigen" ACL Ihre DNS-Server abfragen können, müssen Sie jeden für die Verwendung von * ns1 * und * ns2 * als Nameserver konfigurieren. Dieser Vorgang variiert je nach Betriebssystem, aber für die meisten Linux-Distributionen müssen Ihre Nameserver zur Datei "+ / etc / resolv.conf +" hinzugefügt werden.

Ubuntu 18.04 Clients

Unter Ubuntu 18.04 wird das Netzwerk mit Netplan konfiguriert, einer Abstraktion, mit der Sie standardisierte Netzwerkkonfigurationen schreiben und auf inkompatible Backend-Netzwerksoftware anwenden können. Um DNS zu konfigurieren, müssen wir eine Netplan-Konfigurationsdatei schreiben.

Suchen Sie zuerst das Ihrem privaten Netzwerk zugeordnete Gerät, indem Sie das private Subnetz mit dem Befehl + ip address + abfragen:

ip address show to
Output3: : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
   inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
          valid_lft forever preferred_lft forever

In diesem Beispiel lautet die private Schnittstelle "+ eth1 +".

Als nächstes erstellen Sie eine neue Datei in + / etc / netplan + mit dem Namen + 00-private-nameservers.yaml +:

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

Fügen Sie den folgenden Inhalt ein. Sie müssen die Schnittstelle des privaten Netzwerks, die Adressen Ihrer DNS-Server * ns1 * und * ns2 * sowie die DNS-Zone ändern:

/etc/netplan 00-private-nameservers.yaml

network:
   version: 2
   ethernets:
       :                                 # Private network interface
           nameservers:
               addresses:
               -                 # Private IP for ns1
               -                 # Private IP for ns2
               search: [  ]  # DNS zone

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

Als nächstes weisen Sie Netplan an, die neue Konfigurationsdatei mit + netplan try + zu verwenden. Wenn es Probleme gibt, die einen Netzwerkverlust verursachen, setzt Netplan die Änderungen nach einer Zeitüberschreitung automatisch zurück:

sudo netplan try
OutputWarning: 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 unten korrekt aktualisiert wird, ist die neue Konfiguration mindestens so funktionsfähig, dass Ihre SSH-Verbindung nicht unterbrochen wird. Drücken Sie * ENTER *, um die neue Konfiguration zu übernehmen.

Überprüfen Sie nun den DNS-Resolver des Systems, um festzustellen, ob Ihre DNS-Konfiguration angewendet wurde:

sudo systemd-resolve --status

Scrollen Sie nach unten, bis Sie den Abschnitt für Ihre private Netzwerkschnittstelle sehen. Sie sollten zuerst die privaten IP-Adressen Ihrer DNS-Server sehen, gefolgt von einigen Fallback-Werten. Ihre Domain sollte in der "DNS Domain" sein:

Output. . .
Link 3 (eth1)
     Current Scopes: DNS
      LLMNR setting: yes
MulticastDNS setting: no
     DNSSEC setting: no
   DNSSEC supported: no
        DNS Servers:

                     67.207.67.2
                     67.207.67.3
         DNS Domain:
. . .

Ihr Client sollte jetzt für die Verwendung Ihrer internen DNS-Server konfiguriert sein.

Ubuntu 16.04 und Debian-Clients

Auf Ubuntu 16.04- und Debian Linux-Servern können Sie die Datei + / etc / network / interfaces + bearbeiten:

sudo nano /etc/network/interfaces

Suchen Sie im Inneren die Zeile + dns-nameservers +. Wenn es an die Schnittstelle "+ lo " angehängt ist, verschieben Sie es in Ihre Netzwerkschnittstelle (z. B. " eth0 " oder " eth1 "). Stellen Sie als Nächstes Ihre eigenen Nameserver vor die Liste, die sich derzeit dort befindet. Fügen Sie unterhalb dieser Zeile die Option " dns-search +" hinzu, die auf die Basisdomäne Ihrer Infrastruktur verweist. In unserem Fall wäre dies "nyc3.example.com":

/ etc / network / interfaces

   . . .

   dns-nameservers   8.8.8.8


   . . .

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

Stellen Sie sicher, dass das Paket + resolvconf + auf Ihrem System installiert ist:

sudo apt update
sudo apt install resolvconf

Starten Sie jetzt Ihre Netzwerkdienste neu und übernehmen Sie die neuen Änderungen mit den folgenden Befehlen. Stellen Sie sicher, dass Sie "+ eth0 +" durch den Namen Ihrer Netzwerkschnittstelle ersetzen:

sudo ifdown --force  && sudo ip addr flush dev  && sudo ifup --force

Dadurch sollte Ihr Netzwerk neu gestartet werden, ohne dass die aktuelle Verbindung unterbrochen wird. Wenn es richtig funktioniert hat, sollten Sie so etwas sehen:

OutputRTNETLINK answers: No such process
Waiting for DAD... Done

Überprüfen Sie, ob Ihre Einstellungen übernommen wurden, indem Sie Folgendes eingeben:

cat /etc/resolv.conf

Sie sollten Ihre Nameserver in der Datei "+ / etc / resolv.conf" sowie Ihre Suchdomäne sehen:

Output# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.128.10.11
nameserver 10.128.20.12
nameserver 8.8.8.8
search nyc3.example.com

Ihr Client ist jetzt für die Verwendung Ihrer DNS-Server konfiguriert.

CentOS-Clients

Bearbeiten Sie unter CentOS, RedHat und Fedora Linux die Datei + / etc / sysconfig / network-scripts / ifcfg- +. Möglicherweise müssen Sie "+ eth0 +" durch den Namen Ihrer primären Netzwerkschnittstelle ersetzen:

sudo nano /etc/sysconfig/network-scripts/ifcfg-

Suchen Sie nach den Optionen "+ DNS1 " und " DNS2 " und stellen Sie sie auf die privaten IP-Adressen Ihrer primären und sekundären Nameserver ein. Fügen Sie einen " DOMAIN +" - Parameter hinzu, der der Basisdomäne Ihrer Infrastruktur entspricht. In diesem Handbuch wäre das "nyc3.example.com":

/ etc / sysconfig / network-scripts / ifcfg-eth0

. . .
DNS1=
DNS2=

. . .

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

Starten Sie nun den Netzwerkdienst neu, indem Sie Folgendes eingeben:

sudo systemctl restart network

Der Befehl kann einige Sekunden lang hängen bleiben, sollte Sie jedoch in Kürze zur Eingabeaufforderung zurückführen.

Überprüfen Sie, ob Ihre Änderungen übernommen wurden, indem Sie Folgendes eingeben:

cat /etc/resolv.conf

Sie sollten Ihre Nameserver und Suchdomäne in der Liste sehen:

/etc/resolv.conf

nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com

Ihr Client sollte nun in der Lage sein, eine Verbindung zu Ihren DNS-Servern herzustellen und diese zu verwenden.

Clients testen

Verwenden Sie "+ nslookup +", um zu testen, ob Ihre Clients Ihre Nameserver abfragen können. Dies sollte auf allen Clients möglich sein, die Sie konfiguriert haben und die sich in der „vertrauenswürdigen“ ACL befinden.

Für CentOS-Clients müssen Sie möglicherweise das Dienstprogramm installieren mit:

sudo yum install bind-utils

Für Debian-Clients können Sie Folgendes installieren:

sudo apt install dnsutils

Wir können mit einem Forward-Lookup beginnen.

Forward-Lookup

Beispielsweise können wir eine Forward-Suche durchführen, um die IP-Adresse von * host1.nyc3.example.com * abzurufen, indem Sie den folgenden Befehl ausführen:

nslookup host1

Das Abfragen von "host1" wird zu "host1.nyc3.example.com" erweitert, da die Option "+ search +" auf Ihre private Subdomain festgelegt ist und DNS-Abfragen versuchen, diese Subdomain zu durchsuchen, bevor Sie den Host an einer anderen Stelle suchen. Die Ausgabe des obigen Befehls sieht folgendermaßen aus:

OutputServer:     127.0.0.53
Address:    127.0.0.53#53

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

Als nächstes können wir Reverse Lookups überprüfen.

Rückwärtssuche

Fragen Sie den DNS-Server mit der privaten IP-Adresse von * host1 * ab, um die umgekehrte Suche zu testen:

nslookup 10.128.100.101

Sie sollten eine Ausgabe sehen, die wie folgt aussieht:

Output11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

Authoritative answers can be found from:

Wenn alle Namen und IP-Adressen in die richtigen Werte aufgelöst werden, bedeutet dies, dass Ihre Zonendateien ordnungsgemäß konfiguriert sind. Wenn Sie unerwartete Werte erhalten, überprüfen Sie unbedingt die Zonendateien auf Ihrem primären DNS-Server (z. + db.nyc3.example.com + und + db.10.128 +).

Herzliche Glückwünsche! Ihre internen DNS-Server sind jetzt ordnungsgemäß eingerichtet! Jetzt kümmern wir uns um die Pflege Ihrer Zonendatensätze.

DNS-Einträge pflegen

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

Hinzufügen eines Hosts zu DNS

Wann immer Sie Ihrer Umgebung einen Host hinzufügen (im selben Datencenter), möchten Sie ihn zum DNS hinzufügen. Hier ist eine Liste der Schritte, die Sie ausführen müssen:

Primärer Nameserver

  • Forward Zone-Datei: Fügen Sie einen "A" -Datensatz für den neuen Host hinzu und erhöhen Sie den Wert von "Serial".

  • Reverse-Zone-Datei: Fügen Sie einen "PTR" -Datensatz 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 "vertrauenswürdigen" ACL hinzu (+ named.conf.options)

Testen Sie Ihre Konfigurationsdateien:

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

Dann lade BIND neu:

sudo systemctl reload bind9

Ihr Primärserver sollte jetzt für den neuen Host konfiguriert sein.

Sekundärer Nameserver

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

Überprüfen Sie die Konfigurationssyntax:

sudo named-checkconf

Dann lade BIND neu:

sudo systemctl reload bind9

Ihr sekundärer Server akzeptiert jetzt Verbindungen vom neuen Host.

Konfigurieren Sie den neuen Host für die Verwendung Ihres DNS

  • Konfigurieren Sie "+ / etc / resolv.conf +", um Ihre DNS-Server zu verwenden

  • Testen Sie mit + nslookup +

Host aus DNS entfernen

Wenn Sie einen Host aus Ihrer Umgebung entfernen oder ihn einfach aus DNS entfernen möchten, entfernen Sie einfach alle Elemente, die hinzugefügt wurden, als Sie den Server zu DNS hinzugefügt haben (d. H. die Umkehrung der obigen Schritte).

Fazit

Jetzt können Sie die privaten Netzwerkschnittstellen Ihrer Server nach Namen und nicht nach IP-Adresse benennen. Dies erleichtert die Konfiguration von Diensten und Anwendungen, da Sie sich die privaten IP-Adressen nicht mehr merken müssen und die Dateien leichter zu lesen und zu verstehen sind. Außerdem können Sie jetzt Ihre Konfigurationen so ändern, dass sie auf einen neuen Server an einem einzigen Ort, Ihrem primären DNS-Server, verweisen, anstatt verschiedene verteilte Konfigurationsdateien bearbeiten zu müssen, was die Wartung vereinfacht.

Sobald Sie Ihr internes DNS eingerichtet haben und Ihre Konfigurationsdateien private FQDNs zum Angeben von Netzwerkverbindungen verwenden, ist es * wichtig *, dass Ihre DNS-Server ordnungsgemäß gewartet werden. Wenn beide nicht mehr verfügbar sind, funktionieren Ihre Dienste und Anwendungen, die darauf angewiesen sind, nicht mehr ordnungsgemäß. Aus diesem Grund wird empfohlen, Ihren DNS mit mindestens einem sekundären Server einzurichten und funktionierende Backups von allen zu führen.

Related