So konfigurieren Sie Bind als DNS-Caching- oder Weiterleitungsserver unter Ubuntu 14.04

Einführung


DNS oder das Domain Name System ist häufig eine schwierige Komponente, um die Konfiguration von Websites und Servern zu erlernen. Während die meisten Benutzer wahrscheinlich die von ihrem Hosting-Unternehmen oder ihrer Domain-Registrierungsstelle bereitgestellten DNS-Server verwenden, bietet das Erstellen eigener DNS-Server einige Vorteile.

In diesem Handbuch wird die Installation und Konfiguration des Bind9-DNS-Servers als Cache- oder Weiterleitungs-DNS-Server auf Ubuntu 14.04-Computern erläutert. Diese beiden Konfigurationen haben beide Vorteile, wenn Maschinennetzwerke bedient werden.

Voraussetzungen und Ziele

Um dieses Handbuch zu vervollständigen, müssen Sie zunächst mit einigen gängigen DNS-Begriffen vertraut sein. Schauen Sie sichthis guide an, um mehr über einige der Konzepte zu erfahren, die wir in diesem Handbuch implementieren werden.

Wir werden zwei separate Konfigurationen demonstrieren, die ähnliche Ziele erreichen: einen Cache- und einen Weiterleitungs-DNS-Server.

Um mitzumachen, müssen Sie Zugriff auf zwei Computer haben (von denen mindestens einer ein Ubuntu 14.04-Server sein sollte). Einer fungiert als Client und der andere wird als DNS-Server konfiguriert. Die Details unserer Beispielkonfiguration sind:

Role IP Adresse

DNS Server

192.0.2.1

Klient

192.0.2.100

Wir zeigen Ihnen, wie Sie den Client-Computer so konfigurieren, dass er den DNS-Server für Abfragen verwendet. Wir zeigen Ihnen, wie Sie den DNS-Server je nach Ihren Anforderungen in zwei verschiedenen Konfigurationen konfigurieren.

DNS-Server zwischenspeichern

Die erste Konfiguration gilt für einen DNS-Server voncaching. Dieser Servertyp wird auch als Auflöser bezeichnet, da er rekursive Abfragen verarbeitet und im Allgemeinen die Hauptarbeit des Auffindens von DNS-Daten von anderen Servern erledigen kann.

Wenn ein DNS-Cache-Server die Antwort auf die Anfrage eines Clients aufspürt, gibt er die Antwort an den Client zurück. Sie speichert die Antwort jedoch auch für die Zeit im Cache, die der TTL-Wert der Datensätze zulässt. Der Cache kann dann als Quelle für nachfolgende Anforderungen verwendet werden, um die gesamte Umlaufzeit zu beschleunigen.

Fast alle DNS-Server in Ihrer Netzwerkkonfiguration werden DNS-Server zwischenspeichern. Dies macht den Mangel an geeigneten DNS-Auflösungsbibliotheken wett, die auf den meisten Clientcomputern implementiert sind. Ein DNS-Cache-Server ist in vielen Situationen eine gute Wahl. Wenn Sie sich nicht auf das DNS Ihres Internetdienstanbieters oder andere öffentlich verfügbare DNS-Server verlassen möchten, ist es eine gute Wahl, einen eigenen Caching-Server einzurichten. Wenn es sich in unmittelbarer physischer Nähe zu den Clientcomputern befindet, können sich auch die DNS-Abfragezeiten verbessern.

DNS-Server weiterleiten

Die zweite Konfiguration, die wir demonstrieren werden, ist einforwardingDNS-Server. Ein Weiterleitungs-DNS-Server sieht aus Client-Sicht fast wie ein Caching-Server aus, die Mechanismen und die Arbeitslast sind jedoch sehr unterschiedlich.

Ein DNS-Weiterleitungsserver bietet den gleichen Vorteil, einen Cache zu verwalten, um die DNS-Auflösungszeiten für Clients zu verbessern. Tatsächlich führt es jedoch keine der rekursiven Abfragen durch. Stattdessen werden alle Anforderungen an einen externen Auflösungsserver weitergeleitet und die Ergebnisse für spätere Abfragen zwischengespeichert.

Auf diese Weise kann der Weiterleitungsserver aus seinem Cache antworten, ohne die gesamte Arbeit rekursiver Abfragen ausführen zu müssen. Auf diese Weise kann der Server nur einzelne Anforderungen (die weitergeleitete Clientanforderung) ausführen, anstatt die gesamte Rekursionsroutine durchlaufen zu müssen. Dies kann in Umgebungen von Vorteil sein, in denen die Übertragung externer Bandbreite kostspielig ist, in denen Ihre Caching-Server möglicherweise häufig geändert werden müssen oder wenn Sie lokale Abfragen an einen Server und externe Abfragen an einen anderen Server weiterleiten möchten.

Installieren Sie Bind auf dem DNS-Server

Unabhängig davon, welche Konfigurationsoption Sie verwenden möchten, besteht der erste Schritt bei der Implementierung eines Bind-DNS-Servers darin, die eigentliche Software zu installieren.

Die Bind-Software ist in den Standard-Repositorys von Ubuntu verfügbar. Daher müssen wir nur unseren lokalen Paketindex aktualisieren und die Software mitapt installieren. Wir werden auch die Dokumentation und einige gängige Dienstprogramme einschließen:

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

Nachdem die Bind-Komponenten installiert wurden, können Sie mit der Konfiguration des Servers beginnen. Der Weiterleitungsserver verwendet die Caching-Serverkonfiguration als Ausgangspunkt. Konfigurieren Sie den Server daher unabhängig von Ihrem Endziel zuerst als Caching-Server.

Als Caching-DNS-Server konfigurieren

Zunächst wird erläutert, wie Bind als DNS-Cache-Server konfiguriert wird. Diese Konfiguration zwingt den Server dazu, rekursiv nach Antworten von anderen DNS-Servern zu suchen, wenn ein Client eine Abfrage ausgibt. Dies bedeutet, dass alle zugehörigen DNS-Server nacheinander abgefragt werden, bis die gesamte Antwort gefunden wurde.

Die Bindungskonfigurationsdateien werden standardmäßig in einem Verzeichnis mit/etc/bind gespeichert. Verschiebe jetzt in dieses Verzeichnis:

cd /etc/bind

Wir werden uns nicht mit den meisten Dateien in diesem Verzeichnis befassen. Die Hauptkonfigurationsdatei heißtnamed.conf (named undbind sind zwei Namen für dieselbe Anwendung). Diese Datei bezieht einfach die Dateinamed.conf.options, die Dateinamed.conf.localund die Dateinamed.conf.default-zones.

Bei einem Caching-DNS-Server ändern wir nur dienamed.conf.options-Datei. Öffnen Sie dies in Ihrem Texteditor mit sudo-Berechtigungen:

sudo nano named.conf.options

Wenn die Kommentare der Lesbarkeit halber entfernt sind, sieht die Datei folgendermaßen aus:

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

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Um das Caching zu konfigurieren, müssen Sie zunächst eine Zugriffssteuerungsliste (ACL) einrichten.

Als DNS-Server, der zur Lösung rekursiver Abfragen verwendet wird, soll der DNS-Server nicht von böswilligen Benutzern missbraucht werden. Ein Angriff mit der BezeichnungDNS amplification attack ist besonders problematisch, da Ihr Server an verteilten Denial-of-Service-Angriffen teilnehmen kann.

Ein DNS-Verstärkungsangriff ist eine Möglichkeit, mit der böswillige Benutzer versuchen, Server oder Websites im Internet auszuschalten. Dazu versuchen sie, öffentliche DNS-Server zu finden, die rekursive Abfragen auflösen. Sie fälschen die IP-Adresse des Opfers und senden eine Abfrage, die eine große Antwort an den DNS-Server zurückgibt. Auf diese Weise antwortet der DNS-Server auf eine kleine Anfrage mit einer großen Nutzlast, die an den Server des Opfers gerichtet ist, wodurch die verfügbare Bandbreite des Angreifers effektiv erweitert wird.

Das Hosten eines öffentlichen, rekursiven DNS-Servers erfordert einen hohen Konfigurations- und Administrationsaufwand. Um zu verhindern, dass Ihr Server für böswillige Zwecke verwendet wird, konfigurieren wir eine Liste von IP-Adressen oder Netzwerkbereichen, denen wir vertrauen.

Über dem Blockoptions erstellen wir einen neuen Block mit dem Namenacl. Erstellen Sie eine Bezeichnung für die ACL-Gruppe, die Sie konfigurieren. In diesem Handbuch nennen wir die Gruppegoodclients.

acl goodclients {
};

options {
    . . .

Listen Sie in diesem Block die IP-Adressen oder Netzwerke auf, die diesen DNS-Server verwenden dürfen. Da sowohl unser Server als auch unser Client im selben / 24-Subnetz arbeiten, beschränken wir das Beispiel auf dieses Netzwerk. Wir werden auchlocalhost undlocalnets hinzufügen, die dies automatisch versuchen:

acl goodclients {
    192.0.2.0/24;
    localhost;
    localnets;
};

options {
    . . .

Nachdem wir nun eine ACL von Clients haben, für die wir die Anforderung auflösen möchten, können wir diese Funktionen im Blockoptionskonfigurieren. Fügen Sie in diesem Block die folgenden Zeilen hinzu:

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

    recursion yes;
    allow-query { goodclients; };
    . . .

Wir haben die Rekursion explizit aktiviert und dann den Parameterallow-queryo konfiguriert, dass er unsere ACL-Spezifikation verwendet. Wir hätten einen anderen Parameter wieallow-recursion verwenden können, um auf unsere ACL-Gruppe zu verweisen. Wenn vorhanden und die Rekursion aktiviert ist, bestimmtallow-recursion die Liste der Clients, die rekursive Dienste verwenden können.

Wenn jedochallow-recursion nicht festgelegt ist, greift Bind auf die Listeallow-query-cache, dann auf die Listeallow-query und schließlich auf einen Standardwert vonlocalnets undlocalhost zurück nur. Da wir einen Nur-Caching-Server konfigurieren (er hat keine eigenen autorisierenden Zonen und leitet keine Anforderungen weiter), gilt die Listeallow-queryimmer nur für die Rekursion. Wir verwenden es, weil es die allgemeinste Methode zur Angabe der ACL ist.

Wenn Sie mit diesen Änderungen fertig sind, speichern und schließen Sie die Datei.

Dies ist eigentlich alles, was für einen DNS-Cache-Server erforderlich ist. Wenn Sie sich für diesen Servertyp entschieden haben, können Sie fortfahren, um zu erfahren, wie Sie Ihre Konfigurationsdateien überprüfen, den Dienst neu starten und Clientkonfigurationen implementieren.

Lesen Sie andernfalls weiter, um zu erfahren, wie Sie stattdessen einen Weiterleitungs-DNS-Server einrichten.

Als Weiterleitungs-DNS-Server konfigurieren

Wenn ein Weiterleitungs-DNS-Server besser zu Ihrer Infrastruktur passt, können wir dies stattdessen problemlos einrichten.

Wir beginnen mit der Konfiguration, die wir in der Caching-Server-Konfiguration aufgehört haben. Die Dateinamed.conf.optionsollte folgendermaßen aussehen:

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

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

        recursion yes;
        allow-query { goodclients; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Wir verwenden dieselbe ACL-Liste, um Ihren DNS-Server auf eine bestimmte Liste von Clients zu beschränken. Wir müssen jedoch die Konfiguration ändern, damit der Server nicht mehr versucht, rekursive Abfragen selbst durchzuführen.

Dazu ändern wirnotrecursion in no. Der Weiterleitungsserver bietet weiterhin rekursive Dienste an, indem er Anfragen für Zonen beantwortet, für die er nicht autorisiert ist. Stattdessen müssen wir eine Liste von Caching-Servern einrichten, an die unsere Anforderungen weitergeleitet werden.

Dies erfolgt innerhalb desoptions {}-Blocks. Zuerst erstellen wir einen Block mit dem Namenforwarders, der die IP-Adressen der rekursiven Nameserver enthält, an die Anforderungen weitergeleitet werden sollen. In unserem Handbuch verwenden wir die öffentlichen DNS-Server von Google (8.8.8.8 und8.8.4.4):

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

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        . . .

Danach sollten wir die Direktiveforwardauf "nur" setzen, da dieser Server alle Anforderungen weiterleitet und nicht versuchen sollte, Anforderungen selbst aufzulösen.

Die Konfigurationsdatei sieht folgendermaßen aus, wenn Sie fertig sind:

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

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

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        forward only;

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Eine letzte Änderung, die wir vornehmen sollten, sind die Parameter vondnssec. Bei der aktuellen Konfiguration werden abhängig von der Konfiguration der weitergeleiteten DNS-Server möglicherweise einige Fehler in den Protokollen angezeigt, die folgendermaßen aussehen:

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

Um dies zu vermeiden, ändern Sie die Einstellung vondnssec-validationauf "yes" und aktivieren Sie explizit dnssec:

. . .
forward only;

dnssec-enable yes;
dnssec-validation yes;

auth-nxdomain no;    # conform to RFC1035
. . .

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Sie sollten jetzt einen Weiterleitungs-DNS-Server eingerichtet haben. Fahren Sie mit dem nächsten Abschnitt fort, um Ihre Konfigurationsdateien zu überprüfen und den Dämon neu zu starten.

Testen Sie Ihre Konfiguration und starten Sie Bind neu

Nachdem Sie Ihren Bindungsserver entweder als Caching-DNS-Server oder als Weiterleitungs-DNS-Server konfiguriert haben, sind wir bereit, unsere Änderungen zu implementieren.

Bevor Sie den Bind-Server in unserem System neu starten, sollten Sie die Syntax unserer Konfigurationsdateien mit den im Lieferumfang von Bind enthaltenen Tools überprüfen.

Wir können dies leicht tun, indem wir Folgendes eingeben:

sudo named-checkconf

Wenn Ihre Konfiguration keine Syntaxfehler enthält, kehrt die Shell-Eingabeaufforderung sofort zurück, ohne dass eine Ausgabe angezeigt wird.

Wenn Ihre Konfigurationsdateien Syntaxfehler enthalten, werden Sie auf den Fehler und die Zeilennummer hingewiesen, in der er auftritt. In diesem Fall gehen Sie zurück und überprüfen Sie Ihre Dateien auf Fehler.

Wenn Sie überprüft haben, dass Ihre Konfigurationsdateien keine Syntaxfehler aufweisen, starten Sie den Bind-Daemon neu, um Ihre Änderungen zu implementieren:

sudo service bind9 restart

Behalten Sie anschließend die Serverprotokolle im Auge, während Sie Ihren Clientcomputer einrichten, um sicherzustellen, dass alles reibungslos funktioniert. Lass dies auf dem Server laufen:

sudo tail -f /var/log/syslog

Öffnen Sie jetzt ein neues Terminalfenster, um Ihre Client-Computer zu konfigurieren.

Konfigurieren Sie den Client-Computer

Nachdem Sie Ihren Server in Betrieb genommen haben, können Sie Ihren Client-Computer so konfigurieren, dass dieser DNS-Server für Abfragen verwendet wird.

Melden Sie sich bei Ihrem Client-Computer an. Stellen Sie sicher, dass der von Ihnen verwendete Client in der ACL-Gruppe angegeben wurde, die Sie für Ihren DNS-Server festgelegt haben. Andernfalls verweigert der DNS-Server die Zustellung von Anfragen an den Client.

Wir müssen die Datei/etc/resolv.confbearbeiten, um unseren Server auf den Nameserver zu verweisen. Änderungen, die hier vorgenommen werden, bleiben nur bis zum Neustart bestehen. Dies ist ideal für Tests. Wenn wir mit den Ergebnissen unserer Tests zufrieden sind, können wir diese Änderungen dauerhaft machen.

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

sudo nano /etc/resolv.conf

In der Datei werden die DNS-Server aufgelistet, die zum Auflösen von Abfragen verwendet werden sollen, indem die Direktiven vonnameserverfestgelegt werden. Kommentieren Sie alle aktuellen Einträge aus und fügen Sie einenameserver-Zeile hinzu, die auf Ihren DNS-Server verweist:

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Speichern und schließen Sie die Datei.

Jetzt können Sie mithilfe einiger gängiger Tools testen, ob Abfragen ordnungsgemäß aufgelöst werden können.

Mitping können Sie testen, ob Verbindungen zu Domänen hergestellt werden können:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

Dies bedeutet, dass unser Client über unseren DNS-Server eine Verbindung mitgoogle.com herstellen kann.

Wir können detailliertere Informationen erhalten, indem wir DNS-spezifische Tools wiedig verwenden. Versuchen Sie diesmal eine andere Domain:

dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6017    IN  A   140.211.169.4

;; Query time: 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE  rcvd: 64

Sie können sehen, dass die Abfrage 36 Millisekunden dauerte. Wenn wir die Anfrage erneut stellen, sollte der Server die Daten aus seinem Cache ziehen und die Antwortzeit verringern:

dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6012    IN  A   140.211.169.4

;; Query time: 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE  rcvd: 64

Wie Sie sehen, ist die zwischengespeicherte Antwort erheblich schneller.

Wir können die umgekehrte Suche auch testen, indem wir die gefundene IP-Adresse (in unserem Fall140.211.169.4) mit der Option-xvon dig verwenden:

dig -x 140.211.169.4
; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa.    IN  PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN CNAME   4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

Wie Sie sehen, ist auch die umgekehrte Suche erfolgreich.

Zurück auf Ihrem DNS-Server sollten Sie feststellen, ob während Ihrer Tests Fehler aufgetreten sind. Ein häufiger Fehler, der auftreten kann, sieht folgendermaßen aus:

. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

Diese zeigen an, dass der Server versucht, IPv6-Informationen aufzulösen, der Server jedoch nicht für IPv6 konfiguriert ist. Sie können dieses Problem beheben, indem Sie Bind anweisen, nur IPv4 zu verwenden.

Öffnen Sie dazu die Datei/etc/default/bind9mit sudo-Berechtigungen:

sudo nano /etc/default/bind9

Ändern Sie im Inneren den ParameterOPTIONSo, dass er das Flag-4enthält, um nur IPv4-Verhalten zu erzwingen:

OPTIONS="-u bind -4"

Speichern und schließen Sie die Datei.

Starten Sie den Server neu:

sudo service bind9 restart

Sie sollten diese Fehler nicht erneut in den Protokollen sehen.

Festlegen der Client-DNS-Einstellungen

Wie bereits erwähnt, überleben die Einstellungen von/etc/resolv.conf, die den Clientcomputer auf unseren DNS-Server verweisen, einen Neustart nicht. Damit die Änderungen zuletzt durchgeführt werden, müssen Sie die Dateien ändern, die zum Generieren dieser Datei verwendet werden.

Wenn auf dem Clientcomputer Debian oder Ubuntu ausgeführt wird, öffnen Sie die Datei/etc/network/interfacesmit sudo-Berechtigungen:

sudo nano /etc/network/interfaces

Suchen Sie nach dem Parameterdns-nameservers. Sie können die vorhandenen Einträge entfernen und durch Ihren DNS-Server ersetzen oder einfach Ihren DNS-Server als eine der folgenden Optionen hinzufügen:

. . .
iface eth0 inet static
        address 111.111.111.111
        netmask 255.255.255.0
        gateway 111.111.0.1
        dns-nameservers 192.0.2.1
. . .

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Beim nächsten Start werden Ihre Einstellungen übernommen.

Wenn auf dem Client CentOS oder Fedora ausgeführt wird, müssen Sie stattdessen die Datei/etc/sysconfig/network/network-scripts/ifcfg-eth0öffnen:

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

Suchen Sie im Inneren nach den Zeilen, die mitDNS beginnen. Ändern SieDNS1 in Ihren DNS-Server. Wenn Sie die anderen DNS-Server nicht als Fallback verwenden möchten, entfernen Sie die anderen Einträge:

DNS1=192.0.2.1

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Ihr Client sollte diese Einstellungen beim nächsten Start verwenden.

Fazit

Sie sollten jetzt entweder einen Cache- oder Weiterleitungs-DNS-Server haben, der für Ihre Clients konfiguriert ist. Dies kann eine gute Möglichkeit sein, DNS-Abfragen für die von Ihnen verwalteten Computer zu beschleunigen.

Wenn Sie einen DNS-Server erstellen möchten, der für Ihre eigenen Domänenzonen autorisierend ist, können Sieauthoritative-only DNS serverkonfigurieren oder diese Lösungen kombinieren.