Nachschlagewerk

Inhaltsverzeichnis

Als vor 25 Jahren die RFCs 882 und 883 erschienen, waren längst nicht alle Aufgaben absehbar, die das DNS heute erledigt, etwa das Abfragen von IP-Adress-Blacklists über DNS zur Spam-Abwehr oder die Auflösung von Telefonnummern (ENUM). Nach wie vor ist jedoch die Namensauflösung seine wichtigste und unverzichtbare Aufgabe. Ein längerer Ausfall des DNS hätte sicherlich einen großflächigen Zusammenbruch von Diensten im Internet zur Folge, denn wer kennt schon die IP-Adressen diverser Webseiten oder anderer Dienste im Internet auswendig?

Bereits bevor DNS erfunden war, hatte es sich eingebürgert, anstelle der eindeutigen, aber für Menschen schwer erinnerbaren IP-Adressen Aliase, sogenannte Host-Namen zu verwenden. Die „Übersetzung“ eines Host-Namens in eine IP-Adresse fand lokal auf jedem Computer mithilfe der Datei hosts statt, einer einfachen Liste. Das Domain Name System entstand in erster Linie aus der Notwendigkeit, diese manuell gepflegten Tabellen zur Namensauflösung auf allen ans Internet angeschlossenen Computern durch ein verteiltes System abzulösen. Die Fehleranfälligkeit sowie die mangelnde Flexibilität der manuell gepflegten Dateien stieg mit der Zahl angeschlossener Computer.

Das DNS war daher von vornherein als verteiltes System konzipiert, dessen Datenbestand auf vielen verschiedenen zuständigen Servern lag. Der komplette DNS-Namensraum liegt also nicht an einer zentralen Stelle vor, sondern ergibt sich durch die Menge aller verteilten Domain-Datenbanken, die sogenannten Zonen. Auf dem für eine Domain verantwortlichen („autoritativen“) Nameserver wird daher in der Regel nur die entsprechende Zone angepasst. Ein weiterer Vorteil dieses Mechanismus ist die erhöhte Ausfallsicherheit mittels Datenverteilung.

Der DNS-Namensraum hat die mittlerweile in RFC 1034 definierte fest vorgegebene Struktur. Ein absoluter Name gliedert sich in „Labels“, die durch Punkte voneinander getrennt sind. Die Wurzel des DNS bildet die „nameless root“. Korrekterweise müsste jeder DNS-Name mit einem Punkt enden, doch nur sehr selten findet er sich am rechten Ende eines Domainnamens. In der Regel lässt man ihn einfach weg. Unterhalb der Wurzel befinden sich die „Top-Level-Domains“, kurz TLDs. Es gibt über 200 länderspezifische TLDs wie .de, .fr oder .at und die generischen TLDs wie .com, .org oder .net. Die Vergabe von Sub-Domains innerhalb einer TLD geschieht sehr unterschiedlich. Die Registry Denic ist verantwortlich für die TLD .de und verlangt vom Inhaber einer .de-Domain einen Wohnsitz in Deutschland.

Im Kontrast dazu vermarkten andere Nationen ihre TLD in der Hoffnung auf hohe Registrierungseinnahmen ohne derartige Restriktionen, etwa der Staat Tuvalu seine TLD .tv, die viele mit „Fernsehen“ assoziieren. Auch wenn kleine Inselstaaten im Internet sonst keinen allzu guten Ruf haben, nutzt manch eine Aktiengesellschaft die TLD .ag (von Antigua und Barbuda) für sich und mancher Radiosender .fm (für Mikronesien) in Anlehnung an das analoge Sendeverfahren der Frequenzmodulation. Unterhalb der Top-Level-Domains befinden sich Second-Level-Domains wie heise.de, darunter Third-Level-Domains wie www.heise.de und so weiter.

Die Welt der Domainnamen ist immer wieder für Anekdoten und Kuriositäten gut. So geriet im August 2004 die Domain ebay.de vorübergehend in die Hände eines Dritten, sodass die Auktionsplattform für einige Internetnutzer zeitweise scheinbar nicht erreichbar war – zumindest eben nicht über diesen Namen. Auf ähnliche Weise ereilte es google.de im Januar 2007.

Neben technischen und organisatorischen Pannen bieten Domains ein weitläufiges Spielfeld für juristische Auseinandersetzungen. Einer der aktuelleren Fälle ist der Streit zwischen dem Rohrunternehmen Universal Tube mit der Domain utube.com und dem Videoportal youtube.com um die Namensähnlichkeit. Den Rohrkonzern ärgerte das unerwünscht hohe Besuchsaufkommen durch Benutzer, die eigentlich das Videoportal aufsuchen wollten. Darüber hinaus gibt und gab es zahlreiche Auseinandersetzungen um Domains, die von mehreren Parteien gewünscht waren, so zwischen der Schokoladenmarke Milka und einer französischen Schneiderin Milka um die Domain milka.fr.

Des DNS-Rätsels Auflösung

Wie der Namensraum selbst ist auch der tatsächliche Prozess des Auflösens auf mehrere Systeme verteilt, denen dabei dreierlei Rollen zukommen – dem Anwender-PC in der Regel die des Clients. Der Rechner selbst führt keine DNS-Auflösung durch, sondern gibt die Aufgabe der Namensauflösung an einen „Resolver“ weiter. Der wiederum löst einen Namen im Zusammenspiel mit einem oder mehreren Nameservern auf. Wenn beispielsweise ein Browser eine Webseite vom Host www.internet-sicherheit.de abrufen möchte, formuliert zunächst der Client eine Anfrage zur Namensauflösung an den Resolver. Der erfragt die entsprechende Antwort entweder iterativ oder rekursiv bei weiteren Nameservern und leitet die Antwort – in diesem Fall die IP-Adresse 194.94.127.43 – an den Client zurück. Aufgrund der strikt hierarchischen Struktur des Namensraums ergibt sich häufig eine ähnliche Reihenfolge für die Abfrage.

Den Startpunkt bei der Namensauflösung bildet häufig einer der 13 Root-Nameserver mit den Bezeichnungen A bis M. Sie sind weltweit verteilt und häufig besteht eine Instanz wiederum aus mehreren verteilten Rechnern. Sie enthalten in nur etwa 2500 Einträgen lediglich Verweise auf die Nameserver der Top-Level-Domains. Von hier aus hangelt sich der Resolver im Auflöseprozess bis zum aufzulösenden Namen Label für Label entlang.

Wurzelbehandlung

Die IP-Adressen der Root-Nameserver sind in der Regel fest in die DNS-Software einkodiert. Aus Perspektive der Sicherheit kommt den Root-Nameservern eine wichtige Rolle zu. Wer sie kapert oder die Auflösung auf andere Weise manipulieren kann, hat als Angreifer die Möglichkeit, Opfer gezielt auf andere Systeme zu leiten. Tatsächlich gab es einen solchen Fall im November 2007: Die IP-Adresse des L-Root-Nameservers änderte sich – ein zwar seltenes, aber umso gefährlicheres Phänomen. Die bis dahin gültige IP-Adresse ging in einen neuen Verantwortungsbereich und damit auch auf einen neuen Computer über. Nach einiger Zeit beantwortete der neue Computer wieder die noch immer eingehenden DNS-Anfragen.

Viele DNS-Server-Betreiber hatten diesen Wechsel wohl gar nicht bemerkt und nutzten so monatelang einen falschen Root-Nameserver. Der neue Computer hätte mit Leichtigkeit manipulierte Antworten einspielen können, was aber anscheinend glücklicherweise nicht passiert ist.

Schnell, unverbindlich und angreifbar

Die Betreiber der Root-Nameserver sind sich der Bedrohung seit Langem bewusst und beobachten häufig gezielte Denial-of-Service-Angriffe, die einzelne Root-Nameserver manchmal unerreichbar machten, etwa im Februar 2007. Endanwender bemerken jedoch selten Auswirkungen solcher Angriffe. Die Root-Nameserver sind so ausgelegt, dass zwei Drittel von ihnen ausfallen können, ohne dass die Namensauflösung darunter leidet – zumindest theoretisch.

Nicht nur Root-Nameserver sind ein Ansatzpunkt für Angriffe durch DNS-Spoofing, sondern auch die Namensauflösung im LAN oder gar auf dem Client. Zum Teil modifiziert Malware – darunter einige ZLOB-Varianten – die Namensauflösung auf dem infizierten Client und lockt das Opfer auf diese Weise unbemerkt auf eine schädliche Webseite, zum Beispiel zu Phishing-Zwecken.

Das DNS-Protokoll baut in erster Linie auf dem User Datagram Protocol (UDP) auf, kommt also ohne zeit- und bandbreitenraubenden Verbindungsaufbau aus. Einerseits ermöglicht das die Implementierung von Resolvern in ressourcenarmen Umgebungen, die keinen vollständigen TCP-Stack erfordern, sondern lediglich IP und UDP. Andererseits bietet es weitere Angriffsflächen – in erster Linie wegen der Tatsache, dass auf eine kleine DNS-Anfrage mitunter große Antworten erfolgen („Amplification Attack“). Auf diese Weise können Angreifer den Datenverkehr im Rahmen eines Denial-of-Service-Angriffs um den Faktor 30 bis 50 verstärken. Fälscht man überdies die Absender-IP-Adresse, gelangen die großen Antwortpakete direkt zum Angriffsziel, ohne dass der tatsächliche Ursprung des Angriffs in Erscheinung tritt. Diese Technik kam bereits im Februar 2006 für einen Angriff auf Root-Nameserver zum Einsatz.

Weitere Angriffe auf DNS bestehen beispielsweise darin, gefälschte DNS-Antworten zu versenden, die den Cache eines DNS-Servers „vergiften“ (Cache Poisoning). Trotz der Vielfalt denkbarer Angriffe beweist das Domain Name System auf respektable Weise bis heute eine enorme Stabilität und skaliert trotz des enormen Internet-Wachstums reibungslos – vielleicht einer der Gründe dafür, dass sich Ansätze wie DNSSec, die die Sicherheit erhöhen sollen, noch nicht durchsetzen konnten. Bleibt an dieser Stelle nur eines zu sagen: Herzlichen Glückwunsch, DNS – und alles Gute für die Zukunft.

Christian J. Dietrich
ist Mitarbeiter des Instituts für Internet-Sicherheit an der FH Gelsenkirchen und für den Forschungsbereich E-Mail-Sicherheit verantwortlich. (un)