[[Vorlage(Archiviert)]] 
[[Vorlage(Fortgeschritten)]] 

{{{#!vorlage Wissen
[:Terminal: Ein Terminal öffnen] 
[:Editor: Einen Editor öffnen] 
[:DNS-Server_Bind: Bind - Basiskonfiguration] 
[:chroot: Hintergrund von chroot] 
}}}
[[Inhaltsverzeichnis(2)]] 

Standardmäßig lauscht der Bind-Daemon auf allen verfügbaren Netzwerkschnittstellen. Dies kann unerwünscht sein, wenn man ihn bspw. auf einem Gateway betreibt, ohne die interne Zone im Internet preisgeben zu wollen. Wie man das ändern kann, wird nachfolgend beschrieben.

= Netzwerkschnittstellen =
Zur Änderung der Netzwerkschnittstellen muss man in einem Editor mit Root-Rechten [2] die Datei '''named.conf.options''' bearbeiten und die folgende Zeile in den ''options''-Block eintragen: 

{{{
        listen-on { 127.0.0.1; 192.168.0.10; };
}}}

Die Angabe der IP-Adresse `192.168.0.10` muss natürlich an die IP-Adresse des Bind-Servers im lokalen Netzwerk angepasst werden. Wichtig ist auch, den ''Localhost'', also `127.0.0.1`, nicht zu vergessen, sowie auf die korrekte Verwendung der Semikolons zu achten. 

= Clientzugriff beschränken =

{{{#!vorlage Hinweis
Dieser Abschnitt ist nur dann wirklich relevant, wenn der Server aus dem Internet erreicht werden kann. Wer seinen Nameserver in einem lokalen Netz betreibt, das durch einen NAT-Router vom Internet getrennt ist, kann auf diese Absicherung getrost verzichten. 
}}}

Wer seinen Nameserver nicht für das gesamte Internet betreiben will, sondern nur für seine eigenen Rechner, der wird den Zugriff darauf beschränken wollen. Auch hierfür gibt es eine Option, die bspw. wie folgt in die Datei '''/etc/bind/named.conf.options''' eingetragen wird: 

{{{
        allow-query { 192.168.1.0/24; };
}}}

Hierbei ist es auch möglich, mehrere Netze oder auch einzelne Hosts in die Direktive einzubeziehen. 

Wer selber eine öffentliche Zone für das Internet bedient, darf natürlich entfernten Rechnern nicht den Zugriff versperren. Andererseits möchte man aber sicher auch nicht, dass Fremde den eigenen Nameserver evtl. als Standard eintragen und dadurch unnötigen Traffic zu eigenen Lasten verursachen. Mit der folgenden Direktive erlaubt man deshalb nur den eigenen Clients, reguläre ''(rekursive)'' Anfragen an den Nameserver zu stellen, während allen anderen Clients nur Anfragen über die eigene Zone beantwortet werden: 

{{{
        allow-recursion { 192.168.1.0/24; };
}}}

In größeren Installationen ist es oft sogar sinnvoll, die Funktionen zu trennen, indem man den eigenen Clients einige mit ''allow-query'' zugriffsbeschränkte Nameserver zur Namensauflösung zur Verfügung stellt, und für die Verwaltung der eigenen Zone andere verwendet. Bei diesen kann man dann die rekursive Auflösung ganz abstellen: 

{{{
        recursion no;
}}}

= Forwarders =
Normalerweise fragt sich ein Nameserver auf der Suche nach der gewünschten IP-Adresse rekursiv, von den sogenannten ''Root-Servern'' ausgehend, durch, bis er den Server gefunden hat, der ihm die richtige Antwort geben kann. Manchmal ist dieses Verhalten jedoch nicht erwünscht und der Server soll stattdessen lieber alle Anfragen, die er nicht direkt selber beantworten kann, einfach nur an bestimmte Nameserver weiterleiten, bspw. die des eigenen Providers, oder die Hauptnameserver eines Intranets. 

In diesem Fall muss man die betreffenden Server, wie im Folgenden beschrieben, im ''options''-Block der Datei '''/etc/bind/named.conf.options''' eintragen: 

{{{
        forwarders { a.b.c.d; w.x.y.z; };
}}}

Antworten die Forwarder aus irgendwelchen Gründen nicht, so fällt Bind automatisch auf das erstgenannte Verfahren zurück und versucht "auf eigene Faust" die Anfrage zu befriedigen. Das kann man aber auch verhindern, in welchem Fall stattdessen eine Fehlermeldung zurückgegeben würde: 

{{{
        forward only;
}}}

= Chroot-Umgebung =
Nameserver sind leider überdurchschnittlich häufig Angriffen aus dem Internet ausgesetzt, und in der Geschichte von Bind gab es auch schon mal die eine oder andere Sicherheitslücke. Deswegen kann man auf einem exponierten Server einen gewissen Sicherheitsgewinn erlangen, indem man den Bind-Daemon in einer chroot-Umgebung [4] laufen lässt. Praktischerweise ist eine chroot-Funktion bereits in den Server integriert, so dass man auf die aufwendige Vollausstattung der chroot-Jail, wie im Artikel [:chroot:] beschrieben, verzichten kann. Ein wenig Mehrarbeit gegenüber einer herkömmlichen Installation muss man aber trotzdem in Kauf nehmen. 

{{{#!vorlage Hinweis
Da die folgenden Schritte alle als root ausgeführt werden müssen, und man als normaler Benutzer teilweise nicht mal die entsprechenden Verzeichnisse betreten darf, empfiehlt sich die Benutzung von `sudo -s`. 

Die Existenz einer funktionierenden Bind9-Installation [3] wird vorausgesetzt. 
}}}

== Einrichten der Umgebung ==
Als erstes braucht man ein Verzeichnis, in dass der Server dann "chrooted" wird, und das sowohl die Konfigurationsdateien, als auch alle Laufzeitdaten aufnimmt. Ein geeigneter Ort wäre bspw. ein Verzeichnis namens '''/var/named'''. Die variablen Daten, bspw. die Process-ID (normalerweise in '''/var/run''' zu finden) und Slave-Zonen ('''/var/cache/bind'''), sollten dort ihre eigenen Verzeichnisse bekommen, damit man dem Daemon keine Schreibrechte auf das normale Konfigurationsverzeichnis einräumen muss. Mit den geeigneten Besitzverhältnissen und Rechten sollte das dann nach diversen chown- und chmod-Befehlen ''exakt'' so aussehen: 

{{{#!vorlage Befehl
ls -ld /var/named/
}}}

Ausgabe:

{{{
drwxr-x--- 4 root bind 1024 2006-08-15 22:26 /var/named/
root@server:~# ls -l /var/named/
drwxrwx--- 2 root bind 1024 2006-08-15 21:55 cache
drwxrwx--- 2 root bind 1024 2006-08-15 22:30 pid
}}}

Nun müssen noch alle Dateien aus '''/etc/bind''' in dieses Verzeichnis verschoben werden. 

== Anpassen der Konfiguration ==
Die Pfade in den Konfigurationsdateien stimmen natürlich jetzt alle nicht mehr, und müssen angepasst werden. Durch die Art, wie eine chroot-Umgebung funktioniert [4], ist das Verzeichnis '''/var/named''' dem Daemon im chroot jetzt nur noch als '''/''' bekannt. 

In der Datei '''named.conf''' müssen deswegen ''alle'' Vorkommen von '''/etc/bind''' durch '''/''' ersetzt werden. Beispiel: 

{{{
include "/named.conf.options";
}}}

Auch in '''named.conf.local''' und, nicht zu vergessen, in der '''named.conf-default-zones''' sind entsprechende Anpassungen vorzunehmen. Bei relativen Pfadangaben, wie '''back/domainname.bak''', wird der komplette Pfad entfernt: 

{{{
file "domainname.bak";
}}}

Die größten Anpassungen sind in der Datei '''named.conf.options''' vorzunehmen. Im `options`-Block ist die `directory`-Direktive in geeigneter Form abzuändern und ein Pfad für die Process-ID-Datei festzulegen: 

{{{
       directory "/cache";
       pid-file "/pid/named.pid";
}}}

{{{#!vorlage Warnung
Die folgenden Direktiven sind im Gegensatz zu allen bisherigen Änderungen an der '''options'''-Datei am Ende der Datei, unterhalb der geschweiften Klammer, die den `options`-Block abschließt, einzutragen. 
}}}

{{{
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};

include "/rndc.key";
}}}

== AppArmor ==
Abschließend muss noch das AppArmor-Profile von BIND angepasst werden. Dieses findet man unter '''/etc/apparmor.d/usr.sbin.named'''. In dieser Datei fügt man unter:

{{{
/etc/bind/** r,
}}} 

nun den Eintrag mit dem chroot-Verzeichnis 
{{{
/var/named/** r,
}}}

mit ein und lädt das AppArmor-Profile mit dem Befehl

{{{#!vorlage Befehl
sudo aa-enforce /etc/apparmor.d/usr.sbin.named
}}}

neu.

== Umstellung des Servers ==
Da das Hilfstool `rndc`, das von den Startskripten verwendet wird, den zugehörigen Schlüssel im Verzeichnis '''/etc/bind''' erwartet, sollte als erstes dort im inzwischen leeren Verzeichnis ein symbolischer Link auf die Datei '''/var/named/rndc.key''' angelegt werden. 

Dann muss man ein paar zusätzliche Optionen in der Datei '''/etc/default/bind9''' eintragen: 

{{{
OPTIONS="-u bind -t /var/named -c /named.conf"
}}}

Und zum Abschluss muss der Server neu gestartet werden: 

{{{#!vorlage Befehl
/etc/init.d/bind9 restart
}}}

In der Datei '''/var/log/daemon.log''' kann man dann nachsehen, ob alles auch reibungslos geklappt hat. Außer den folgenden zwei Zeilen, die man ignorieren kann, sollten dort keine Fehler auftauchen: 

{{{
could not open entropy source /dev/random: file not found
using pre-chroot entropy source /dev/random
}}}

Dass der Server wirklich im chroot läuft, kann man durch ein Auflisten des zur Bind-Pid gehörigen '''/proc'''-Unterverzeichnisses kontrollieren (Ausgabe gekürzt): 

{{{#!vorlage Befehl
ls -l /proc/`ps aux | grep '\/usr\/sbin\/[n]amed' | awk '{ print $2; }'`
}}}
Ausgabe:
{{{
lrwxrwxrwx 1 root root 0 2006-08-16 00:17 cwd -> /var/named/cache
lrwxrwxrwx 1 root root 0 2006-08-16 00:17 exe -> /usr/sbin/named
lrwxrwxrwx 1 root root 0 2006-08-16 00:17 root -> /var/named
}}}

= Links =
 * [:DNS-Server_Bind:] - Hauptartikel

# tag: Server, Netzwerk, dns