DNS-Server · 8 min read · Oct 02, 2025
Zwei-in-eins DNS-Server mit BIND9
Dieses Tutorial zeigt Ihnen, wie Sie den BIND9 DNS-Server so konfigurieren, dass er gleichzeitig ein internes Netzwerk und ein externes Netzwerk mit unterschiedlichen Informationen bedient. Um dieses Ziel zu erreichen, wird eine neue Funktion von BIND9 namens View verwendet. Als Tutorial wird es Sie durch die gesamte Einrichtung führen, aber grundlegende Kenntnisse über BIND und DNS sind erforderlich, es gibt viele Dokumente, die diese Informationen im Internet abdecken.
Weiterlesen auf der Originalseite oder PDF herunterladen.
Inhalte
- 1 Das Problem
- 2 Erste Konfiguration
- 3 Internes und externes
- 4 Sicherheit
- 5 Konfigurationsdateien - 5.1 /etc/bind/named.conf.local
- 5.2 /etc/bind/externals/db.example.com
- 5.3 /etc/bind/internals/db.example.com
- Bibliografie
1 Das Problem
Es ist ein typisches Problem in wachsenden Organisationen, dass sie zwei Probleme gleichzeitig lösen müssen:
- Einen DNS-Server für das interne Netzwerk des Unternehmens zu haben, denn vor langer Zeit gab es bereits zu viele Computer, um sich ihre IPs zu merken 1 und sogar zu viele Computer, um eine Reihe von Host-Dateien zu pflegen 2.
- Einen DNS-Server für die externen Server, für externe Kunden usw.
Diese Probleme zu lösen, wird zu einem größeren Problem, wenn die wachsende Organisation nicht mehr Ressourcen als einen DNS-Server bereitstellen kann 3. Es ist ein größeres Problem, weil, wenn Sie Ihren Server einfach mit all Ihren Namen, öffentlich und privat, konfigurieren, Sie am Ende das Internet mit privaten Adressen verschmutzen, was sehr schlecht ist, und auch der Welt einen Teil der Topologie Ihres internen Netzwerks zeigen. Etwas, das Sie einem möglichen Angreifer/Hacker nicht geben möchten.
Der andere Teil des Problems ist, dass Sie aus Effizienzgründen möglicherweise interne IPs auflösen möchten, wenn Sie sich innerhalb des Netzwerks befinden, und externe IPs, wenn Sie sich außerhalb befinden. Hier spreche ich von Computern, die öffentliche und private Verbindungen haben.
Es gibt viele verschiedene Lösungen für dieses Problem, und ich erinnere mich, dass ich es sogar mit BIND4 gelöst habe, aber jetzt werde ich BIND9 verwenden, um eine sehr saubere Lösung zu schaffen. Dies wurde auf einem Debian GNU/Linux 3.1-Server bereitgestellt, sollte aber auch für andere Betriebssysteme, die BIND9 ausführen, funktionieren, stellen Sie nur sicher, dass Sie Ihre Pfade entsprechend ändern.
2 Erste Konfiguration
Stellen wir uns vor, die Organisation, für die ich arbeite, macht Beispiele… von was? Ich weiß es nicht, aber Sie können sie auf example.com bestellen. Die Examples Corporation wurde das Netzwerk 192.0.2.0/24 zugewiesen, und intern verwenden wir 10.0.0.0/24.
Lassen Sie uns beginnen, die externen Namen und IPs zu bedienen, wir bearbeiten /etc/bind/named.conf.local 4 und fügen hinzu:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};und dann erstellen wir /etc/bind/db.example.com mit folgendem Inhalt:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Wir haben unseren Mailserver woanders.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Wir verbinden uns sehr oft mit client1.Wie Sie sehen können, hat unser Start-up einen Computer, der alles bedient, außer Mail, er hält sogar das IP-Forwarding und ein paar Datenbanken.
Jetzt hat eine gute DNS-Konfiguration mindestens einen sekundären Server, und tatsächlich setzen einige Registrar (wo Sie Domainnamen registrieren) dies durch. Da wir keinen zweiten Computer haben, gehen wir zu XName, eröffnen ein Konto und registrieren example.com als sekundär mit 192.0.2.1 als IP, von der übertragen werden soll. Wir müssen jetzt die IP von XName die Übertragung durchführen lassen; wir sind eine kleine Organisation, aber da wir ein erfolgreiches Start-up sein wollen, versuchen wir, alles so klug wie möglich zu machen. Also verwenden wir die BIND9-Konfigurationsanweisung acl, um einen Bezeichner zu definieren, der auf die IP-Adressen von XName verweist; am Anfang von /etc/bind/named.conf.local fügen wir hinzu:
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};und wir ändern die Zonen-Deklaration zu:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { slaves; };
};Wir hätten einfach die IPs dort eingeben können, wo wir “slaves” eingeben.
3 Internes und externes
Jetzt, da wir eine solide Basis haben, können wir anfangen, darüber nachzudenken, unterschiedliche Inhalte für das interne und externe Netzwerk bereitzustellen, aber zuerst müssen wir definieren, was intern und was extern ist.
In /etc/bind/named.conf.local fügen wir die folgende Definition hinzu (am Anfang oder unter der Definition von slaves):
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};Wenn wir mehr interne Netzwerke hätten, könnten wir sie einfach dort hinzufügen. Wir definieren keine externen, weil alles, was nicht intern ist, extern ist. Sie können, wenn Sie möchten, Gruppen von verschiedenen externen definieren, wenn Sie unterschiedlichen Inhalt an verschiedene Teile des Internets bereitstellen möchten.
Wir werden eine neue Funktion von BIND9 namens Views verwenden. Eine View ermöglicht es, ein Stück Konfiguration innerhalb einer Bedingung zu platzieren, die von einer Anzahl von Dingen abhängen kann, in diesem Fall werden wir einfach von internals abhängen. Wir ersetzen die Zonen-Deklaration in /etc/bind/named.conf.local durch:
view "internal" {
match-clients { internals; };
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};Die Konfigurationsanweisung match-clients ermöglicht es uns, diese View bedingt basierend auf einer Gruppe von IPs anzuzeigen, “any” steht für jede IP. Interne IPs werden von der internen View zwischengespeichert, und der Rest wird in der externen View verworfen. Die Außenwelt kann die interne View nicht sehen, und das schließt XName, unseren sekundären DNS-Anbieter, ein, aber wir haben die allow-transfer von der internen View entfernt, da wir nicht möchten, dass jemand unter irgendwelchen Umständen die Inhalte der internen View übertragen kann.
Wir haben auch den Pfad geändert, wir müssen das Verzeichnis /etc/bind/externals und /etc/bind/internals erstellen und /etc/bind/db.example.com nach /etc/bind/externals/ verschieben.
In /etc/bind/internals/db.example.com legen wir eine Zonen-Datei ähnlich der Gegenstück in extern, aber mit den internen IPs:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Großartig, wir können jetzt den Computer unseres Chefs anpingen mit
ping boss.example.comaber der Versuch, mail.example.com zu erreichen, wird uns enttäuschen, was ist passiert? Es gibt keinen Verweis auf mail.example.com in der internen Zonen-Datei, und da wir uns im internen Netzwerk befinden, können wir mail.example.com auflösen. Gut, lassen Sie uns einfach den Inhalt der externen Zonen-Datei in die interne Zonen-Datei kopieren. Das wird funktionieren.
Aber wir sind ein kleines, schlaues Start-up, wir können besser sein, als jede Änderung in die Zonen-Datei zu kopieren und einzufügen, außerdem ist das sehr fehleranfällig (werden Sie sich immer daran erinnern, die interne Zonen-Datei zu ändern, wenn Sie die externe ändern, oder werden Sie es vergessen und einige Tage mit der Fehlersuche von Netzwerkproblemen verbringen?).
Was wir tun werden, ist, die externe Zonen-Datei in die interne Datei auf diese Weise einzuschließen:
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103und voila! Es war schwer, die $include-Direktive in der aktuellen Dokumentation zu finden… Denken Sie nur daran, die Seriennummer der externen Zonen-Datei zu ändern, wann immer Sie die interne ändern, aber das ist kein großes Problem, wenn Sie es vergessen, wird nichts Schlimmes passieren, da Sie wahrscheinlich keine Caching-Server in Ihrem eigenen kleinen Netzwerk haben.
4 Sicherheit
Es wird nicht empfohlen, denselben DNS-Server als primären für eine Domain (in unserem Fall example.com) und als Caching-DNS-Server zu verwenden, aber in unserem Fall sind wir gezwungen, es zu tun. Aus der Außenwelt ist 192.0.2.1 der primäre DNS-Server für example.com, aus unserem eigenen internen Netzwerk ist 192.0.2.1 (oder seine private Adresse, 10.0.0.1) unser Caching-Namensserver, der als Nameserver konfiguriert sein sollte, der auf jedem Arbeitsplatz verwendet wird, den wir haben.
Eines der Probleme ist, dass jemand unseren Caching-Namensserver von außen verwenden könnte, es gibt einen Angriff namens Cache-Poisoning und viele andere böse Dinge, die getan werden können und dokumentiert sind auf [SINS] (einschließlich wie man sie vermeidet).
Um unsere Sicherheit ein wenig zu verbessern, fügen wir ein paar Direktiven zur Konfigurationsdatei hinzu:
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};Das wird verhindern, dass jemand im gefährlichen Internet unseren Server rekursiv verwendet, während wir in unserem eigenen Netzwerk dies weiterhin tun können.
5 Konfigurationsdateien
5.1 /etc/bind/named.conf.local
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};5.2 /etc/bind/externals/db.example.com
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Wir haben unseren Mailserver woanders.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Wir verbinden uns sehr oft mit client1.5.3 /etc/bind/internals/db.example.com
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Bibliografie
SINS
Sichern eines Internet-Namensservers
Fußnoten
… IPs
1
Für mich qualifizieren sich bereits zwei Computer als zu viele Computer, um sich ihre IPs zu merken.
… Dateien
2
Die Host-Datei befindet sich unter /etc/hosts und ist eine einfache Zuordnung für den lokalen Computer von Namen zu IP. Es war der erste Weg, Namen in IPs aufzulösen, und vor langer Zeit wurde eine zentrale große Host-Datei gepflegt, die später per FTP oder ähnlichem verteilt wurde. Sie wuchs schnell zu einem Problem, das durch die Erfindung von DNS gelöst wurde. Versuchen Sie, Ihre Hosts-Datei nicht zu einem Problem wachsen zu lassen, bevor Sie sie in DNS umwandeln, lernen Sie von den Pionieren!
… Server
3
Oder wenn Sie Perfektionist sind und glauben, dass dies mit nur einem Server machbar sein sollte.
…/etc/bind/named.conf.local
4
Es könnte in Ihrem Betriebssystem einfach /etc/bind/named.conf sein, wenn es nicht Debian ist.
Erhalte neue Beiträge in deinem Posteingang.
Kein Spam. Jederzeit abmelden.