Nachdem sich die ersten beiden Teile der Artikelserie eingehend mit Aufbau und Konfiguration eines Nameservers beschäftigt haben, widmet sich dieser Beitrag dynamischen DNS-Updates und sowie dem Thema Sicherheit und DNS.
Unter Linux und vielen anderen Unix-Systemen kommt als Nameserver das Paket BIND (Berkeley Internet Name Domain) zum Einsatz, das wir im Folgenden genauer betrachten werden. Von dieser Implementierung gibt es auch eine Windows-Portierung. Ausführliche Informationen zur Konfiguration und zum stabilen Betrieb eines Nameservers finden Sie in den Quellen zu BIND. Zunächst folgt eine eingehende Beschreibung der Optionen für die Datei named.boot, aufbauend auf dem zweiten Teil der Serie.
Die Artikelserie basiert auf dem Kapitel 22 des Standardwerks „Linux Systemadministration, Einrichtung, Verwaltung, Netzwerkbetrieb“ von Jochen Hein aus dem Verlag Addison-Wesley. Sie können dieses über 600 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
Betrieb eines Nameservers |
Optionen in der Datei named.boot
Das Verhalten von named kann durch einige weitere Einträge beeinflusst werden. Die wichtigsten finden Sie hier erläutert, eine vollständige Dokumentation entnehmen Sie bitte dem BIND Administrators Reference Manual, das den BIND-Quellen beiliegt.
option forward only
Es werden nur die angegebenen Forwarder befragt. Der früher verwendete Eintrag slave sollte nicht mehr verwendet werden. In der Version 8 von BIND hiess die Option forward-only.
logging
Protokollierung kann sehr flexibel konfiguriert werden. Neben normalen Logs können Sie zur Fehlersuche auch alle Anfragen protokollieren. Logs können mittels syslog oder in Dateien geschrieben werden. Wenn Sie besondere Wünsche haben, werfen Sie einen Blick in die BIND-Dokumentation.
option recursion no
Normalerweise beschafft ein Nameserver die gewünschten Daten für den Client, selbst wenn er nicht direkt zuständig ist. Das hat den Vorteil der guten Cache-Bildung, würde aber bei den Root-Nameservern, von denen alle Zonen delegiert werden, zu einer sehr grossen Belastung führen. Diese Server liefern nur einen Verweis auf den zuständigen Rechner und nicht die gewünschten Daten. Diesen Eintrag sollten Sie nicht verwenden.
allow-Option
BIND9 gestattet es, den Zugriff auf verschiedene Funktionen einzuschränken. Mit der Option allow-transfer kann der Zugriff auf die gesamten Zonendaten mittels Zonentransfer auf Rechner aus den angegebenen Netzen beschränkt werden. Damit kann man eine einfache Form der Zugriffskontrolle implementieren. Besonders nützlich ist das nicht, da immer noch die Möglichkeit besteht, die zugeordneten IP-Adressen mittels Reverse-Lookupzu durchsuchen. Diese Option können Sie auch je Zone angeben, dann wird der Standardwert überschrieben. Weitere Optionen zur Zugriffskontrolle finden Sie in der BIND-Dokumentation erläutert.
include
Sie können die Datei named.boot aufteilen und die einzelnen Teile mittels include einlesen. Das kann interessant sein, wenn Sie viele Zonen verwalten und diese möglicherweise von verschiedenen Personen betreut werden.
bogus
Es kann vorkommen, dass fremde Nameserver fehlerhafte Daten liefern. Mit der Option bogus lässt sich verhindern, dass ein derartig verseuchter Nameserver befragt wird.
max-cache-size
Ein großer Nameserver kann eine beachtliche Last auf eine Maschine bringen. Mit der Option max-cache-size können Sie die Größe des DNS-Cache beschränken. Eine weitere Option, um den Speicherbedarf einzuschränken, ist recursive-clients. Hier können Sie die Anzahl der rekursiven Anfragen beschränken, die für Clients durchgeführt werden.
check-names master|slave|response warn|fail|ignore
named kann die Namen in den Zonen auf Gültigkeit prüfen. Alte Versionen von BIND ignorierten fehlerhafte Namen stillschweigend, bei aktuellen Versionen kann man wählen, ob named eine Warnung ausgeben (warn), einen Fehler melden (fail) oder den Fehler wie gewohnt ignorieren soll (ignore). Die Einstellung kann getrennt für primäre und sekundäre Zonen erfolgen.
BIND kennt noch eine ganze Reihe weiterer Optionen. Für viele Fälle werden Sie diese nicht benötigen. Sollten Sie dennoch etwas vermissen, werfen Sie einen Blick in die BIND-Dokumentation.
Steuerung des named-Prozesses
Das Programm named, das den Nameservice bereitstellt, läuft in der Regel als Dämon im Hintergrund. Die Steuerung erfolgt über Signale, die in der Manpage zu named dokumentiert sind. Als Vereinfachung existiert das Programm rndc, mit dem die wichtigsten Signale versendet werden können. Mögliche Parameter sind:
stop
Stoppen des named.
status
Zeigt die wichtigsten Server-Parameter an, insbesondere die Anzahl der Zonen und ob der Server aktiv ist.
dumpdb
named schreibt die aktuelle Datenbank und den Cache in die Datei named_dump.db. Diese Funktion ist zur Fehleranalyse manchmal recht nützlich.
reload [Zone]
named lädt die angegebene Zone neu. Wenn keine Zone angegeben wird, dann liest named die Konfiguration und alle Zonen neu ein.
stats
Der Nameserver schreibt seine Statistik in die Datei, die in der Option statistics-file angegeben ist. Standardwert ist named.stats.
trace
Der Tracelevel wird erhöht und mehr Informationen werden in der Datei /var/tmp/named.run protokolliert.
notrace
Der Tracelevel wird um eins verringert und entsprechend weniger Informationen werden protokolliert.
rndc kann nicht nur auf dem lokalen Rechner verwendet werden. Mit der Option -s kann ein anderer Server und mit -p ein anderer Port als der Standardwert 953 angegeben werden. Damit das sicher funktioniert, muss der Server mit der Option controls konfiguriert werden. Sie können Zugriffe auf IP-Adressen einschränken oder mittels kryptographischen Schlüsseln authentifizieren. In der Standardinstallation kann der Nameserver nur vom localhost aus konfiguriert werden.
Betrieb eines Nameservers
Die Programme aus dem BIND-Paket sind so stabil, dass im täglichen Betrieb kaum mit Problemen zu rechnen ist. Insbesondere ist der Betrieb eines Secondary- DNS praktisch wartungsfrei. Dennoch sollte man ab und zu einen Blick in die Log-Dateien werfen, insbesondere, wenn man die Daten der Zone geändert hat.
Eine solche Änderung ist nicht sofort auf allen Rechnern bekannt. Die Secondary-Server erkennen nach der Erhöhung der serial-Nummer, dass sie die Zone neu laden müssen. Das erfolgt normalerweise einmal je refresh-Intervall. Treten hierbei Fehler auf, wird der Zonentransfer alle retry Sekunden erneut versucht. Die Anfragen werden vom Secondary-Server aber weiterhin als authoritative beantwortet, bis die Zeit expire abgelaufen ist.
Das heißt, dass es – auch durch das normale DNS-Caching und die Möglichkeit, einen privaten Secondary-Server für fremde Zonen aufzusetzen – keine Möglichkeit gibt, eine Zonenänderung sofort überall wirksam werden zu lassen. Normalerweise wird man tunlichst versuchen, derartige Situationen zu vermeiden, indem man beispielsweise Dienste temporär auf dem alten und dem neuen Rechner parallel anbietet.
Sollte man eine derart plötzliche Umschaltung nicht vermeiden können, so sollte man vorher die Timing-Werte in der Zone schrittweise vermindern (dabei muss auch die serial-Nummer erhöht werden). Zum Umschaltzeitpunkt kann man dann mit einer schnellen Verteilung der Daten rechnen. Das bedeutet allerdings, dass in der Zwischenzeit eine deutlich höhere Netzwerklast nur durch DNS-Anfragen zu verzeichnen sein wird.
Ein weiterer Fall, bei dem Sie vorsichtig sein müssen, ist die Verminderung der serial-Nummer in einer Zone. Eigentlich ist das nämlich nicht möglich – und Sie sollten es auch zu vermeiden suchen. Wenn Sie es dennoch tun müssen und alle Secondary-Server unter Kontrolle haben, dann können Sie dort die kopierte Zone löschen und die Server neu starten. Im Internet haben Sie normalerweise diesen Zugriff auf die Secondary-Server nicht, so dass Sie hier das in den Quellen zum BIND beschriebene Verfahren (schrittweises und gezieltes Erhöhen der serial-Nummer bis zum Überlauf) anwenden müssen.
Dynamische DNS-Updates
Bisher haben wir DNS-Zonen als statisch betrachtet – das stimmt auch, solange nur der Administrator diese ändert. Bei der Verwendung von DHCP ist die Zuordnung von Namen zu IP-Adressen dynamisch möglich. Nun könnte man für alle möglichen IP-Adressen einen statischen Namen vergeben, aber das hat auch Nachteile. Ein Nachteil ist, dass zunächst alle Namen aufgelöst werden können und der Versuch die Rechner dann wirklich zu erreichen, in einen Timeout laufen kann.
Mit den Schlüsselwörtern allow-update oder update-policy im zone-Statement kann der Administrator das dynamische Update erlauben. Aus Performance-Gründen wird die Zonen-Datei nicht nach jedem Update neu geschrieben, sondern Änderungen werden zunächst in einem Journal protokolliert. Bei einem Neustart wird dann die bestehende Zone geladen und das Journal nachgefahren. In regelmäßigen Abständen wird allerdings die Zone als Datei gespeichert. Wenn Sie die Zone mit einem Editor ändern wollen, so müssen Sie den Nameserver mit rndc stop anhalten und das Journal löschen.
Sicherheit und DNS
DNS ist ein zentraler Dienst im Internet. Bisher hat man sich darauf verlassen, dass schon alles stimmen wird. Programme wie dnsspoof beweisen allerdings schon seit geraumer Zeit das Gegenteil. Noch werden die hier vorgestellten Methoden selten eingesetzt, was sich aber hoffentlich ändert.
Bisher kann sich ein Client nie sicher sein, ob die Antwort, die er erhalten hat (eventuell über einen Forwarder oder einen DNS-Cache) tatsächlich vom authoritativen Nameserver stammt oder nicht. Im Rahmen von DNSsec wurden Methoden entwickelt, dies mit kryptographischen Verfahren sicherzustellen.
Zunächst wird eine Zone wie bekannt erstellt, außerdem wird ein zu dieser Zone gehörendes Keypaar generiert. Die Zone wird mit dem Private Key unterschrieben, so dass Clients anhand des Public Key die Authentität überprüfen können. Ein analoges Verfahren wird bei PGP und GnuPG verwendet.
In folgendem Listing finden Sie die notwendigen Befehle, um ein Keypaar zu generieren. Die Keys müssen für das Signieren der Zone verfügbar sein, allerdings kann das auf einem Rechner erledigt werden, der nicht der DNS-Server ist.
(linux):~# dnssec-keygen -a rsamd5 -b 2048 -n zone jochen.org
Kjochen.org.+001+40716
(linux):~# ls –l
...
-rw-r--r-- 1 root jochen 378 29. Apr 21:02
Kjochen.org.+001+40716.key
-rw------- 1 root jochen 1697 29. Apr 21:02
Kjochen.org.+001+40716.private
...
(linux):~# cat Kjochen.org.+001+40716.key
jochen.org. IN KEY 256 3 1 AQP7qzWpGTD...
(linux):~# dnssec-makekeyset -a Kjochen.org.+001+40716
keyset-jochen.org.
(linux):~# ls –l
...
-rw------- 1 root jochen 925 29. Apr 21:05 keyset-jochen.org.
Der erstellte Public Key wird in die Zone aufgenommen:
Zone jochen.org
$INCLUDE Kjochen.org.+001+40716.key
Signieren der Zone
Mit dem erstellten Keypaar kann die Zone signiert werden, siehe folgendes Listing. Damit ist das Problem noch nicht gelöst, wie der Public Key zum Client kommt. In abgeschlossenen Umgebungen könnte man diesen manuell transportieren und authentisieren, im Internet wird man eine Public-Key-Infrastruktur aufbauen müssen. In dieser PKI wird der Parent der Zone diese signieren und damit diesen Key bestätigen.
(linux):~# dnssec-signzone -o jochen.org jochen.org
Kjochen.org.+001+40716
jochen.org.signed
Beim Signieren der Zone werden zusätzliche NXT- und SIG-Sätze eingefügt, die die Daten authentifizieren. Damit kann ein Client eine Antwort gegen den Public Key prüfen. In dem folgenden Listing finden Sie ein Beispiel für eine Signatur. In der Nameserver- Konfiguration verwenden Sie die Datei jochen.org.signed als Zonendefinition.
hermes.jochen.org. 86400 IN MX 10 mail.jochen.org.
86400 IN MX 80 mail.example.org.
86400 IN MX 90 mail2.example.org.
86400 SIG MX 1 3 86400
20020529193717 (
20020429193717 40716
jochen.org.
ksFvd1VtVBjxI+p0RxFWfs4iUCxp0pqhhchr
...
SvII+aNOpoo51gVy5A== )
Der Parent der DNS-Zone signiert das Keyset mit dem Befehl dnssec-signkey. Noch ist das unüblich, das könnte sich aber ändern, wenn die DNS-Registrare diesen Dienst anbieten oder sogar zur Pflicht machen.
Zu DNSsec gehört auch noch die Möglichkeit, Anfragen zu signieren (Transaction Signatures, TSIG). BIND9 bietet auch hierfür Unterstützung, primär für Transaktionen zwischen Servern, insbesondere Zonen-Transfers. Das Bind- Handbuch enthält hierfür ein Beispiel, das Sie als Startpunkt verwenden können. Da hier zwischen den Servern ein Shared-Secret verwendet wird, ist es einfach, einen Key zu erzeugen und zu verwenden.
Weitere Informationen zum DNS
Die wichtigsten Informationen zum Betrieb eines Nameservers finden Sie im „Administrators Reference Manual for BIND“, das in den Quellen zu BIND enthalten ist.
Empfehlenswert ist darüber hinaus das Buch „Managing DNS and BIND“ von Paul Albitz, Cricket Liu, O’Reilly and Associates – das Standardwerk zu BIND. (mje)