silvesterlangen.de
BIND9
Update: Das Tutorial funktioniert ohne Probleme 1:1 mit Debian Stretch sowie CentOS.
BIND ist der Berkley Internet Name Domain Server in der Version 9. Neben einfachem Resolving ist er in der Lage selbst Zonen autoritativ zu verwalten und mit weiteren Nameservern zusammen für die selben Zonen zuständig zu sein. Dazu können mehrere BIND-Server verbunden werden und für Domains als Primary-, Secondary-, usw. Nameserver zu arbeiten. Entsprechende Einträge werden in der Domain beim Registrar hinterlegt. Die Zonen werden mittels gesicherter Verbindung vom Primary zum Secondary übertragen sobald eine Änderung in der Zone vorgenommen wurde.
Der Bind ist mit großem Abstand der im Internet weit verbreiteste Name Server überhaupt. Auch, wenn die Konfiguration von vielen für schwierig erachtet wird und BIND recht alt ist. Ein Grund mehr sich dieses geniale Stück Software anzusehen.
Rahmenbedingungen für diesen Aufbau:
Es dient eine virtuelle Maschine in VMWare als Hostsystem. Installiert ist Debian 8 (Jessie) in einer Minimalinstallation, also nur die Systemtools. Auf das X-Window-System und sonstigen Schnickschnack habe ich wie immer verzichtet. Die VM hat 512 Mb Ram, 2 CPUs mit zwei Kernen und hat 20 Gb Plattenplatz. Ein Internetzugriff findet über NAT statt für evtl. Nachinstallationen von Software. Wichtig ist, dass die VM eine feste IP hat und nicht vom DHCP bezogen wird. Ich habe als fixe IP 192.168.2.117 gesetzt. Das Gateway ist 192.168.2.1
Die Installation:
Wir beginnen damit zunächst aus dem Repository den Bind zu installieren. Dazu muss man als Root angemeldet sein und folgendes in die Prompt eingeben:
apt-get install bind9
Der Bind ist installiert. Jetzt geht es an die Konfiguration. Die Konfigurationsdateien befinden sich unter /etc/bind/ und müsen angepasst werden. Zuerst kopieren wir die db.local, um eine Kopie davon zu haben, die wir nur noch bearbeiten müssen. Als Beispiel gilt hier: brainworld.lpic.zone
;
; BIND data file for local loopback interface
;
$TTL 604800
brainworld.lpic. IN SOA landns.brainworld.lpic. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; festlegen des NS für die Zone brainworld.lpic
brainworld.lpic. IN NS landns.brainworld.lpic.
brainworld.lpic. IN A 192.168.2.117
; festlegen der Hosts, die unterhalb von brainworld.lpic sind
workstation.brainworld.lpic. IN A 192.168.2.118
fileserver.brainworld.lpic. IN A 192.168.2.119
lanmail.brainworld.lpic. IN A 192.168.2.120
Die Datei named.conf.default-zones ebenfalls editieren und um folgenden Eintrag erweitern:
zone "brainworld.lpic" {
type master;
file "/etc/bind/brainworld.lpic.zone";
};
Dann in der named.conf.options die Zeile mit // auskommentieren, damit der Bind IPv6 ignoriert und keine Zoneneinträge erwartet. Ansonsten würde er das bei restart bemängeln, weil wir keine IPv6-Einträge haben.
//listen-on-v6 { any; }
Nun den bind restarten mit systemctl restart bind9 und dann mit systemctl status bind9 schauen, ob er problemlos gestartet ist. Wenn er nichts angemeckert hat, dann probieren wir mal Bind aus, ob es funktioniert.
host -l brainworld.lpic 127.0.0.1
Wenn alles richtig gelaufen ist, dann erhält man eine Liste mit allen Einträgen, die man in der Domain so hat und den dazugehörigen IP-Adressen.
Nun ist die Sache die, dass der Nameserver zwar eigene Domainnamen "auflösen" kann sofern er die Zone hat, aber beispielsweise www.google.de oder heise.de nicht auflösen könnte. Woher soll er das auch wissen. Allerdings haben wir die Möglichkeit unserem Bind zu sagen, dass er einen anderen Nameserver fragen darf, wenn Anfragen reinkommen für dessen Zonen er aber nicht zuständig ist. Um das zu erreichen editieren wir die Datei named.conf.options noch mal. Dort setzen wir auch gleich weitere Einträge, die dafür sorgen, dass der Nameserver auf allen Netzwerkinterfaces lauscht und jede eintreffende Anfrage beantwortet.
Dort befindet sich ein auskommentierter Bereich (meist 3 - 4 Zeilen), die man zunächst einkommentiert und dann wie folgt aussehen lässt.
// horcht auf allen Interfaces (eth0 usw)
listen-on port 53 { any; };
// bearbeitet jede eintreffende Anfrage
allow-query { any ;};
// Falls der NS eine Zone nicht kennt, dann holt er sich
// die Info bei den Google-Nameservern
forwarders {
8.8.8.8;
8.8.4.4;
};
Den Bind wieder restarten und dann sollte er absofort alle eintreffenden Anfragen bearbeiten und bereit für weitere Zonen sein. Noch als kleiner Hinweis: Der Bind ist ziemlich zickig und sehr genau, was die Schreibweise in der Zone-Files angeht. Einen Punkt vergessen und schon geht der Spaß los, denn dann lädt er diese defekte Zone nicht. Immer als erstes nach dem Domainnamen direkt nach dem Punkt suchen. Fehlerquelle Nr. 1 !!!
Böse Seiten blocken
Der DNS lässt sich auch super nutzen, um böse Websites zu blocken. Auf der Seite malwaredomains.lehigh.edu wird eine Liste mit bösen Websites gepflegt, die freundlicherweise für jedermann bereitgestellt wird. Diese machen wir uns zu nutze.
Zuerst legen wir einen weiteren Eintrag in die named.conf an:
include "/etc/bind/named.conf.blocked";
Dann legen wir eine Datei in /etc/bind/ an:
touch /etc/bind/fetchMalwarelist.sh
Diese füllen wir mit folgendem Inhalt:
rm -rf /etc/bind/named.conf.blocked
wget -O /etc/bind/malmwaredomains -q "http://malwaredomains.lehigh.edu/files/justdomains"
while read entry
do
if [ -n "${entry}" ]
then
echo "zone \""$entry"\" {type master; file \"/etc/bind/db.empty\";};" >> /etc/bind/named.conf.blocked
fi
done < /etc/bind/malmwaredomains
/etc/init.d/bind9 reload
Die Datei dann mit chmod +x /etc/bind/fetchMalwarelist.sh
ausführbar machen. Danach das gerade erstellte Shellscript ausführen.
Der DNS braucht jetzt eine Weile, weil er sehr viele Zonendaten laden
muss.
Ab jetzt können diese Domänen nicht mehr aufgelöst werden und somit der Inhalt nicht mehr geladen werden. ;-)
