
|
 |
|
|
 |
|
 |
 |
| Vorbemerkung |
Dieses Howto beschreibt, wie ein in einem lokalen Netz ein DNS-Server aufgesetzt werden kann. Gleichzeitig enthält es Hinweise für diejenigen, die bisher das weithin eingesetzte BIND nutzen und dieses aus Sicherheits-, Administrations- oder Performance-Gründen ablösen wollen.
tinydns ist ein Programmpaket von Prof. Dan J. Bernstein, der neben dnscache Urheber diverser anderer Programme ist, z.B. von dem u.E. besten MTA (Mail Transfer Agent) qmail.
Die aktuelle Version des tinydns-Pakets ist 1.05. Bernstein hat - wie schon seinerzeit bei Entwicklung des MTA qmail - einen Geldpreis (500 US$) ausgelobt für denjenigen, der Sicherheitslücken in diesem Programmpaket entdeckt. Bei qmail wurde dieser Geldpreis bis heute nicht eingefordert...
|
|
|
|
|
| Was ist tinydns bzw. dnscache? |
tinydns (der frühere Name lautete dnscache) besteht aus mehreren Programmen, mit denen ein vollwertiger lokaler DNS-Server aufgebaut und getestet werden kann. U.a. sind in diesem Paket auch Programme mit gleichem Namen (also tinydns bzw. dnscache) enthalten. Wenn im folgenden von dnscache gesprochen wird, ist damit das Programm, nicht das Paket gemeint.
dnscache
Hiermit wird ein lokaler Caching-Server eingerichtet, der dazu dient, DNS-Anfragen an die zuständigen Domain-Server weiterzugeben und das gelieferte Ergebnis für einen bestimmbaren Zeitraum für zukünftige Anfragen aus dem lokalen Netz zu speichern.
dnscache ist ein vollwertiger DNS-Server, nach seiner Installation werden entsprechende Anfragen an die dafür zuständigen DNS-Server weitergeleitet, sofern die Antwort nicht schon bekannt ist und sich im Cache befindet. Anfragen aus dem Netz auf Port 53 werden entweder aus dem Cache oder durch ``Rückfrage'' bei den zuständigen Servern beantwortet. Hierbei akzeptiert dnscache ausschließlich Antworten von den definitiv zuständigen Servern, DNS-Spoofing ist so nicht möglich. Die Einrichtung eines DNS-forwarders wie z.B. mit BIND ist in der bekannten Form nicht mehr möglich, was sich hier in der Praxis allerdings nicht als störend erwiesen hat. Trotz des Verzichts auf einen forwarder ergaben sich keine Verschlechterungen der Performance - im Gegenteil.
tinydns
Hiermit wird der DNS-Server für das lokale (private) Netz eingerichtet, da die lokal vergebenen Namen sonst nicht aufgelöst werden können. Bei tinydns handelt es sich aber um einen vollwertigen DNS-Server, der so genau so gut für vollwertige, nicht-private Netze verwendet werden kann. Dafür sind dann weitere Tools verfügbar, dies ist aber nicht Bestandteil dieses Mini-HOWTOs.
DNS lookup tools
Mit diesen - ebenfalls im Programmpaket enthaltenen - Programmen können verschiedene DNS-Abfragen durchgeführt werden. Die Ausgabe entspricht im Ergebnis der des bekannten nslookup, nur lassen sich diese Ausgaben wesentlich einfacher durch andere Programme weiterverarbeiten. Selbstverständlich kann aber auch nslookup weiter eingesetzt werden.
|
|
|
|
|
| Voraussetzungen |
Für den Einsatz von tinydns bzw. dnscache ist Voraussetzung, daß die ebenfalls von Bernstein entwickelten daemontools installiert sind. Für den Betrieb von dnscache ist svscan zu installieren und in Betrieb zu nehmen. Eine englische Installationsanleitung ist unter o.g. URL zu finden.
Installation der daemontools bzw. svscan
Nach dem Download von o.g. URL ist das Archiv mit
tar xpfz daemontools-X.XX.tar.gz
zu entpacken und anschließend in das dabei erzeugte Verzeichnis zu
wechseln. Mit
./package/install
werden die einzelnen Programme erzeugt und auch gleich installiert.
Als Standard erwartet svscan ein Verzeichnis /service auf root-Ebene, dieses wird ebenfalls von o.g. Skript angelegt, sofern es noch nicht existiert. Ebenfalls angelegt wird das Verzeichnis /command, wo nach der umstrittenen Auffassung von Bernstein systemnahe binaries installiert werden sollen... Die binaries aus o.g. Paket werden jedenfalls per default in diesem Verzeichnis installiert, zusätzlich wird in der /etc/inittab der Eintrag
SV:123456:respawn:/command/svscanboot
eingefügt, der dafür sorgt, daß die daemontools (bzw. besser svscan) automatisch bei jedem Systemneustart initialisiert werden.
Der in früheren Versionen (bis 0.70) noch erforderliche manuelle Start von svscan ist nicht mehr erforderlich.
Mit
ps ax |grep svscan
kann geprüft werden, ob die daemontools (bzw. svscan, "die Mutter" aller unter Kontrolle der daemontools laufenden Prozesse) tatsächlich gestartet wurden. Ebenfalls gestartet wurde dann ein Prozess readproctitle, der dafür zuständig ist, die letzten 500 Bytes aus eventuellen Fehlermeldungen von z.B. nicht startbaren services in der Prozeßübersicht anzuzeigen (z.B. mittels ps ax).
Sofern BIND noch läuft, ist jetzt ein guter Zeitpunkt, diesen Service zu beenden mit
/etc/rc.d/init.d/named stop
und ggf. vorhandene Links in den entsprechenden
Runlevel-Verzeichnissen zu löschen. Dies sollte natürlich nur
geschehen, wenn gewährleistet ist, daß keine anderen Prozesse während der nachfolgend beschriebenen Konfiguration auf DNS-Services angewiesen sind. Ggf. per cron gestartete Prozesse sollten für die Dauer der Umstellung deaktiviert werden.
Ausgangssituation
Im folgenden gehe ich davon aus, daß ein lokales Netz mit privaten
IP-Adressen vorhanden ist und daß ein Rechner z.B. per
ISDN-Wählleitung mit dem Internet verbunden ist. Hier ist z.B. dieses
lokale Netz mit folgender Konfiguration vorhanden:
| Rechner |
Interface |
IP-Adresse |
| main |
eth0 |
192.168.100.1 |
| main |
ippp0 |
192.168.100.201 |
| train |
eth0 |
192.168.100.99 |
| prn01 |
eth0 |
192.168.100.191 |
| ... |
... |
... |
Anmerkung: Die IP-Adresse des ISDN-Devices wird dynamisch geändert, sobald eine Verbindung aufgebaut wurde.
Der Rechner main ist demzufolge zentrales Gateway und Router, der entsprechende Eintrag aus den init-Skripten auf main sieht also so aus:
route add default ippp0
Auf den anderen Rechnern im Netz müssen natürlich ebenfalls entsprechende Default-Routen eingerichtet sein, dies geht mit
route add -host 192.168.100.1 eth0 und route add default gw 192.168.100.1
Die Einrichtung der jeweiligen Interfaces bzw. Devices mittels ifconfig ist nicht Bestandteil dieses HOWTOs.
resolv.conf
Sofern bisher kein eigener DNS-Server installiert war, muß die Datei /etc/resolv.conf eingerichtet bzw. angepaßt werden. Diese Datei sollte die zwei Zeilen
search yourdomain.dom nameserver 192.168.100.1
beinhalten. Die erste Zeile sorgt dafür, daß nach Inbetriebnahme des
DNS-Servers lokale Rechnernamen auch ohne Angabe der Domain aufgelöst
werden können, die zweite Zeile verweist auf den Rechner, der
zukünftig für die Beantwortung von DNS-Anfragen zuständig ist.
Diese Datei sollte auf allen Rechnern im lokalen Netz - sofern sie unter Linux laufen - vorhanden sein. Bei Win-Rechnern sind die entsprechenden Einträge in der Systemsteuerung / Netzwerk vorzunehmen.
Hinweis für SuSE-Nutzer: Sofern o.g. Datei manuell erzeugt wird, ist in der Datei /etc/rc.config CREATE_RESOLVCONF auf ``no'' zu ändern bzw. die DNS-relevanten Parameter entsprechend anzupassen.
|
|
|
|
|
| Einrichtung einer weiteren IP für den Nameserver |
Für den Betrieb von dnscache und tinydns sind zwei verschiedene IP-Adressen erforderlich. Es ist nicht möglich, beide Programme gleichzeitig unter einer IP zu nutzen.
Am sinnvollsten und einfachsten ist es, tinydns auf dem loopback-device (127.0.0.1) aufzusetzen, da dieses schon vorhanden ist und tinydns ja nur für die DNS-Anfragen zuständig soll, für die der lokale Rechner die ``Hoheit'' hat. (Dank an Felix von Leitner nicht nur für diesen Tipp)
|
|
|
|
|
| Konfiguration von tinydns und dnscache |
Als Ausgangspfad wurde hier /etc gewählt, selbstverständlich
kann auch ein anderer Pfad (z.B. /var) gewählt werden.
Erforderliche User einrichten
Die o.g. Programme laufen auch aus Sicherheitsgründen unter eigenen
Benutzerkennungen in einer chroot-Umgebung. Vor der eigentlichen
Konfiguration müssen daher zunächst von root drei Benutzer
eingerichtet werden:
useradd -g nofiles tinydns
useradd -g nofiles dnscache
useradd -g nofiles dnslog
Die Einrichtung der entsprechenden Home-directories ist nicht erforderlich.
tinydns - Nameserver für interne Adressen
Als root mit
tinydns-conf tinydns dnslog /etc/tinydns 127.0.0.1
zunächst den Nameserver für das lokale private Netz einrichten.
Im Anschluß daran in das Verzeichnis /etc/tinydns/root
wechseln und mit
./add-ns yourdomain.dom 127.0.0.1 sowie
./add-ns 100.168.192.in-addr.arpa 127.0.0.1
die entsprechende DNS- und reverse-Zone anlegen, dabei nicht
vergessen, den Namen und die IP-Range den lokalen Anforderungen
entsprechend anzupassen. :-)
Mit
./add-host main.yourdomain.dom 192.168.100.1
./add-host prn01.yourdomain.dom 192.168.100.191 ...
die im lokalen Netz vorhandenen Hosts dem DNS-Server mitteilen.
Sofern für einzelne Rechner sog. Aliase vorhanden sind, müssen diese auch noch dem DNS-Server mitgeteilt werden. Mit
./add-alias news.yourdomain.dom 192.168.100.1
wird dem DNS-Server z.B. mitgeteilt, daß der Rechner main auch unter
dem Namen news erkannt werden soll.
Abschließend sollte - sofern vorhanden - dem DNS-Server noch mitgeteilt werden, auf welchem Rechner ein MTA für die gerade eingerichtete Domain läuft. Mit
./add-mx yourdomain.dom 192.168.100.1
wird z.B. dieser Rechner als der MX mit der höchsten Priorität für yourdomain.dom festgelegt.
Die Datei /etc/tinydns/root/data enthält alle o.g. Angaben in lesbarer Form. Nach Abschluß der o.g. Arbeiten kann mit
make
die Erzeugung der von tinydns benötigten Tabellen gestartet werden.
dnscache - Caching DNS für externe Adressen
Wiederum als root mit
dnscache-conf dnscache dnslog /etc/dnscache 192.168.100.1
die Grundkonfiguration des dnscache starten.
ACHTUNG: Die hier verwendete IP muß sich von der für tinydns verwendeten unterscheiden, sofern beide Programme auf der gleichen Maschine ausgeführt werden sollen.
Aus Sicherheitsgründen beantwortet dnscache zunächst nur Anfragen des eigenen Hosts. Um Anfragen aus dem gesamten lokalen Netz zu akzeptieren ist eine ensprechende Datei in /etc/dnscache/root/ip erforderlich. Mit
touch /etc/dnscache/root/ip/192.168
wird dnscache mitgeteilt, daß alle Anfragen aus dem privaten Netz beantwortet werden dürfen (also auch z.B. Anfragen von 192.168.0.2).
Schließlich muss dnscache noch mitgeteilt werden, daß es für bestimmte Domains nicht die üblichen Abfragen durchführen soll. Dies betrifft insbesondere ggf. weiter oben eingerichtete lokale Domain. Hierfür werden zwei Dateien benötigt, eine für ``normale'' DNS-Anfragen und eine für die reverse-lookups (also das Ermitteln des Namens anhand der IP). Mit
echo ``127.0.0.1'' > /etc/dnscache/root/servers/yourdomain.dom und
echo ``127.0.0.1'' > /etc/dnscache/root/servers/100.168.192.in-addr.arpa
wird dnscache mitgeteilt, daß Anfragen über diese Domain von dem genannten DNS-Server 127.0.0.1 (IP-Nummer des loopback-device) beantwortet werden, also von dem Host, der im vorhergehenden Abschnitt konfiguriert wurde. Auf diese Weise lassen sich auch für andere Domains abweichende DNS-Server einrichten.
|
|
|
|
|
| Start it up |
Der (dauerhafte) Start der oben eingerichteten Programme ist sehr simpel, da svscan als Bestandteil der oben eingerichteten daemontools automatisch alle Programme startet, die einen entsprechenden Link in /service haben. Deshalb reichen
ln -s /etc/tinydns /service und
ln -s /etc/dnscache /service
aus, damit beide Programme innerhalb von maximal 5 Sekunden ihren Dienst aufnehmen. Mit ps ax kann das ggf. kontrolliert werden.
|
|
|
|
|
| Testen, ob alles funktioniert |
Ob die Installation erfolgreich war, kann mit den im Programmpaket dnscache vorhandenen DNS-Tools getestet werden.
| Befehl |
Ergebnis |
| lokale Adressen |
| dnsip localhost |
127.0.0.1 |
| dnsip main.yourdomain.dom |
192.168.100.1 |
| dnsname 192.168.100.191 |
prn01.yourdomain.dom |
| dnsmx yourdomain.dom |
0 a.mx.yourdomain.dom |
| externe Adressen |
| dnsip www.bettercom.de |
212.202.242.68 |
| dnsname 204.148.40.9 |
helio.ora.com |
| dnsmx bettercom.de |
12801 a.mx.bettercom.de |
Selbstverständlich kann auch mit dem bekannten nslookup gearbeitet werden, auch dann müssen die o.g. Ergebnisse geliefert werden, sonst ist die Konfiguration nicht ordnungsgemäß erfolgt.
Wenn alles so funktioniert, wie oben dargestellt:
Herzlichen Glückwunsch zum eigenen vollwertigen und sicheren DNS-Server.
|
|
|
|
|
|
 |
|



bettercom
IT-Services
Gemündener Strasse 7
D - 61276 Weilrod
Phone +49-6083-329090
ml-info@bettercom.de
|