zurück zum Artikel

Einige der größten deutschen Internet-Provider manipulieren am Domain Name System herum, indem sie Fehlermeldungen fremder DNS-Server durch Verweise auf eigene Web-Server ersetzen. Das soll zusätzliche Anzeigenerlöse zeitigen, bringt aber einige Probleme mit sich - nicht nur technische.

Wenn Sie die Internetseite der c't besuchen wollen, morgens noch keinen Kaffee hatten und deshalb wwww.ct.de [1] 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 AOL (inzwischen 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.ct.de [2] 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 ct.de und den schließlich nach wwww.ct.de [3]. 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

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 ct.heise.de eingestellt ist, lautet der abgefragte Name server.ct.heise.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 [4], 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 [5]. Die Kritik der Internet Corporation for Assigned Names and Numbers (ICANN) führte zum Ende des Sitefinder-Experiments. 2008 warnte ein Report [6] des "Security and Stability Advisory Committee" (SSAC) der ICANN vor den Problemen durch "Änderungen an DNS-Antworten". Und der aktuelle Bericht [7] 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 [8] auf der Mailingliste der Arbeitsgruppe wandte sich schnell vom "wie" zum "ob" und die recht klare Meinung war: "Lieber nicht".

Dürfen die das?

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 [9] 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 [10] und 1035 [11] 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 [12] 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.

Das kann man bei Kabel Deutschland leicht nachvollziehen: Wenn ein Name nicht auflösbar ist, aber beispielsweise mit www, web oder http beginnt, liefert der DNS die Adresse des Kabel-Deutschland-Suchservers, also auch für www.gibts.nicht.heise.de [13] und wwww.ct.de [14]. Wahrscheinlich ist diese nicht öffentliche Liste der umzuleitenden Namensteile noch etwas länger. Alle anderen Namen führen zur korrekten Fehlermeldung. Ähnlich vorsichtig leiten Alice die Anfragen um. T-Online und Versatel gehen wesentlich aggressiver vor: Der DNS-Server hat offensichtlich nur eine Liste von Namensteilen, die er nicht verbiegt. So führt die Frage nach mail.nicht.heise.de [15] zur korrekten Fehlermeldung, während maul.nicht.heise.de [16] ebenso auf den T-Suchserver zeigt wie nicht.heise.de [17] und nackte, nicht vergebene Domain-Namen wie sdfgh.de [Update: Dieses Beispiel wurde mittlerweile als Domain registriert].

Gibts ja gar nicht

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, wie das große Epsilon in WWW.HΕISΕ.DE. Doch die DNS-Umleitung kümmert sich nicht um solche Regeln. Munter behauptet sie, der Server sei erreichbar. Vollends absurd wird es beim ß, das laut DeNIC-Regeln durch ss zu ersetzen ist. Alle aktuellen Browser halten sich daran und daher kann die Anfrage nach www.heiße.de [18] nicht von ihnen stammen. Trotzdem funktioniert bei den DNS-verbiegenden Providern der Befehl ping www.heiße.de. 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.

Antworten auf die häufigsten Fragen

Antworten auf die häufigsten Fragen

Seltsame Netzwerk-Fehler

Ich komme aus unserem Firmennetz nicht ins Internet. Mein Admin sagt mir, ich müsse einen Proxy benutzen, und der würde vollautomatisch konfiguriert. Das klappt aber offenbar nicht. Warum?

Auf meinem Notebook habe ich ein Skript, das per Ping-Befehl prüft, ob der Netzwerkdrucker unserer Firma verfügbar ist. Daheim führt das zu Fehlermeldungen, weil das Skript meint, der Drucker sei erreichbar, was aber gar nicht stimmt.

Alle diese Symptome können daher kommen, dass Ihr Provider in die Namensauflösung im Domain Name System eingreift und die Antworten verändert. Er liefert dann die Adresse eines seiner Server zurück, wenn die richtige Antwort eigentlich "den Namen gibts nicht" wäre. Die genannten Programme und Protokolle verlassen sich auf diese Fehlermeldung und funktionieren nicht korrekt, wenn sie stattdessen eine falsche IP-Adresse bekommen.

Abschalten

Kann ich die DNS-Verbiegung irgendwie abschalten?

Ja. T-Online [19], Alice [20] und Versatel [21] regeln das über ihre Online-Kundencenter im Browser. Entweder geben Sie einen vollkommen unsinnigen Domain-Namen in Ihren Browser ein, um die Suchergebnisseite aufzurufen. Damit die Umstellung wirksam wird, müssen Sie anschließend Ihren Router veranlassen, sich erneut ins Internet einzuwählen. Als Kabel-Deutschland-Kunde rufen Sie die kostenlose Nummer 0800/5 26 66 25 an. Dort lassen Sie sich mit einem Mitarbeiter verbinden, der Internet-Support leisten darf. Nach Aussage von Kabel Deutschland kann dieser die "DNS-Suchhilfe" für Ihren Anschluss deaktivieren. Bei unseren Stichproben waren jedoch nicht alle Mitarbeiter darüber informiert. Sie müssen also eventuell hartnäckig bleiben.

OpenDNS als Alternative

Kann ich nicht einfach OpenDNS benutzen?

Entgegen dem Anschein, den der Name erweckt, ist OpenDNS ein konfigurierbarer Internet-Filter, der zum Beispiel surfende Kinder schützen soll. Dazu beantwortet der Dienst DNS-Anfragen nach gesperrten Seiten mit der Adresse eines Servers, der eine Sperrmeldung liefert. Zur Grundfunktion gehört außerdem eine "Tippfehlerkorrektur", die der Ihres Providers ähnelt.

Eigener DNS-Server

Kann ich auch selbst einen DNS-Server betreiben? Umgehe ich damit Filter und gefälschte Antworten?

Ja, das würde funktionieren. Ihr DNS-Server würde dann die DNS-Hierarchie selbst abklappern. Das erzeugt allerdings zusätzlichen Netzwerkverkehr und Last auf den beteiligten Servern. Und es dauert etwas länger als die Frage bei einem DNS-Server, der die Antwort im Cache hat. Außerdem ist es nicht ganz einfach, so einen Server aufzusetzen und er erfordert einen ständig laufenden Rechner, der dauernd Strom verbraucht.

Frei verwendbare DNS-Server

Gibt es denn keine DNS-Server, die keine Antworten fälschen?

Doch. Sie müssen dafür allerdings einen vertrauenswürdigen Betreiber finden. Denn wenn jemand Ihre Zugriffe auf www.0815-Bank.de auf seinen Server umleiten kann, ist der Weg zu Ihren PINs und TANs nicht mehr weit. Eine sinnvolle Quelle ist die Liste frei verwendbarer DNS-Server [22] beim Chaos Computer Club. Allerdings gibt es noch eine Stolperfalle: Es kann sein, dass die DNS-Server der Provider unterschiedliche Adressen zurück liefern, je nachdem, von wo die Anfrage kommt. So hatte früher www.kabeldeutschland.de für Zugriffe aus dem eigenen Netz eine andere Adresse als für Zugriffe aus dem Internet.

Wenn Sie einen der frei verwendbaren Server nutzen, fragt der immer über das Internet beim DNS Ihres Providers an. Obwohl Sie also innerhalb des Netzes sind, benutzen Sie dann immer die externen Zugänge.

Anderen DNS-Server nutzen

Okay, das Risiko gehe ich ein. Wie bekomme ich meine Rechner dazu, den externen DNS-Server zu benutzen?

Das hängt von Ihrem Router ab. Der enthält selbst einen DNS-Server, der nichts anderes tut, als die Anfragen an den Server weiterzuleiten, den der Provider bei der Einwahl mitteilt. Das Eleganteste wäre es, dem Router einen anderen Partner-Server beizubringen. Uns ist allerdings kein Router bekannt, bei dem man für einen DSL-Zugang nur die DNS-Server-Adresse umstellen kann.

Dass er selbst der DNS-Server fürs lokale Netz ist, teilt der Router den PCs per DHCP mit. Bei den meisten Router-Modellen kann man in der DHCP-Konfiguration eintragen, dass er den PCs stattdessen die Adresse des externen freien DNS-Servers zuweisen soll. Dann fragen die Clients direkt den externen Server.

Beschnittener DHCP-Server

Bei meinem Router (einer Fritzbox) kann ich in den DHCP-Einstellungen keinen DNS-Server eintragen. Bin ich jetzt verloren?

Nein. In modernen PC-Betriebssystemen kann man den DNS-Server unabhängig von den anderen Netzwerk-Parametern einstellen.

Unter Windows öffnen Sie die Eigenschaften Ihrer LAN- oder WLAN-Verbindung und doppelklicken auf dem Reiter "Netzwerk" das "Internetprotokoll Version 4". Im nächsten Dialog lassen Sie oben den Knopf bei "IP-Adresse automatisch beziehen" stehen und klicken unten auf "Folgende DNS-Serveradressen verwenden". Dann können Sie zwei verschiedene Server eintragen. Unter Mac OS klicken Sie in den Netzwerkeinstellungen auf "Weitere Optionen". Im nächsten Dialog gibt es eine eigene Seite für die DNS-Server. Die per DHCP bezogenen Adressen stehen hier grau und verschwinden, sobald Sie über den Plus-Knopf unten eigene Server-Adressen hinzufügen. (Johannes Endres)/ (rek [23])

URL dieses Artikels:
https://www.heise.de/-1025662

Links in diesem Artikel:
[1] http://wwww.ct.de
[2] http://wwww.ct.de
[3] http://wwww.ct.de
[4] http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
[5] http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
[6] http://www.icann.org/committees/security/sac032.pdf
[7] http://www.icann.org/en/security/dns-ssr-symposium-report-1-3feb10-en.pdf
[8] http://thread.gmane.org/gmane.ietf.dnsop/4804
[9] http://www.heise.de/netze/rfc/rfcs/rfc973.shtml
[10] http://www.heise.de/netze/rfc/rfcs/rfc1034.shtml
[11] http://www.heise.de/netze/rfc/rfcs/rfc1035.shtml
[12] http://www.nominum.com/info_center/registration_thanks.php?iid=1772
[13] http://www.gibts.nicht.heise.de
[14] http://wwww.ct.de
[15] http://mail.nicht.heise.de:mail.nicht.heise.de
[16] http://maul.nicht.heise.de
[17] http://nicht.heise.de
[18] http://www.heiße.de
[19] https://kundencenter.telekom.de/kundencenter/kundendaten/navigationshilfe/
[20] https://www.alice-dsl.de/kundencenter/StartErrorpageOptOut.do
[21] http://www.versatel.de/scripts/goto?suchergebnis
[22] http://www.ccc.de/censorship/dns-howto/
[23] mailto:rek@ct.de

Copyright © 2010 Heise Medien