Wenn Sie die Internetseite der cyscon GmbH besuchen wollen, morgens noch keinen Kaffee hatten und deshalb http://wwww.cyscon.de eintippen, zeigt Ihr Browser in der Regel eine Fehlermeldung. Die meisten fügen auch einen Link ein, über den Sie den eingetippten Text einer Internet-Suchmaschine übergeben können. Der Internet Explorer blendet auf Wunsch sogar ohne Nachfrage die Ergebnisseite der ausgewählten Suchmaschine ein. Und diese könnte Werbung zum Suchbegriff enthalten, an der Google, Yahoo oder Bing verdienen.
Diese Einnahmen wecken Begehrlichkeiten bei Providern wie T-Online und Alice, deren eigene Suchmaschinen und Portal-Seiten viel weniger Surf-Traffic abbekommen. Zu seinem Glück weiß Ihr Provider aber schon vor dem Browser, dass der Zugriff schiefgehen wird. Denn er betreibt den DNS-Server, bei dem in der Regel die Frage landet, welche IP-Adresse denn zum Namen wwww.cyson.de gehört.
Der DNS-Server schaut dann zunächst in seinem Cache nach und falls dort nichts steht, macht er sich auf die Suche: Zuerst fragt er bei einem DNS-Root-Server nach, wer für die Domain “de” zuständig ist. Dann fragt er dort nach dem Zuständigen für cyscon.de und den schließlich nach wwww.cyscon.de. Da es diesen Namen bei uns nicht gibt, lautet die Antwort “gibts nicht”, in DNS-Sprache “NXDomain”. Sollte diese Antwort Ihren Browser erreichen, reagiert der, indem er Sie über den Fehler informiert. Doch die findigen Provider lassen es nicht so weit kommen. Sie ersetzen die NXDomain-Meldung einfach durch die Adresse eines eigenen Servers, der eine Seite mit Suchergebnissen zum falschen Domain-Namen liefert.
Belogen
Was unbedarften Surfern helfen mag, die eigentlich gemeinte Seite zu finden, verwirrt viele Anwendungen, die auf die NXDomain-Fehlermeldung angewiesen sind. So versucht Linux beim Zugriff auf die Windows-Freigabe //server/ordner zuerst, den Namen “server” per DNS aufzulösen. Wenn eine Such-Domain wie blog.cyscon.de eingestellt ist, lautet der abgefragte Name server.blog.cyscon.de. Den gibts zwar nicht, doch der manipulierende DNS-Server liefert trotzdem eine Adresse zurück. Und Linux versucht nun, die Freigabe /ordner auf dem Werbe-Server des Providers anzusprechen. Würde die korrekte Fehlermeldung den Linux-PC erreichen, würde er die Namensauflösung im lokalen Netz per Broadcast probieren und den richtigen Server problemlos finden. Ähnliche Probleme entstehen überall, wo verschiedene Methoden der Namensauflösung zur Verfügung stehen und DNS zuerst probiert wird.
Doch auch anderswo ist NXDomain wichtig. Manche Spam-Filter prüfen, ob es den absendenden Server überhaupt gibt. Dieses Kriterium ist bei manipulierten DNS-Antworten unwirksam.
Bei abgehender Mail mit einem Tippfehler in der Domain verzögert sich die Fehlermeldung. Denn falls der Versender-Server keinen zuständigen Empfänger-Server (MX-Eintrag im DNS) findet, versucht er, den Domain-Namen als Server-Namen zu interpretieren. Bei korrekter NXDomain-Antwort würde er den Fehler sofort bemerken. Mit einer manipulierten DNS-Anwort versucht der Mail-Server jedoch mehrfach, die Mail beim Such-Server des Providers abzuliefern. Je nach Konfiguration gibt er erst nach Stunden oder Tagen auf. So lange erfährt der Absender eventuell nichts von seinem Versehen. Diese technischen Probleme sind seit Jahren bekannt. Schon 2003 diskutierte man das DNS-Wildcarding, bei dem ein zuständiger Server zu allen Namen in seiner Domain “On the fly”-Antworten erzeugt. Im selben Jahr stellte Verisign seinen “Sitefinder” auf Proteste hin ein. Der für die Top-Level-Domains .com und .net zuständige Registrar hatte DNS-Fragen nach nicht registrieren Domains auf seinen Server umgeleitet. Dort bot er die Domain zum Kauf an. Ähnliches tun manche Top-Level-Registrare weiterhin.
Beide DNS-Manipulationen werfen einige derselben Probleme auf wie die Verbiegung beim Provider. Und die Ablehnung der zuständigen Gremien ist seit Jahren einhellig: Das Internet Architecture Board (IAB) der Internet Engineering Task Force (IETF) stellt fest, dass DNS-Wildcarding die Architektur des Internet beeinträchtigt. Die Kritik der Internet Corporation for Assigned Names and Numbers (ICANN) führte zum Ende des Sitefinder-Experiments. 2008 warnte ein Report des “Security and Stability Advisory Committee” (SSAC) der ICANN vor den Problemen durch “Änderungen an DNS-Antworten”. Und der aktuelle Bericht der Arbeitsgruppe zur “DNS-Gesundheit” definiert als zwei wichtige Kriterien, dass die Antwort beim Abfragenden ankommt, die der Domain-Inhaber auf den Weg schickt, und dass zwei Server zur selben Zeit dieselbe Antwort liefern. 2009 brachte der amerikanische Provider Comcast einen RFC-Entwurf in die DNS-Arbeitsgruppe der IETF ein, der beschreibt, wie man als Provider DNS-Umleitungen am besten umsetzen sollte. Die Diskussion auf der Mailingliste der Arbeitsgruppe wandte sich schnell vom “wie” zum “ob” und die recht klare Meinung war: “Lieber nicht”.
Dürfen die das?
Die Internet-Gremien lehnen DNS-Verbiegungen zwar ab, doch dem Wortlaut der RFCs, die die Standards des Internet bilden, widerspricht die Praxis nicht. Denn die RFCs legen nur fest, wie der Server die Antworten übermittelt. Beim Lesen des RFC hat man den Eindruck, dass das ganz selbstverständlich dieselben sind, die der Server selbst bekommen hat. Doch im Text steht das nicht explizit. Im RFC 973 schrieb Paul Mockapetris zwar 1986 an die Betreiber von DNS-Servern: “Jedenfalls sollen Sie nicht über andere Teile des Namensraums lügen.” Doch 1987 goss er DNS in die derzeit gültige Fassung der RFCs 1034 und 1035 die dieses Lügenverbot nicht mehr enthalten. Pikanterweise ist derselbe Paul Mockapetris heute Vorstandsvorsitzender und Technik-Chef der Firma Nominum, die DNS-Server-Software an Provider liefert – inklusive dem Modul “Vantio NXR”, das für die DNS-Umleitungen zuständig ist.
Nominum nennt die DNS-Manipulation “Web Error Redirection”. Und im eigenen White Paper Zehn Schritte zur erfolgreichen Web Error Redirection heißt es: “Der erste und wichtigste Schritt ist, sicherzustellen, dass die NXDomain-Umleitung [...] ohne negative Auswirkungen auf Nicht-Web-Anwendungen implementiert wird.” Nominum verspricht zwar, mit Hilfe von Filtern nur die Anfragen umzuleiten, die auf Webseiten führen. Das ist allerdings prinzipiell unmöglich, da der DNS-Server nicht erkennen kann, zu welchem Zweck der Client den Namen auflösen möchte. Schließlich steht als einzige Information der abgefragte Name zur Verfügung. Die Programmierer und Admins beim Provider raten also aufgrund des Namens, was damit geschehen soll.
Gibts ja gar nicht
Alle DNS-Verbieger verletzen die Regeln für .de-Domain-Namen: Die zuständige DeNIC erlaubt nur einen eingeschränkten Satz von Umlauten und Sonderzeichen, um Phishing zu erschweren. So sind beispielsweise griechische Zeichen ausgeschlossen, die lateinischen ähneln. Doch die DNS-Umleitung kümmert sich nicht um solche Regeln. Munter behauptet sie, der Server sei erreichbar. Genauso wenig wie der Provider feststellen kann, ob die DNS-Anfrage von einem Browser kommt, kann der Client erkennen, ob die Antwort echt oder manipuliert ist. Die einzigen Hinweise sind die IP-Adresse des Provider-Servers in der Antwort und die Cache-Zeit (TTL, Time To Live) von 0. Doch beides kann auch bei einem korrekten Eintrag auftreten. Bei signierten Antworten gemäß DNSSEC kann der Client die Fälschung sofort erkennen. Doch bis DNSSEC flächendeckend eingeführt ist, gehen sicher noch viele Jahre ins Land. Da die verärgerten Kunden keinen technischen Ansatzpunkt finden, um DNS-Verbiegungen auszuhebeln, hoffen viele auf juristische Hilfe. Denn die Nutzung des falsch eingetippten Domain-Namens außerhalb der DNS-Antwort könnte eine Verletzung des Datenschutzes sein. Schließlich hat der User den Domain-Namen nur an den DNS-Server des Providers geschickt und nicht an dessen Such- und Werbeserver. Außerdem gibt dieser ihn an einen Dritten weiter, ohne dass der User dem zugestimmt hat, nämlich an den Betreiber der Suchmaschine. Die juristische Frage dabei ist, ob die Tippfehler-Domain ein personenbezogenes Datum ist, denn nur dann greift der Datenschutz.
Britische Datenschutzaktivisten haben sich beim Büro des Datenschutzbeauftragten (Information Commissioner’s Office, ICO) über die DNS-Umleitung des Providers Virgin Media beschwert. In der Antwort wird zwar eine Verletzung der EU-Datenschutztrichtlinie 95/46 bestätigt. Die Beeinträchtigung der User sei aber zu gering, um einzuschreiten. Da die Aktivisten dies bestreiten, läuft das Verfahren derzeit weiter. Einfacher lässt sich wahrscheinlich das Markenrecht anwenden: Wenn beispielsweise T-Online den Domain-Namen bestellung. alice-dsl.de auf seinen Server verbiegt, könnte das als unzulässige Nutzung des Marke Alice ausgelegt werden.
Doch selbst wenn sich diese juristische Ansicht durchsetzt, dauert das. Bis dahin bleibt den Kunden der DNS-Fälscher nur zweierlei zu tun: bei allen Netzwerkproblemen auch prüfen, ob das Provider-DNS schuld ist und dann die DNS-Verbiegung abschalten.
Viel vergnügen mit “Virales Marketing im Todesstern Stuttgart”:
