DNS (Domain Name System) ist eine wichtige und eher schwer zu konfigurierende Komponente, die für den Betrieb von Websites und Servern notwendig ist. Viele Benutzer verwenden DNS-Server, die von ihrem Hosting-Anbieter bereitgestellt werden. Der Besitz eigener DNS-Server hat jedoch einige Vorteile.

In diesem Tutorial erfahren Sie, wie Sie Bind9 installieren und als Caching- oder Weiterleitungs-DNS-Server auf einem Ubuntu 14.04-Server konfigurieren.

Anforderungen

• Verstehen der Grundtypen von DNS-Servern. Näheres erfahren Sie unter.
• Zwei Maschinen, von denen mindestens eine mit Ubuntu 14.04 läuft. Der erste Rechner wird als Client (IP-Adresse 192.0.2.100) und der zweite als DNS-Server (192.0.2.1) konfiguriert.

Sie erfahren, wie Sie einen Client-Computer so konfigurieren, dass er Abfragen über einen DNS-Server sendet.

Caching-DNS-Server

Server dieses Typs werden auch Resolver genannt, da sie rekursive Abfragen verarbeiten und typischerweise DNS-Daten von anderen Servern nachschlagen können.

Wenn ein zwischenspeichernder DNS-Server die Antwort auf eine Client-Anfrage überwacht, sendet er die Antwort an den Client zurück und speichert sie außerdem für den Zeitraum im Cache, den der TTL-Wert der entsprechenden DNS-Einträge zulässt. Der Cache kann dann als Quelle für Antworten auf nachfolgende Anfragen verwendet werden, um die Gesamtverarbeitungszeit der Anfragen zu verkürzen.

Fast alle DNS-Server in Ihrer Netzwerkkonfiguration sind Caching-Server. Ein Caching-DNS-Server ist in vielen Situationen eine gute Wahl. Wenn Sie sich nicht auf die DNS-Server Ihres Hosting-Anbieters oder andere öffentliche DNS-Server verlassen möchten, richten Sie Ihren eigenen Caching-DNS-Server ein. Je kürzer die Entfernung vom DNS-Server zu den Client-Rechnern ist, desto kürzer ist die Zeit, die für die Bearbeitung von DNS-Anfragen benötigt wird.

Weiterleitung des DNS-Servers

Aus der Sicht eines Kunden sieht ein Weiterleitungs-DNS-Server fast genauso aus wie ein Caching-Server, die Mechanismen und die Arbeitslast sind jedoch völlig unterschiedlich.

Ein weiterleitender DNS-Server bietet die gleichen Vorteile wie ein Caching-Server. Es werden jedoch keine rekursiven Abfragen durchgeführt. Stattdessen leitet es alle Anfragen an einen externen Auflösungsserver weiter und speichert die Ergebnisse dann für nachfolgende Anfragen zwischen.

Dadurch kann der Umleitungsserver Anforderungen aus seinem Cache bedienen, ohne rekursive Anforderungen verarbeiten zu müssen. Somit verarbeitet dieser Server nur einzelne Anfragen (umgeleitete Client-Anfragen) und nicht den gesamten Rekursionsvorgang. Dies kann in Umgebungen mit begrenzter externer Bandbreite, in denen Caching-Server häufig gewechselt werden müssen, und in Situationen, in denen lokale Anfragen an einen Server und externe Anfragen an einen anderen weitergeleitet werden müssen, von Vorteil sein.

1: Installieren Sie Bind auf dem DNS-Server

Das Bind-Paket finden Sie im offiziellen Ubuntu-Repository. Aktualisieren Sie Ihren Paketindex und installieren Sie Bind mit dem apt-Manager. Sie müssen auch einige Abhängigkeiten installieren.

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

Anschließend können Sie mit der Einrichtung des Servers beginnen. Die Konfiguration des Caching-Servers kann als Vorlage für die Konfiguration des Weiterleitungsservers verwendet werden. Daher müssen Sie zuerst den Caching-DNS-Server konfigurieren.

2: Einrichten eines Caching-DNS-Servers

Zuerst müssen Sie Bind als Caching-DNS-Server konfigurieren. Diese Konfiguration zwingt den Server dazu, rekursiv nach Antworten auf Client-Anfragen auf anderen DNS-Servern zu suchen. Es werden nacheinander alle passenden DNS-Server abgefragt, bis eine Antwort gefunden wird.

Bind-Konfigurationsdateien werden im Verzeichnis /etc/bind gespeichert.

Die meisten Dateien müssen nicht bearbeitet werden. Die Hauptkonfigurationsdatei heißt „named.conf“ (named und bind sind zwei Namen für dieselbe Anwendung). Diese Datei verweist auf die Dateien „named.conf.options“, „named.conf.local“ und „named.conf.default-zones“.

Um einen Caching-DNS-Server zu konfigurieren, müssen Sie nur „named.conf.options“ bearbeiten.

sudo nano mit dem Namen.conf.options

Diese Datei sieht folgendermaßen aus (Kommentare wurden der Einfachheit halber weggelassen):

Optionen (
Verzeichnis „/var/cache/bind“;
dnssec-validierung auto;

listen-on-v6 (any;);
};

Um einen Caching-Server einzurichten, müssen Sie eine Zugriffskontrollliste (ACL) erstellen.

Sie müssen den DNS-Server schützen, der rekursive Anfragen von Angreifern verarbeitet. DNS-Amplification-Angriffe sind besonders gefährlich, da sie den Server in verteilte Denial-of-Service-Angriffe verwickeln können.

DNS-Amplification-Angriffe sind eine Möglichkeit, Server und Websites lahmzulegen. Dazu versuchen Angreifer, öffentliche DNS-Server zu finden, die rekursive Abfragen verarbeiten. Sie fälschen die IP-Adresse des Opfers und senden eine Anfrage, die eine sehr lange Antwort an den DNS-Server zurückgibt. In diesem Fall sendet der DNS-Server als Reaktion auf eine kleine Anfrage zu viele Daten an den Server des Opfers zurück, wodurch die verfügbare Bandbreite des Angreifers erhöht wird.

Das Hosten eines öffentlichen rekursiven DNS-Servers erfordert eine sorgfältige Konfiguration und Verwaltung. Um zu verhindern, dass der Server gehackt wird, konfigurieren Sie eine Liste von IP-Adressen oder Netzwerkbereichen, denen der Server vertrauen kann.

Fügen Sie vor dem Optionsblock einen ACL-Block hinzu. Erstellen Sie eine Bezeichnung für die ACL-Gruppe (in diesem Tutorial heißt die Gruppe „goodclients“).

acl gute Kunden (
};
Optionen (
. . .

Listen Sie in diesem Block die IP-Adressen oder Netzwerke auf, die Zugriff auf diesen DNS-Server haben. Da Server und Client im Subnetz /24 laufen, können Sie den Zugriff auf dieses Subnetz einschränken. Sie müssen auch localhost und localnets entsperren, die sich automatisch verbinden.

acl gute Kunden (
192.0.2.0/24;
localhost;
lokale Netze;
};
Optionen (
. . .

Sie verfügen jetzt über eine sichere Client-ACL. Sie können mit der Einrichtung der Anfrageauflösung im Optionsblock beginnen. Fügen Sie die folgenden Zeilen hinzu:

Optionen (
Verzeichnis „/var/cache/bind“;
Rekursion ja;

. . .

Der Optionsblock aktiviert explizit die Rekursion und konfiguriert dann die Option „allow-query“ für die Verwendung der ACL. Sie können auch einen anderen Parameter verwenden, z. B. „allow-recursion“, um auf die ACL-Gruppe zu verweisen. Wenn die Rekursion aktiviert ist, definiert „allow-recursion“ eine Liste von Clients, die rekursive Dienste nutzen können.

Wenn jedoch „allow-recursion“ nicht festgelegt ist, greift Bind auf die Liste „allow-query-cache“ zurück, dann auf die Liste „allow-query“ und schließlich auf die Standardlisten „localnets“ und „localhost“. Da wir nur einen Caching-Server einrichten (er hat keine eigenen Zonen und leitet keine Abfragen weiter), gilt die Liste der zulässigen Abfragen immer nur für die Rekursion. Dies ist die gebräuchlichste Methode zum Definieren einer ACL.

Speichern und schließen Sie die Datei.

Dies sind alle Einstellungen, die zur Konfigurationsdatei des Caching-DNS-Servers hinzugefügt werden müssen.

Notiz: Wenn Sie nur diesen DNS-Typ verwenden möchten, überprüfen Sie die Konfigurationen, starten Sie den Dienst neu und konfigurieren Sie Ihren Client.

3: Einrichten eines Weiterleitungs-DNS-Servers

Wenn Ihre Infrastruktur eher für einen Weiterleitungs-DNS-Server geeignet ist, können Sie die Einrichtung etwas anpassen.

Derzeit sieht die Datei „named.conf.options“ folgendermaßen aus:

acl gute Kunden (
192.0.2.0/24;
localhost;
lokale Netze;
};
Optionen (
Verzeichnis „/var/cache/bind“;
Rekursion ja;
Allow-Query(goodclients;);
dnssec-validierung auto;
auth-nxdomain nein; # entspricht RFC1035
listen-on-v6 (any;);
};

Mit derselben ACL können Sie den DNS-Server auf eine bestimmte Liste von Clients beschränken. Dies erfordert jedoch eine geringfügige Konfigurationsänderung, damit der Server nicht mehr versucht, rekursive Abfragen auszuführen.

Ändern Sie die Rekursion nicht in „Nein“. Der umleitende Server unterstützt weiterhin rekursive Dienste. Um einen Umleitungsserver einzurichten, müssen Sie eine Liste von Caching-Servern erstellen, an die er Anfragen umleitet.

Dies geschieht im Optionen()-Block. Zunächst müssen Sie darin einen neuen Weiterleitungsblock erstellen, in dem die IP-Adressen der rekursiven Nameserver gespeichert werden, an die Sie Anfragen umleiten möchten. In diesem Fall handelt es sich um Google DNS-Server (8.8.8.8 und 8.8.4.4):

. . .
Optionen (
Verzeichnis „/var/cache/bind“;
Rekursion ja;
Allow-Query(goodclients;);
Spediteure (

8.8.8.8;

8.8.4.4;

};
. . .

Die resultierende Konfiguration sieht folgendermaßen aus:

acl gute Kunden (
192.0.2.0/24;
localhost;
lokale Netze;
};
Optionen (
Verzeichnis „/var/cache/bind“;
Rekursion ja;
Allow-Query(goodclients;);
Spediteure (
8.8.8.8;
8.8.4.4;
};
nur vorwärts;
dnssec-validierung auto;
auth-nxdomain nein; # entspricht RFC1035
listen-on-v6 (any;);
};

Die letzte Änderung betrifft den Parameter dnssec. Bei der aktuellen Konfiguration und abhängig von den Einstellungen der DNS-Server, an die Anfragen umgeleitet werden, können in den Protokollen folgende Fehler auftreten:

25. Juni 15:03:29 Cache mit dem Namen: Fehler (DS-Server verfolgen) beim Auflösen von „in-addr.arpa/DS/IN“: 8.8.8.8#53
25. Juni 15:03:29 Cache mit dem Namen: Fehler (kein gültiger DS) beim Auflösen von „111.111.111.111.in-addr.arpa/PTR/IN“: 8.8.4.4#53

Um sie zu vermeiden, müssen Sie den Parameter dnssec-validation auf „yes“ ändern und dnssec explizit aktivieren.

. . .
nur vorwärts;
dnssec-enable ja;
DNSsec-Validierung ja;
auth-nxdomain nein; # entspricht RFC1035
. . .

Speichern und schließen Sie die Datei. Die Einrichtung des Weiterleitungs-DNS-Servers ist abgeschlossen.

4: Überprüfen Sie die Einstellungen und starten Sie Bind neu

Jetzt müssen Sie sicherstellen, dass die Einstellungen wie erwartet funktionieren.

Um die Syntax der Konfigurationsdateien zu überprüfen, geben Sie Folgendes ein:

sudo benannt-checkconf

Wenn die Dateien keine Fehler enthalten, zeigt die Eingabeaufforderung keine Ausgabe an.

Wenn Sie eine Fehlermeldung erhalten, korrigieren Sie diese und testen Sie erneut.

Anschließend können Sie den Bind-Daemon neu starten, um die Einstellungen zu aktualisieren.

sudo service bind9 neu starten

Dann müssen Sie die Serverprotokolle überprüfen. Führen Sie den Befehl auf dem Server aus:

sudo tail -f /var/log/syslog

Öffnen Sie nun ein neues Terminal und beginnen Sie mit der Einrichtung des Client-Rechners.

5: Client-Setup

Melden Sie sich am Client-Computer an. Stellen Sie sicher, dass der Client in der ACL-Gruppe des konfigurierten DNS-Servers aufgeführt ist. Andernfalls verweigert der DNS-Server die Bearbeitung von Anfragen dieses Clients.

Bearbeiten Sie die Datei /etc/resolv.conf, um den Server auf einen Nameserver zu verweisen.

Hier vorgenommene Änderungen bleiben nur bis zu einem Neustart bestehen, was sich hervorragend zum Testen eignet. Wenn Sie mit den Ergebnissen der Testeinstellungen zufrieden sind, können Sie diese Einstellungen dauerhaft machen.

Öffnen Sie die Datei mit sudo in einem Texteditor:

sudo nano /etc/resolv.conf

Die Datei muss die DNS-Server auflisten, die zum Auflösen von Abfragen verwendet werden. Verwenden Sie dazu die Nameserver-Direktive. Kommentieren Sie alle aktuellen Einträge aus und fügen Sie eine Nameserver-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.

Sie können jetzt eine Testanfrage senden, um sicherzustellen, dass das Problem korrekt gelöst wird.

Hierfür können Sie Ping verwenden:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) Bytes Daten.
64 Bytes von sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63,8 ms
--- Ping-Statistiken von google.com ---
1 Pakete gesendet, 1 empfangen, 0 % Paketverlust, Zeit 0 ms
RTT min/avg/max/mdev = 63,807/63,807/63,807/0,000 ms

Der Zweck von DNS besteht darin, Domänennamen, die sich Menschen leicht merken können, in IP-Adressen zu übersetzen, die Computer verstehen können. Dieser Vorgang wird Namensauflösung genannt. Was bringt uns die Installation unseres eigenen Caching-DNS-Servers? Dadurch wird die Reaktion von Websites ein wenig beschleunigt. + Linux akzeptiert NetBios-Namen nicht besonders gut, aber manchmal muss man Computer oder Drucker in einem lokalen Netzwerk finden, möchte dies jedoch anhand des Namens tun.

Das Merken von IP-Adressen ist nicht bequem, und auch der ständige Blick auf das Protokoll des DHCP-Servers ist nicht unsere Methode. In solchen Fällen benötigen Sie DNS im lokalen Netzwerk. Die Installation des bind9-Pakets selbst ist nicht schwierig; Fehler treten normalerweise bereits in der Konfigurationsphase auf, weil Nach leicht lesbaren Systemkonfigurationsdateien steht der Mensch vor einer unverständlichen Syntax, die übrigens der Programmiersprache S sehr ähnlich ist. Der Server funktioniert innerhalb des lokalen Netzwerks, es macht keinen Sinn, ihn in eine Chroot-Umgebung zu übertragen, und die gesamte Einrichtung nimmt nur sehr wenig Zeit in Anspruch. Damit ist der lyrische Teil abgeschlossen, fahren wir mit der Installation und Konfiguration fort.

Lassen Sie uns den Bind9-DNS-Server installieren:

# apt – get install bind9

Nach Abschluss, Download und Installation müssen wir die Konfigurationsdatei bearbeiten:

#vim /etc/bind/named. conf. Optionen

Wir finden den Abschnitt, er befindet sich ganz am Anfang der Konfigurationsdatei, außer ihm gibt es dort nichts anderes ...

Optionen ( Verzeichnis „/var/cache/bind“ ; // Wenn zwischen Ihnen und den gewünschten Nameservern eine Firewall besteht// Um ​​mit ihnen zu kommunizieren, müssen Sie möglicherweise die Firewall reparieren, um mehrere zuzulassen// Ports zum Reden. Siehe http://www.kb.cert.org/vuls/id/800113// Wenn Ihr ISP eine oder mehrere IP-Adressen für stabil bereitgestellt hat// Nameserver, Sie möchten sie wahrscheinlich als Weiterleitungen verwenden.// Den folgenden Block auskommentieren und die Adressen ersetzen// der All-0-Platzhalter. // Weiterleitungen ( // 0.0.0.0; // ); auth - nxdomain no; # entspricht RFC1035 listen - on - v6 ( any ; ); );

Der Abschnitt Weiterleitungen ist dafür verantwortlich, wohin die DNS-Anfrage zur Namensauflösung gesendet wird, wenn sie sich nicht in der eigenen Datenbank befindet. In letzter Zeit war ich überhaupt nicht zufrieden, die Arbeit dieser Server mit dem Anbieter ist der Grund, warum man Server von Drittanbietern verbinden kann, zum Beispiel die von Google, man kann sich die IP 8.8.8.8 sehr leicht merken, ich werde ihr Beispiel dafür verwenden Konfigurieren Sie es, aber niemand stört Sie, diejenigen zu verwenden, die Ihnen am besten gefallen.

Wir bearbeiten den Abschnitt. Zuerst müssen Sie Kommentare daraus entfernen und DNS von Drittanbietern hinzufügen. Wenn beispielsweise mehrere Server hinzugefügt werden müssen, falls der Google-Server Ihren Anforderungen nicht standhalten kann und ausfällt :), dann IP anderer Server können in eine Spalte geschrieben werden, dann erreicht man eine höhere Fehlertoleranz.

Spediteure(8.8.8.8; 193.58.251.251; //Russischer DNS-Dienst -SkyDNS};

In diesem Abschnitt ist es besser, die IP des Servers einzutragen, den Sie in der Datei angegeben haben /etc/resolv.conf oder geben Sie es in den Abschnitt ein Nameserver diese IP. Speichern Sie die Änderungen und beenden Sie den Vorgang. Starten Sie den Server neu und überprüfen Sie. Wir geben die Befehlszeile ein nslookup mail.ru
Sollte ausgeben:

Nicht verbindliche Antwort: Name: E-Mail. ru Adressen: 94.100.191.202

Dies deutet darauf hin, dass unser Server nicht der Hauptserver ist, der diese Zone (mail.ru) bedient, sondern Anfragen zum Cache hinzugefügt hat!
Jetzt müssen wir eine DNS-Zone für unser Netzwerk erstellen, damit Maschinen verschiedene Netzwerkdienste finden können – es könnten zum Beispiel Netzwerkdrucker sein, sie können entweder unabhängig sein oder auf anderen Workstations gemeinsam genutzt werden.
Unsere Zone kann Orgname heißen – d.h. Name der Organisation.
Zunächst erstellen wir eine Zone, die wir bearbeiten benannt.conf.local

#vim /etc/bind/named. conf. lokal

und füge Folgendes hinzu:

Zone „orgname“ (Typ Master; Datei „/etc/bind/db.orgname“;);

Speichern und beenden
Jetzt müssen wir eine Zonenkonfigurationsdatei erstellen

# vim / etc / bind / db . Organisationsname

und fügen Sie Folgendes ein:
(Bitte achten Sie genau auf die Syntax der Konfigurationsdatei, auch die Punkte haben eine Bedeutung)

@IN SOA-Organisationsname.

Wurzel. Organisationsname. (20101015 4h; Aktualisierungszeit – 4 Stunden 1h; Wiederholung jede Stunde 1w; wie lange Informationen gespeichert werden sollen – 1 Woche 1d);
Die TTL (Time to Live) eines Datensatzes beträgt 1 Tag @ IN NS orgname. ;
nameservername @ IN A 192.168.10.1 ;

A – Eintrag – die IP-Adresse unseres DNS-Servers, der diese Zone bedient, @ bedeutet, dass dies die Root-Zone ist.

* IN CNAME @ Drucker IN A 192.168.10.25 ;

Sie können einen DNS-Eintrag für einen Netzwerkdrucker unter 192.168.10.25 erstellen

Wenn Sie nun ein neues Netzwerkgerät hinzufügen, müssen Sie zwei Dinge tun:

1) Reservieren Sie eine IP-Adresse auf einem DHCP-Server. Wie das geht, können Sie im Artikel „Einen DHCP-Server einrichten“ nachlesen
2) Erstellen Sie eine DNS-Zone für diese IP und geben Sie den Gerätenamen IN A XXX.XXX.XXX.XXX ein. Dabei ist: Gerätename der Netzwerkname des Geräts; XXX.XXX.XXX.XXX ist seine IP-Adresse, die auf dem DHCP-Server reserviert ist.

Jetzt müssen wir die Datei resolv.conf bearbeiten

#vim /etc/resolv. conf und geben Sie dort ein:.
Nameserver 127.0.0.1
Alles, was da war, kann mit # auskommentiert werden

Der Server wird neu gestartet

# neu starten

Dies wurde so gemacht, dass der Server nach allem in seiner eigenen Datenbank sucht und BIND erst dann Anfragen an die Server-IP 8.8.8.8 umleitet, deren IP in der Direktive enthalten ist

Spediteure

Jetzt können Sie die Funktionalität überprüfen: Wenn der Test unter Windows stattfindet:

Ping-Gerätename. Organisationsname<<>Wenn wir unter Linux testen:<<>Ping-Gerätename. Organisationsname - c 4<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310

Pings sollten an die IP gehen, die Sie angegeben haben, und nicht an XXX.XXX.XXX.XXX Sie können mit dem Befehl auch die Geschwindigkeit der Verarbeitung von Anfragen überprüfen graben # dig @127.0.0.1 tut.by ;> DiG 9.9.5-9+deb8u6-Debian > @127.0.0.1 tut.by ; (1 Server gefunden) ;; globale Optionen: +cmd ;; Antwort bekommen: ;; ->>HEADER Guten Tag, liebe Leser. Um das theoretische Material fortzusetzen, möchte ich im aktuellen Artikel ein praktisches Beispiel betrachten Installationen und Einstellungen anders BIND-Serverkonfigurationen..

Im Artikel werde ich beschreiben

DNS-Cache einrichten und voll DNS-Masterserver. Ich beginne die Beschreibung mit allgemeinen Konzepten und notwendigen Schritten für deren Organisation DNS-Server. allgemeine Informationen Namens ist ein Dämon, der Teil davon ist Paket bind9 und Sein Domain-Name-Server Dämon benannt. Es übernimmt Einstellungen aus der aufgerufenen Hauptkonfigurationsdatei benannt.conf und befindet sich im Verzeichnis /etc/bind. In der Hauptkonfiguration beschrieben Arbeitsverzeichnis des Servers, oft ist dies ein Verzeichnis /var/cache/bind, in dem liegen Zonenbeschreibungsdateien und andere Servicedateien. Korrespondenz Zonennamen Und Zonenbeschreibungsdatei Sätze Zonenabschnitt mit Parameter Datei. Zonenabschnitt Es legt außerdem die Art der Verantwortung dieses Servers für die Zone fest (Master, Slave usw.) und definiert außerdem spezielle Parameter für die aktuelle Zone (z. B. auf welcher Schnittstelle Anforderungen für die aktuelle Zone verarbeitet werden sollen). In Zonenbeschreibungsdateien enthält Zonenparameter und Ressourceneinträge (die in diesem Absatz angegebenen Pfade können je nach Linux-Distribution oder Parametern unterschiedlich sein).

Hierbei handelt es sich um ein allgemeines Arbeitsschema, das Ihnen dabei helfen wird, in Zukunft bei der Betrachtung spezifischer Konfigurationen Verwirrung zu vermeiden.

Das Konfigurationsdateiformat für die 4. Version des Programms unterscheidet sich von dem in der achten und neunten Version verwendeten BINDEN. In Anbetracht dessen, dass ich mit der Installation eines neuen rechne DNS Server, aber ich sehe keinen Sinn darin, die alte Version zu installieren, also schaue ich mir die Konfiguration der neuen Version an.

Ausgangsdaten

Damit DNS ordnungsgemäß funktioniert, müssen Sie über . DNS wird im aktuellen Artikel auf der Debian-Distribution konfiguriert; Features anderer Distributionen werden ebenfalls erwähnt. Die Standnetzwerkkonfiguration lautet wie folgt:

DNS: ~# CAT/ETC/Network/InterFaces Auto LO IFACE LOOPBACK AUTH0 IFACE ETH0 INETCAS 10.0.152 NETMASK 255.255.255.0 GATEWAY 10.0.254 AUTOO AUTH1 AUTH1 ATH1 Ace ETH1 Inet Statische Adresse 192.168.1.1 Netzmaske. 255.255.25 5,0

Wo 10.0.0.152/24 - externe Schnittstelle (vom Anbieter zugewiesenes Subnetz), 192.168.1.1/24 - intern (Lokales Netzwerk). Die benutzerdefinierte Zone erhält den Namen example.com. Im Beispiel mit Slave-Server, der sekundäre Server befindet sich auf IP 10.0.0.191 .

BIND9 installieren

Damit der DNS-Server funktioniert, müssen Sie Folgendes tun bind9 (in einigen Distributionen - binden ). Wie im Diagramm angegeben – die Hauptkonfigurationsdatei BINDEN ist eine Datei benannt.conf(Diese Datei kann im Verzeichnis abgelegt werden /usw, manchmal in /etc/bind).

Parameter (Syntax) benannt.conf

Syntax der Datei „named.conf“. hält sich an folgende Regeln:

IP-Adressen- Die IP-Liste muss durch das Symbol „;“ getrennt werden. , es ist möglich, ein Subnetz im Format 192.168.1.1/24 oder 192.168.1.1/255.255.255.0 anzugeben, (um IP auszuschließen, muss man ein Zeichen davor setzen!), es ist möglich, Namen anzugeben „any“, „none“, „localhost“ in doppelten Anführungszeichen.

Kommentare- Zeilen, die mit #, // beginnen und in /* und */ eingeschlossen sind, gelten als Kommentare.

IN Zonenbeschreibungsdateien -Symbol @ ist eine „Variable“, die den Namen der in der Konfigurationsdatei angegebenen Zone speichert benannt.conf oder in der @-Direktive $ORIGIN aktuelle Zonenbeschreibung.

Jede fertige Zeichenfolge Parameter müssen mit dem Symbol enden; .

Acl-Abschnitt

Acl (Zugriffskontrollliste)– ermöglicht Ihnen die Angabe einer benannten Liste von Netzwerken. Abschnittsformat: acl „Netzwerkname“ (ip; ip; ip; );

Abschnitt „Optionen“.

Abschnitt „Optionen“. Sätze globale Parameter Konfigurationsdatei, die alle Zonen steuert. Dieser Abschnitt hat das Format: Optionen(options_section_operators);. Optionen können darin „verschachtelt“ werden Zonenabschnitt, dabei überschreibt es die globalen Parameter. Häufig verwendet Optionsanweisungen:

• erlauben-Abfrage ( list_ip} - Ermöglicht Antworten auf Anfragen nur von list_ip. Bei Abwesenheit antwortet der Server auf alle Anfragen.
• Allow-Rekursion( list_ip} - Rekursive Abfragen werden für Anfragen von list_ip ausgeführt. Im Übrigen iterativ. Wenn der Parameter nicht angegeben ist, führt der Server rekursive Abfragen für alle Netzwerke durch.
• Zulassen-Übertragung ( list_ip} - Zeigt die Liste der Server an, die eine Zone vom Server übernehmen dürfen (hier werden hauptsächlich Slave-Server angegeben)
• Verzeichnis /path/to/work/dir- Gibt den absoluten Pfad zum Arbeitsverzeichnis des Servers an. Diese Aussage ist nur im Abschnitt Optionen gültig.
• Spediteure ( IP-Port, IP-Port...} - gibt Hostadressen und ggf. Ports an, an die Anfragen weitergeleitet werden sollen (normalerweise wird hier der DNS von ISP-Anbietern angegeben).
• nach vorne NUR oder nach vorne ERSTE - Parameter Erste gibt an, dass der DNS-Server versuchen soll, Namen mithilfe der im Parameter „forwarders“ angegebenen DNS-Server aufzulösen. Nur wenn die Namensauflösung mithilfe dieser Server nicht möglich war, versucht er selbst eine Namensauflösung.
• benachrichtigen JA|NEIN - JA- Slave-Server über Änderungen in der Zone benachrichtigen, NEIN- nicht benachrichtigen.
• Rekursion JA|NEIN - JA- auf Wunsch des Kunden rekursive Abfragen durchführen, NEIN- Nicht ausführen (nur iterative Abfragen). Wenn die Antwort im Cache gefunden wird, wird sie aus dem Cache zurückgegeben. (kann nur im Abschnitt Optionen verwendet werden)

Zonenabschnitt

Definiert die Beschreibung der Zone(n). Abschnittsformat: Zone( section_zone_operators}; Betreiber, die am häufigsten verwendet werden:

• Allow-Update( list_ip} – gibt die Systeme an, die diese Zone dynamisch aktualisieren dürfen.
• Datei "Dateiname „ – gibt den Pfad der Zonenparameterdatei an (muss sich in dem Verzeichnis befinden, das im Optionsabschnitt durch die Verzeichnisanweisung angegeben wird)
• Meister ( list_ip} -zeigt die Liste der Master-Server an. (nur in untergeordneten Zonen erlaubt)
• Typ " Zonentyp " – gibt den im aktuellen Abschnitt beschriebenen Zonentyp an; zone_type kann die folgenden Werte annehmen:
  • nach vorne– gibt eine Umleitungszone an, die in dieser Zone eingehende Anforderungen weiterleitet.
  • Hinweis– weist auf eine Hilfszone hin (dieser Typ enthält Informationen über die Root-Server, die der Server kontaktieren wird, wenn er keine Antwort im Cache finden kann)
  • Master– gibt an, als Master-Server für die aktuelle Zone zu arbeiten.
  • Sklave– gibt an, als Slave-Server für die aktuelle Zone zu arbeiten.

Zusätzliche Konfigurationsoptionen

Zeitwerte in Zonendateien Standardmäßig wird sie in Sekunden angegeben, es sei denn, ihnen folgt einer der folgenden Buchstaben: S – Sekunden, M – Minuten, H – Stunden, D – Tage, W – Wochen. Dementsprechend der Eintrag 2h20m5s hat einen Wert von 2 Stunden 20 Minuten 5 Sekunden und entspricht 8405 Sekunden.

Jeder Host-/Eintragsname, der nicht mit endet Punkt zählt nicht FQDN Name und wird durch den Namen der aktuellen Zone ergänzt. Beispielsweise wird der Eintrag „domen“ in der Zonendatei „examle.com“ auf den FQDN-Namen „domen.examle.com“ erweitert. .

IN BIND-Konfigurationsdateien Folgendes kann zutreffen Richtlinien:

• $TTL– Definiert die Standard-TTL für alle Datensätze in der aktuellen Zone.
• $ORIGIN– Ändert den Zonennamen gegenüber dem in der Datei „named.conf“ angegebenen. Gleichzeitig erstreckt sich der Geltungsbereich dieser Direktive nicht „nach oben“ (d. h. wenn eine Datei durch die $INCLUDE-Direktive einbezogen wird, erstreckt sich der Geltungsbereich von $ORIGN nicht auf die übergeordnete Datei).
• $INCLUDE– schließt die angegebene Datei als Teil der Zonendatei ein.

Ich möchte besonders beschreiben Parameter Allow-Transfer ( 10.0.0.191; );. Dieser Parameter beschreibt die Server, die eine Kopie der Zone herunterladen dürfen – sog Slave-Server. Im folgenden Beispiel schauen wir uns die Einstellung an Slave-DNS.

Damit die Protokollierung ordnungsgemäß funktioniert, müssen Sie das entsprechende Verzeichnis erstellen und die erforderlichen Rechte vergeben:

Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep mit dem Namen bind 4298 0,0 3,4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0,0 0,1 3304 772 pts/4 S+ 18:19 0:00 grep benannt dns:~# chown bind /var/log/bind/ dns:~# ls -ld /var/log/bind/ drwxr--r-- 2 bind root 4096 6. Juli 18:18 /var/log/bind/

Dns:~# cat /var/cache/bind/example.com $TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601; seriell 8H; Aktualisierung 2H; erneut versuchen 2W; Ablauf 1D) ; Minimum @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @

sowie in der in-addr.arpa-Domäne.

Dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001; Seriell 3600; Aktualisieren 900; Wiederholen 3600000; Ablaufen 3600) ; Mindestens IN NS ns.examle.com.

IN NS ns2.example.com. 152 IN PTR example.com. 191 IN PTR ns.example.com. * IN PTR example.com. dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001; Seriell 3600; Aktualisieren 900; Wiederholen 3600000; Ablaufen 3600) ; Mindestens IN NS ns.examle.com.

IN NS ns2.example.com. * IN PTR example.com.

Unser Netzwerk ist klein, es wird davon ausgegangen, dass es nur sehr wenige Maschinen im Netzwerk gibt. Alle Netzwerkdienste werden auf einem Host, example.com, gehostet, sodass sowohl Master-DNS (ns.example.com.) als auch Mailserver (mx.example.com.) auf denselben Computer (10.0.0.152) verweisen. Sekundärer (Slave) autorisierender Zonenserver Hauptfunktion Slave-Server- Automatische Synchronisierung der Zonenbeschreibung mit dem Masterserver. Diese Aufgabe wird durch das Dokument geregelt 4.3.5. RFC 1034

im Abschnitt Laut diesem Dokument wird empfohlen, Daten zwischen Servern über eine AXFR-Anfrage auszutauschen. Für diese Anfrage muss die gesamte Zone in einer TCP-Verbindung übertragen werden (RFC 1035). Auch,

Slave-DNS-Server teilt sich die Last mit dem Master-Server oder übernimmt bei einem Ausfall des ersten Servers die gesamte Last. Bevor Sie beginnen

Einrichten eines Slave-DNS-Servers<<>, müssen Sie prüfen, ob Sie die Zone manuell vom sekundären Server abrufen können, indem Sie den folgenden Befehl verwenden:<<>Root@debian:~# dig @10.0.0.152 example.com. axfr;

1. > DiG 9.7.3 > @10.0.0.152 example.com. axfr; (1 Server gefunden) ;; globale Optionen: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Abfragezeit: 14 ms ;; SERVER: 10.0.0.152#53(10.0.0.152) ;; WANN: Fr. 8. Juli 15:33:54 2011 ;; XFR-Größe: 11 Datensätze (Nachrichten 1, Bytes 258) Kopie
2. Konfigurationsdatei „named.conf“. vom Master-Server; Ersetzen Geben Sie den Master-Parameter ein
3. An Typ Sklave Ersetzen Parameter erlaubte Übertragung ( 10.0.0.191; ); in den Zonen, für die es zweitrangig sein wird;
4. Zonen löschen, die der aktuelle Server nicht bedienen kann, einschließlich der Root-Anfrage, wenn der Slave nicht auf rekursive Anfragen antwortet;
5. Erstellen Sie Verzeichnisse für Protokolle, wie im vorherigen Beispiel.

Insgesamt erhalten wir die Slave-Server-Konfiguration:

Root@debian:~# cat /etc/bind/named.conf options ( Verzeichnis „/var/cache/bind“;allow-query (any;); // auf Anfragen von allen Schnittstellen antworten recursion no; // rekursiv deaktivieren Anfragen auth-nxdomain no; // für RFC1035-Kompatibilität listen-on-v6 (none;); // wir benötigen keine IPv6-Version „unknown“ // zeigen die DNS-Serverversion nicht an); // die unten beschriebenen Zonen definieren den Server als autorisierend für Loopback-Schnittstellen // sowie für Broadcast-Zonen (gemäß RFC 1912) Zone „localhost“ ( Typ Master; Datei „localhost“; ); Zone „127.in-addr.arpa“ ( Typ Master; Datei „127.in-addr.arpa“; ); Zone „0.in-addr.arpa“ ( Typ Master; Datei „0.in-addr.arpa“; ); Zone „255.in-addr.arpa“ ( Typ Master; Datei „255.in-addr.arpa“; ); // Beschreibung der Hauptzone Zone „example.com“ ( Typ Slave; Datei „example.com“; Masters ( 10.0.0.152; ); ); //Beschreibung der Reverse-Zone-Zone „0.0.10.in-addr.arpa“ ( Typ Slave; Datei „0.0.10.in-addr.arpa“; Masters ( 10.0.0.152; ); ); // Protokollierungseinstellungen Protokollierung ( Kanal „misc“ ( Datei „/var/log/bind/misc.log“ Versionen 4 Größe 4 m; Druckzeit JA; Druckschweregrad JA; Druckkategorie JA; ); Kanal „Abfrage“ (Datei „/var/log/bind/query.log“ Versionen 4 Größe 4m; Druckzeit JA; Druckkategorie NEIN; ); ); ;

nach dem Neustart unseres Slave-Server kopiert die benötigten Informationen erfolgreich vom Hauptserver, was durch das Vorhandensein von Dateien im Verzeichnis angezeigt wird:

Root@debian:~# ls -la /var/cache/bind/ total 28 drwxrwxr-x 2 root bind 4096 8. Juli 18:47 . drwxr-xr-x 10 root root 4096 8. Juli 15:17 .. -rw-r--r-- 1 bind bind 416 8. Juli 18:32 0.0.10.in-addr.arpa ...... - rw-r--r-- 1 bind bind 455 8. Juli 18:32 example.com ........

Grundsätzlich ist /stroallow-transfer (pngp Slave-Server darf keine Kopie der Zone in seinem Dateisystem speichern. Diese Kopie wird nur benötigt, wenn DNS startet. Eine Kopie der Zone im Dateisystem kann einen Ausfall verhindern, wenn der Master-Server während des Slave-DNS-Starts nicht verfügbar ist. Wenn Sie die Dateioption im Zonenabschnitt nicht angeben, wird keine Kopie erstellt.

Einrichten von netfilter() für DNS BIND

Nachdem der Server konfiguriert wurde, wäre es tatsächlich eine gute Idee, ihn zu schützen. Wir wissen, dass der Server auf Port 53/udp läuft. Nachdem Sie den Artikel dazu gelesen und sich damit vertraut gemacht haben, können Sie Regeln zum Filtern des Netzwerkverkehrs erstellen:

Dns ~ # iptables-save # typische iptables-Regeln für DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # lokalen Netzwerkzugriff auf den DNS-Server erlauben: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack - -ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp - m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # DNS-Serverzugriff erlauben, um ausgehende Anfragen zu stellen -A OUTPUT -p udp -m udp --dport 53 -m conntrack - -ctstate NEW -j ACCEPT COMMIT

Das ist ein typisches Beispiel! Um iptables-Regeln festzulegen, die Ihren Aufgaben und Ihrer Netzwerkkonfiguration entsprechen, müssen Sie die Funktionsweise von Netfilter unter Linux verstehen, indem Sie die oben genannten Artikel lesen.

Fehlerbehebung

Die Hauptquelle zur Identifizierung von DNS-Problemen ist. Hier ist ein Beispiel für Startfehler, wenn ich beim Pfad zu einen Fehler gemacht habe Zonendatei des Kernservers:

5. Juli 18:12:43 DNS-Server mit dem Namen: startet BIND 9.7.3 -u bind 5. Juli 18:12:43 DNS-Server mit dem Namen: erstellt mit „--prefix=/usr“ „--mandir=/usr/ share/man“ „--infodir=/usr/share/info“ „--sysconfdir=/etc/bind“ „--localstatedir=/var“ „--enable-threads“ „--enable-largefile“ „- -with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "- -with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap =yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" " CPPFLAGS=" 5. Juli 18:12:43 DNS-Server benannt: Grenzwert für geöffnete Dateien von 1024 auf 1048576 angepasst 5. Juli 18:12:43 DNS-Server benannt: 1 CPU gefunden, verwendet 1 Arbeitsthread 5. Juli 18:12: 43 DNS-Server mit dem Namen: verwendet bis zu 4096 Sockets. 5. Juli 18:12:43 DNS-Server mit dem Namen: Konfiguration wird aus „/etc/bind/named.conf“ geladen. 5. Juli 18:12:43 DNS-Server mit dem Namen: wird erstellt -in vertrauenswürdige Schlüssel aus der Datei „/etc/bind/bind.keys“ 5. Juli 18:12:43 DNS-Server mit dem Namen: verwendet den Standard-UDP/IPv4-Portbereich: 5. Juli 18:12:43 DNS-Server mit dem Namen: verwendet den Standard UDP/IPv6-Portbereich: 5. Juli 18:12:43 DNS-Server mit dem Namen: lauscht auf der IPv4-Schnittstelle lo, 127.0.0.1#53 5. Juli 18:12:43 DNS-Server mit dem Namen: lauscht auf der IPv4-Schnittstelle eth1, 192.168.1.1 #53 5. Juli 18:12:43 DNS-Server mit dem Namen: Sitzungsschlüssel für dynamisches DNS wird generiert. 5. Juli 18:12:43 DNS-Server mit dem Namen: Root-Hinweise aus der Datei „/etc/bind/db.root“ konnten nicht konfiguriert werden nicht gefunden 5. Juli 18:12:43 DNS-Server mit dem Namen: Ladekonfiguration: Datei nicht gefunden # Datei nicht gefunden 5. Juli 18:12:43 DNS-Server mit dem Namen: wird beendet (aufgrund eines schwerwiegenden Fehlers) 5. Juli 18:15:05 DNS-Server mit dem Namen: Start von BIND 9.7.3 -u bind 5. Juli 18:15:05 DNS-Server mit dem Namen: erstellt mit „--prefix=/usr“ „--mandir=/usr/share/man“ „- infodir =/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "- - enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres= no " "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with - dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" 5. Juli 18: 15 :05 DNS-Server benannt: Grenzwert für geöffnete Dateien von 1024 auf 1048576 angepasst. 5. Juli 18:15:05 DNS-Server benannt: 1 CPU gefunden, verwendet 1 Arbeitsthread. 5. Juli 18:15:05 DNS-Server benannt: belegt auf 4096 Sockets 5. Juli 18:15:05 DNS-Server mit dem Namen: Konfiguration aus „/etc/bind/named.conf wird geladen“ 5. Juli 18:15:05 DNS-Server mit dem Namen: unter Verwendung des standardmäßigen UDP/IPv4-Portbereichs: 5. Juli 18:15:05 DNS-Server mit dem Namen: verwendet den standardmäßigen UDP/IPv6-Portbereich: 5. Juli 18:15:05 DNS-Server mit dem Namen: lauscht auf der IPv4-Schnittstelle lo, 127. 0.0.1#53 5. Juli 18:15:05 DNS-Server mit dem Namen: Überwachung der IPv4-Schnittstelle eth1, 192.168.1.1#53 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: 254.169.IN-ADDR. ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: 2.0.192.IN-ADDR.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: 100.51.198.IN-ADDR. ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: 113.0.203.IN-ADDR.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: 255.255.255.255.IN-ADDR. ARPA 5. Juli 18:15:05 DNS-Servername: automatische leere Zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6 .ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. IP6.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: D.F.IP6.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: 8.E.F.IP6.ARPA 5. Juli 18:15 :05 DNS-Server mit dem Namen: automatische leere Zone: 9.E.F.IP6.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatische leere Zone: A.E.F.IP6.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatisch Leere Zone: B.E.F.IP6.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: automatisch leere Zone: 8.B.D.0.1.0.0.2.IP6.ARPA 5. Juli 18:15:05 DNS-Server mit dem Namen: Zone 0. in-addr.arpa/IN: seriell geladen 1 5. Juli 18:15:05 DNS-Server mit dem Namen: Zone 127.in-addr.arpa/IN: seriell geladen 1 5. Juli 18:15:05 DNS-Server mit dem Namen: Zone 255.in-addr.arpa/IN: seriell geladen 1. 5. Juli 18:15:05 DNS-Server mit dem Namen: Zone localhost/IN: seriell geladen 2. 5. Juli 18:15:05 DNS-Server mit dem Namen: läuft # Start war erfolgreich

Ein ausgezeichnetes Diagnosewerkzeug ist.

Wieder aufnehmen

Im aktuellen Artikel habe ich die Einrichtung grundlegender BIND-DNS-Serverkonfigurationen beschrieben. Ziel des Artikels war es, einen Einblick in die Funktionsweise des BIND-Servers unter UNIX zu geben. Ich habe die Fragen der DNS-Sicherheit praktisch nicht angesprochen und mich kaum mit spezifischen Einstellungen wie dem Betrieb des Servers im Edge-Modus befasst, wenn unterschiedliche Informationen über die Zone(n) an verschiedene Netzwerke gesendet werden. Für ein tieferes Verständnis stelle ich eine Liste zusätzlicher Quellen zur Verfügung, aus denen Sie hoffentlich die notwendigen Informationen erhalten können. Ich werde dem ein Ende setzen. Bis zum nächsten Mal.

Domain-Name-System: http://citforum.ru/internet/dns/khramtsov/
Slave-Server– Domainnamen – Konzepte und Einrichtungen: http://tools.ietf.org/html/rfc1034
RFC 1035– Domänennamen – Implementierung und Spezifikation: http://tools.ietf.org/html/rfc1035
RFC 1537– Häufige Fehler bei der Konfiguration von DNS-Datendateien: http://tools.ietf.org/html/rfc1537
RFC 1591- Struktur und Delegation des Domain Name Systems: http://tools.ietf.org/html/rfc1591
RFC 1713- Tools für DNS-Debugging: http://tools.ietf.org/html/rfc1713
RFC 2606– Reservierte Top-Level-DNS-Namen: http://tools.ietf.org/html/rfc2606
DNS-Sicherheit (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 Administrator-Referenzhandbuch: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Sichere BIND-Vorlage: http://www.cymru.com/Documents/secure-bind-template.html
Die Konfigurationsparameter sind ausführlich beschriebenRussisch: http://www.bog.pp.ru/work/bind.html
Automatische Erstellung von Zonendateien: http://www.zonefile.org/?lang=en#zonefile

Autor: Paul Cobbaut
Veröffentlichungsdatum: 24. Mai 2015
Übersetzung: A. Panin
Übersetzungsdatum: 11. Juli 2015

Kapitel 4: Einführung in DNS-Server

4.3. Zwischenspeichern von DNS-Servern

Ein DNS-Server, der keine DNS-Zone bedient, aber mit anderen Nameservern verbunden ist, um Abfragen zwischenzuspeichern, wird als Caching-DNS-Server bezeichnet. Caching-DNS-Server funktionieren nicht mit DNS-Zonendatenbanken, die Ressourceneinträge enthalten. Stattdessen stellen sie eine Verbindung zu anderen Nameservern her und speichern die relevanten Informationen zwischen.

Es gibt zwei Arten von DNS-Caching-Servern. Dies sind DNS-Server, die Weiterleitungs-DNS-Server verwenden, sowie DNS-Server, die Root-DNS-Server verwenden.

4.3.1. Caching-DNS-Server, der keine Weiterleitung verwendet

Ein zwischenspeichernder DNS-Server, der keine Weiterleitung verwendet, muss seine Informationen von woanders beziehen. Wenn eine Anfrage von einem Client empfangen wird, kontaktiert dieser einen der Root-Server. Der Root-Server leitet Informationen über den Server, der die Zieldomäne der obersten Ebene bedient, an den Caching-Server weiter, der sie wiederum an einen anderen DNS-Server weiterleitet. Der letzte Server kann entweder über die Informationen verfügen, um die Anfrage zu beantworten, oder er kann Informationen über einen anderen DNS-Server weitergeben, der möglicherweise über diese Informationen verfügt. Schließlich erhält unser DNS-Server die Informationen, die er benötigt, um die Anfrage zu beantworten und eine Antwort an den Client zu senden.

Die folgende Abbildung zeigt den Prozess, bei dem ein Client eine Anfrage nach IP-Adressinformationen für den Domainnamen linux-training.be sendet. Unser Caching-Server stellt eine Verbindung zum Root-Server her und wird an den Server weitergeleitet, der die .be-Top-Level-Domain bedient. Es stellt dann eine Verbindung zu dem Server her, der die .be-Top-Level-Domain bedient, und wird zu einem der Nameserver der Openminds-Organisation umgeleitet. Einer dieser Nameserver (in diesem Fall nsq.openminds.be) antwortet auf die Anfrage mit der IP-Adresse des Servers mit dem Domänennamen linux-training.be. Sobald unser Caching-Server diese Informationen an den Client weitergibt, kann dieser eine Verbindung zur betreffenden Website herstellen.

Wenn Sie den tcpdump-Sniffer zum Auflösen eines bestimmten Domänennamens verwenden, können Sie die folgende Ausgabe erhalten (die ersten 20 Zeichen jeder Zeile wurden entfernt).

192.168.1.103.41251 > M.ROOT-SERVERS.NET.domain: 37279% A? linux-t\aining.be. (46) M.ROOT-SERVERS.NET.domain > 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268 > d.ns.dns.be.domain: 38555% A? Linux-Training.\be. (46) d.ns.dns.be.domain > 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514 > ns2.openminds.be.domain: 60888 % A? linux-train\ing.be. (46) ns2.openminds.be.domain > 192.168.1.103.7514: 60888*- 1/0/1 A 188.93.155.\ 87 (62)

4.3.2. Zwischenspeicherung des DNS-Servers mithilfe eines Weiterleitungsservers

Ein zwischenspeichernder DNS-Server, der eine Weiterleitung verwendet, ist ein DNS-Server, der alle erforderlichen Informationen von der Weiterleitung erhält. Beispielsweise kann der DNS-Server eines Internetdienstanbieters als umleitender DNS-Server fungieren.

Die Abbildung oben zeigt einen DNS-Server im lokalen Netzwerk eines Unternehmens, der den vom ISP bereitgestellten DNS-Server als Weiterleitungs-DNS-Server verwendet. Wenn die IP-Adresse des vom Internetanbieter bereitgestellten DNS-Servers 212.71.8.10 lautet, müssen die folgenden Zeilen in der Konfigurationsdatei „named.conf“ des DNS-Servers des Unternehmens vorhanden sein:

Spediteure ( 212.71.8.10; );

Darüber hinaus können Sie Ihren DNS-Server auch so konfigurieren, dass er mit bedingten Weiterleitungen arbeitet. Die Beschreibung des bedingten Weiterleitungs-DNS-Servers in der Konfigurationsdatei lautet wie folgt:

Zone „someotherdomain.local“ ( Typ vorwärts; nur weiterleiten; Weiterleitungen ( 10.104.42.1; ); );

4.3.3. Iterative oder rekursive Abfrage

Eine rekursive Anfrage ist eine DNS-Anfrage, nach deren Absenden der Client eine endgültige Antwort vom DNS-Server erwartet (in der Abbildung oben ist dies durch einen dicken roten Pfeil dargestellt, der vom MacBook zum DNS-Server zeigt). Eine iterative Anfrage ist eine DNS-Anfrage, nach deren Absenden der Client keine endgültige Antwort vom DNS-Server erwartet (in der Abbildung oben ist dies mit drei schwarzen Pfeilen dargestellt, die vom DNS-Server ausgehen). Iterative Abfragen werden am häufigsten zwischen Nameservern durchgeführt. Root-Nameserver antworten nicht auf rekursive Abfragen.

Der DNS-Server, der eine DNS-Zone verwaltet, wird als autorisierender DNS-Server für diese Zone bezeichnet. Denken Sie daran, dass eine DNS-Zone lediglich eine Sammlung von Ressourceneinträgen ist.

Der erste autorisierende DNS-Server für eine DNS-Zone wird als primärer DNS-Server bezeichnet. Dieser Server arbeitet mit einer Kopie der DNS-Zonendatenbank, die sowohl lesbar als auch beschreibbar ist. Wenn Sie die Datensicherheit bei Ausfällen erhöhen, die Serverleistung verbessern oder den Lastausgleich verbessern möchten, können Sie einen anderen DNS-Server beauftragen, der diese DNS-Zone ebenfalls verwaltet. Dieser Server wird als sekundärer DNS-Server bezeichnet.

Der Sekundärserver erhält während des DNS-Zonenübertragungsprozesses eine Kopie der DNS-Zonendatenbank vom Primärserver. Anfragen für DNS-Zonendatenübertragungen werden in bestimmten Zeitintervallen von sekundären Servern gesendet. Die Dauer dieser Zeitintervalle wird im SOA-Ressourcendatensatz festgelegt.

Mit dem Dienstprogramm rndc können Sie eine Aktualisierung der DNS-Zonendaten erzwingen. Das folgende Beispiel initiiert eine Datenübertragung für die DNS-Zone fred.local und druckt den entsprechenden Teil der Syslog-Datei /var/log/syslog.

root@debian7:/etc/bind# rndc aktualisiert fred.local root@debian7:/etc/bind# grep fred /var/log/syslog | Schwanz -7 | Schnitt -c38- Zone fred.local/IN: Senden von Benachrichtigungen (seriell 1) Empfang des Steuerkanalbefehls „fred.local aktualisieren“ Zone fred.local/IN: Übertragung gestartet. Übertragung von „fred.local/IN“ von 10.104.109.1#53: verbunden über Zone 10.104.33.30#57367 fred.local/IN: übertragen seriell 2 Übertragung von „fred.local/IN“ von 10.104.109.1#53: Übertragung abgeschlossen: 1 Nachrichten, 10 Datensätze, 264 Bytes, 0,001 Sek. (264000 Byte/Sek.) Zone fred.local/IN: Senden von Benachrichtigungen (seriell 2) root@debian7:/etc/bind#

Wenn Sie einer DNS-Zone einen sekundären DNS-Server hinzufügen, können Sie den Server als Slave-DNS-Server des primären Servers konfigurieren. Der primäre DNS-Server ist im Verhältnis zum sekundären Server der Master-DNS-Server.

Meistens ist der primäre DNS-Server der Master-Server, der mit allen Slave-Servern kommuniziert. Manchmal kann ein Slave-Server auch der Master-Server für Slave-Server auf der nächsten Ebene sein. In der folgenden Abbildung ist der Server mit dem Namen „ns1“ der primäre Server und die Server mit den Namen „ns2“, „ns3“ und „ns4“ die sekundären Server. Obwohl der Master-Server für die Server mit den Namen ns2 und ns3 ns1 ist, ist der Master-Server für ns4 ns2.

Der SOA-Ressourceneintrag enthält einen Wert für die Aktualisierungsrate der DNS-Zonendaten mit dem Namen „refresh“. Wenn dieser Wert auf 30 Minuten eingestellt ist, sendet der Slave-Server alle 30 Minuten Anfragen zur Übertragung einer Kopie der DNS-Zonendaten. Dieser Eintrag enthält auch einen Wert für die Länge des Timeout-Zeitraums namens retry . Dieser Wert wird verwendet, wenn der Masterserver nicht auf die letzte Anforderung zur Datenübertragung in der DNS-Zone antwortet. Ein Wert namens Ablaufzeit legt den Zeitraum fest, den der Slave-Server auf Anfragen von Clients antworten kann, ohne die DNS-Zonendaten zu aktualisieren.

Nachfolgend finden Sie ein Beispiel für die Verwendung des Dienstprogramms nslookup zum Lesen von SOA-Ressourceneintragsdaten für eine DNS-Zone (linux-training.be).

Root@debian6:~# nslookup > setze Typ=SOA > Server ns1.openminds.be > linux-training.be Server: ns1.openminds.be Adresse: 195.47.215.14#53 linux-training.be Ursprung = ns1.openminds.be E-Mail-Adresse = hostmaster.openminds.be Seriennummer = 2321001133 Aktualisierung = 14400 Wiederholung = 3600 Ablaufdatum = 604800 Minimum = 3600

DNS-Zonendatenübertragungen erfolgen nur, wenn sich Daten in den DNS-Zonendatenbanken ändern (d. h. wenn ein oder mehrere Ressourceneinträge auf der Masterserverseite hinzugefügt, gelöscht oder geändert werden). Der Slave-Server vergleicht die Versionsnummer (Seriennummer) seiner eigenen Kopie des SOA-Ressourcendatensatzes mit der Versionsnummer des SOA-Ressourcendatensatzes des entsprechenden Master-Servers. Wenn die Versionsnummern übereinstimmen, ist keine Datenaktualisierung erforderlich (da keine anderen Ressourceneinträge hinzugefügt, gelöscht oder geändert wurden). Wenn im gleichen Fall die Versionsnummer des SOA-Ressourceneintrags auf der Seite des Slave-Servers kleiner ist als die Versionsnummer desselben Eintrags auf der Seite des entsprechenden Master-Servers, wird eine DNS-Zonendatenübertragungsanforderung gestellt.

Unten sehen Sie einen Schnappschuss des Wireshark-Sniffer-Fensters mit Daten, die während der Datenübertragung in der DNS-Zone abgefangen wurden.

4.9. Vollständige oder teilweise Übertragung von DNS-Zonendaten

Die Übertragung der DNS-Zonendaten kann entweder vollständig oder teilweise erfolgen. Die Entscheidung, den einen oder anderen Modus zu verwenden, hängt von der Datenmenge ab, die übertragen werden muss, um die DNS-Zonendatenbank auf dem Slave-Server vollständig zu aktualisieren. Eine teilweise Übertragung von Zonendaten ist vorzuziehen, wenn die Gesamtmenge der geänderten Daten geringer ist als die Größe der gesamten Datenbank. Vollständige DNS-Zonendatenübertragungen werden mit dem AXFR-Protokoll und teilweise DNS-Zonendatenübertragungen mit dem IXFR-Protokoll durchgeführt.