Karstens Blog

Stolperfallen im Domain Name System

Author: Karsten | April 29, 2011 | 6 Minute Read

Jeder fleißige Internetznutzer benutzt es mehrmals täglich, meistens aber unbewusst: Das Domain Name System, kurz: DNS. Die oft als «Gelbe Seiten des Internet» bezeichnete Datenbank ist eine gigantische verteilte Informationsbibliothek, die auch dem erfahrenen Surfer manchmal noch magisch vorkommt. Die Schwierigkeiten, die sich beim Betrieb einer eigenen Internetplattform, sei es Web- oder Mailserver ergeben und wie man sie umschiffen kann, wird in diesem Artikel behandelt.

Es begann mit einer Datei

Als das Internet noch aus einer Sammlung einiger Dutzend Computer bestand, konnte die Übersetzung der Rechnernamen (z.B. www.example.net) zu den eigentlichen IP-Adressen (z.B. 123.45.67.8) noch in einer Datei gehalten werden, die einfach «hosts» hieß und von Zeit zu Zeit über die einzelnen Rechner kopiert wurde. Sehr schnell wurde aber schon damals (als «Surfen» noch einen Wassersport bezeichnete) klar, dass bei dem drastischen Wachstum des Netzes ein leistungsfähigeres System benötigt würde.

Das neu geschaffene Domain Name System erfüllte bereits die Anforderungen, die man an ein verteiltes Datenbanksystem haben kann. Heute besteht sie aus tausenden Rechnern, die weltweit verteilt sind, damit das System vor Ausfällen gut geschützt ist. Das DNS speichert längst nicht mehr nur Netzwerkadressen sondern kann alle möglichen Informationen aufnehmen. So spielt DNS beim Versand von E-Mails eine große Rolle. Hierbei werden die Mail-Datensätze, so genannte MX-Records abgefragt, die den zuständigen Mailserver einer Domain liefern.

Bedingt durch die hierarchische Struktur des DNS können Domains in Unterdomains unterteilt werden oder sogar je nach geografischer Lage unterschiedliche Antworten liefern, wie das bei großen Websites der Fall ist, die die Netzwerkauslastung auf ihre weltweit verteilten Rechenzentren aufteilen wollen.

Back to the Roots!

Der «Anfasspunkt» für jede Abfrage ist einer der so genannten Root-Server, man kehrt gewissermaßen auf die Wurzeln des Internet zurück. Die Root-Zone besteht aus 13 Rechnern, die ihrerseits auf weitere zuständige Name Server verweisen. Anfragen für eine Internetadresse, also z.B. www.example.net werden rekursiv von mehreren zuständigen Servern beantwortet. Das bedeutet, dass zunächst der letzte Teil der durch Punkte getrennten Adresse, in diesem Fall «.net» angefragt wird. Der Root-Server wird nun wissen, welche Vergabestelle für die Top Level Domain «.net» zuständig ist und wird den Anfragesteller an dessen Name Server verweisen. Für den Rootserver ist die Aufgabe damit beendet und er kann sich einer der Millionen weiteren Anfragen, die pro Stunde auf ihn einprasseln, zuwenden.

{.alignright .size-thumbnail .wp-image-325 width=”150” height=”150”}

Der Fragesteller, also der zum Surfen benutzte Computer, kann sich nun an den genannten Server wenden. Dieser wird ihn aber auch lediglich die Adresse zweier (oder mehr) Nameserver desjenigen Providers nennen, bei dem die Domain «example.net» gehostet wird. Einer derer allerdings kennt dann in der Regel tatsächlich die IP-Adresse des Rechners «www.example.net». In diesem Fall ist es ein Server der Organisation IANA, die u.a für die Verwaltung der Root-Zonen zuständig ist.

Wer ist hier zuständig?

Der in der oben genannten Kette «letzte» Server wird auch als autoritativer Server bezeichnet; wir nennen ihn im Folgenden einfach den zuständigen Nameserver. Für ihn gelten einige Besonderheiten, von denen weiter unten noch zu sprechen sein wird.

Damit nun nicht jede Anfrage im Internet den gesamten rekursiven Vorgang wiederholen muss, gibt es eine Reihe von Zwischenspeichern, die so genannten Resolver, die das Endergebnis speichern und bei wiederholten Anfragen schnell ausliefern können. Außerdem sind sie in der Lage, die rekursiven Anfragen selbständig, sozusagen im Auftrag zu erledigen.

Internetprovider betreiben meist für ihre angeschlossenen DSL-Kunden mehrere solcher Resolver, um die ausgehenden Anfragen gering zu halten. Das ist nicht immer unproblematisch, da damit auch gewisse Einflussmöglichkeiten verbunden sind. So hat die Zeitschrift c't mehrfach darauf hingewiesen, dass Anfragen an den Resolver des Providers, die z.B. wegen falsch geschriebener Adressen nicht beantwortet werden konnten, mit einer anderen Adresse beantwortet werden, die zum Portal des Providers oder eines Werbepartners führt.

{.alignright .size-thumbnail .wp-image-326 width=”150” height=”150”}

Dies kommt einer Manipulation gleich, die auch bei den viel diskutierten Netzsperren zur Anwendung kommen sollte. Fatal wird ein solches Verhalten beim Versenden von E-Mails, da die Mail in dem Fall von einem anderen Server abgefangen werden kann. Um solche Manipulationen zu vermeiden, kann man auf einen alternativen Resolver ausweichen. Google bietet z.B. einen offenen Resolver mit der einprägsamen IP-Adresse 8.8.8.8 an, auf dem man ausweichen kann.

Letztlich braucht es immer ein gewisses Maß an Vertrauen, wenn man nicht einen eigenen Resolver verwenden kann. Die Installation eines eigenen Resolvers ist übrigens immer dann angeraten, wenn man einen eigenen Internetservice anbietet, da viele Server-Applikationen selber DNS-Anfragen versenden. Dieser ausgehende Netzwerkverkehr kann dann unter Umständen den eigentlichen Dienst ausbremsen.

Vetrauensstellung

Eine empfehlenswerte Maßnahme, vor allem für Internetprovider und -dienstanbieter ist die Trennung von autoritativen Nameservern und Resolvern: Bietet nämlich ein Provider für die Domains seiner Kunden den zuständigen DNS an (was in der Regel der Fall ist), können durch manipulierte Einträge unter Umständen Domains «entführt» werden, wenn der anfragende Computer den selben Server als Resolver verwendet. So erhält er nämlich eine Antwort für eine Domain, für die er gar nicht zuständig ist! Würde man nämlich den oben genannten (langen) rekursiven Weg gehen, erhielte man die richtige Antwort, da die Anfrage dann garantiert über den wirklich zuständigen Server gehen würde. Das lässt sich relativ leicht einrichten, indem man auf dem autoritativen Server rekursive Abfragen abschaltet^[1]^.

Das DNS wurde auf der Basis von Offenheit und Vetrauen entworfen und genügt nicht mehr den heutigen Sicherheitsanforderungen. Wegen der oben genannten möglichen Probleme wurde bereits vor Jahren der Standard «Secure DNS», kurz DNSSec, entworfen, der nach langer Entwurfszeit heute produktiv ist^[2]^.

Im wesentlichen beruht dieser Service auf fälschungssicheren DNS-Einträgen. Gewährleistet wird das durch eine kryptografische Signatur für jeden einzelnen Namenseintrag und die Signierung durch die jeweils übergeordnete Instanz. Dadurch wird eine Kette des Vertrauens gebildet, vorausgesetzt natürlich, man vertraut in letzter Instanz den US-Amerikanischen Behörden, die de facto die Aufsicht über Internetorganisationen wie ICANN haben.

Der Anwender bekommt von dieser Absicherung nichts mit. Wird tatsächlich eine Antwort eines Servers gefälscht, liefert der letztlich antwortende Resolver lediglich ein «nichts gefunden».

Ausblick

Das heutige System ist nicht perfekt, funktioniert aber stabil und ist einigermaßen robust. Die Netzanbieter tun ihr übriges, um ihre Nameserver vor Ausfällen oder gar Attacken aus dem Netz zu schützen. Mit der Einführung von DNSSec wird vor allem bei sensiblen Diensten wie Online-Banking mehr Sicherheit geboten werden. Allerdings kommt auf die Betreiber auch eine höhere Rechenlast zu, da die Signaturen aufwändig berechnet und überprüft werden müssen. Mit der allmählichen Einführung des neuen Internetprotokolls IPv6 kommen weitere Herausforderungen hinzu, da sich die Anzahl der Adressen potenzieren wird. Diese können heute kaum abgeschätzt werden.

[]{#literatur}Literatur

[1] «DNS for Rocket Scientists», Freies Buch zur Konfiguration von Bind 9

[2] Einführung in Secure DNS