Sicheres DNS mit Unbound
Dieser Artikel ist der erste in einer Serie, die sich mit dem freien DNS-Server Unbound beschäftigt. Den Anfang machen die Grundlagen und die erste Installation der Software.
Einführung
Das DNS ist kaputt. Das Protokoll wird weitgehend unverschlüsselt abgewickelt, und man muss davon ausgehen, dass es komplett aufgezeichnet und gespeichert wird. Der DNS-Server Unbound kann im eigenen Netz betrieben werden und den Datenschutz und die Sicherheit um einiges verbessern. Die vorliegende Artikelserie soll dabei helfen, Unbound zu verstehen und zu betreiben. In diesem Artikel, dem ersten der Serie, werden die Grundlagen vorgestellt. Alle Teile dieser Artikelserie können Sie über das Inhaltsverzeichnis finden.
Grundlagen von DNS
Die meisten unserer Interaktionen mit dem Internet geschehen anhand von Servernamen, die jeweils einer oder mehreren IP-Adressen entsprechen. Die Übersetzung dieser Namen in vier Byte lange IPv4-Adressen oder 16 Byte lange IPv6-Adressen geschieht durch das Domain Name System (DNS). Der Grund ist die leichtere Benutzbarkeit: pro-linux.de (oder www.pro-linux.de) ist leichter zu merken und zu tippen als 148.251.87.233 - zudem hätte die Adresse etwas früher noch 78.46.83.99 gelautet.
DNS ist ein dezentrales System, was grundsätzlich eine sehr gute Eigenschaft ist. Es gibt eine Unzahl von Servern, die man sich in einer Hierarchie angeordnet denken kann. Diese Server trifft man in verschiedenen Ausprägungen an. Ein Server kann nur für eine einzige Domain zuständig sein und auf alle Fragen nach anderen Domains mit »kenne ich nicht« antworten. Ein Server kann natürlich auch für mehrere Domains zuständig sein, die Spanne reicht bis zu Servern von Providern, die Millionen von Domains verwalten. Sofern der Provider es zulässt, kann aber im Prinzip jeder Domain-Besitzer einen für seine eigene Domain zuständigen Server betreiben. Auf der anderen Seite gibt es Server, die alle Domains auflösen können, weil sie dafür, wenn nötig, andere Server fragen. Solche Server nennt man rekursiv. Mischformen zwischen diesen beiden Typen sind natürlich auch möglich. Und dann gibt es noch die Root-Nameserver, die an der Spitze der Hierarchie stehen. Weltweit gibt es ungefähr 20 von diesen. Sie kennen nicht jede einzelne Domain, sondern vorwiegend nur die (zahlreicher werdenden) Toplevel-Domains, wissen aber, wer für sie jeweils zuständig ist.
Eine typische DNS-Auflösung läuft im Detail folgendermaßen ab: Der Rechner, der die IP-Adresse zu einem Namen wissen will (nennen wir ihn einmal Client), schaut zuerst in seiner lokalen Datenbank nach. Unter Linux und Unix ist das /etc/hosts. (Dies ist für DNS nicht wirklich relevant und wird hier nur der Vollständigkeit halber erwähnt, zudem lässt sich dieses Verhalten über /etc/nsswitch.conf abschalten.) Die Komponente, die die Namensauflösung auf dem Client vornimmt, heißt Resolver und kann in verschiedenen Implementationen vorliegen. Einer dieser Resolver ist Bestandteil der glibc und wird dadurch von zahlreichen Programmen verwendet.
Kommt der Resolver nun zu dem Schluss, dass er DNS einsetzen muss, wertet er zunächst die Datei /etc/resolv.conf aus, in der die IP-Adressen eines oder mehrerer DNS-Server stehen. Das ist eine der wenigen Stellen im System, an der nur IP-Adressen und keine Namen stehen können. Hier sollte es sich im Normalfall immer um rekursive Server handeln. Der Resolver fragt nun einen der Server nach einer Domain. Sollte er von diesem keine Antwort erhalten, fragt er den nächsten.
Wenn der kontaktierte Server für die Domain zuständig ist oder die Antwort bereits im Cache hat, liefert er die Antwort und die Prozedur ist beendet. Andernfalls hat er zwei Optionen. Er könnte die Anfrage an Server weiterleiten, die vielleicht mehr wissen. Da danach aber wieder dieselbe Situation vorliegt, müssen wir diesen Fall nicht weiter betrachten. Er erhöht lediglich die Aufruftiefe um 1. Im anderen Fall fragt der Server direkt einen der Root-Nameserver, der allerdings keine IP-Adresse direkt auflösen kann. Stattdessen liefert er die IP-Adressen der Nameserver, die für die Toplevel-Domain zuständig sind. Im Fall von www.pro-linux.de wären das die Adressen der zuständigen Nameserver für .de. Nun fragt unserer wackerer Server an einer dieser Adressen nach www.pro-linux.de, erhält aber wiederum nicht die gewünschte Antwort, sondern nur eine Liste der Nameserver der Domain. Jetzt kann der Server aber einen dieser Nameserver fragen und erhält schließlich die gewünschte IP-Adresse 148.251.87.233.
