Zensur-Experimente der Telekom?

Posted by Jesco Freund at June 5, 2009 4:41 p.m.

Kein Anschluss unter dieser Nummer – so sieht die Fehlerseite der Telekom aus.

In den letzten Tagen erhielt ich beim surfen immer öfter besagte Fehlerseite von der Telekom – die Seite moniert einen angeblich nicht auflösbaren Hostnamen in der angesurften URI. Betroffen sind alle möglichen Seiten quer Beet, zeitweise konnte ich meine eigenen Seiten nicht erreichen, oder wie hier im Screenshot zu sehen, war der Zugriff auf code.google.com nicht möglich. Auch auf andere, allesamt durchweg harmlose Seiten wie etwa BSDForen.de war zeitweise kein Zugriff möglich.

Nun sind DNS-Probleme bei einem Provider zwar ärgerlich, aber ansich nichts furchtbar exotisches. Wenn es sich denn tatsächlich um ein DNS-Problem handeln würde. Interessanterweise funktioniert die Namensauflösung der monierten Hostnamen nämlich durchaus – nslookup oder dig liefern auf der Kommandozeile stets korrekte Auflösungen, wenn der Browser die Telekom-Fehlerseite zeigt. Auch wenn ich explizit meinen Router (fungiert als lokaler DNS Cache) verwende, bekomme ich die korrekte IP-Adresse zurückgeliefert.

So richtig wild wird es, wenn ich jetzt die Browser-Zugriffe mit wget simuliere (wohlgemerkt nachdem ich mit dig überprüft habe, dass keine fehlerhaften Namensauflösungen irgendwo im Cache hängen). Bei einem Zugriff auf die IP-Adresse liefert wget die erwartete Seite zurück. Lasse ich wget jedoch auf den Hostnamen los, speichert auch wget die Fehlerseite der Telekom. Gleiches lässt sich bestätigen, wenn man mit netcat auf einen gerade geblockten Hostnamen losgeht (und für die ganz kritischen Leser: auch die wget-Option --no-dns-cache ändert nichts an diesem Sachverhalt).

Für mich ist das jedenfalls sehr undurchsichtig, was dort bei der Telekom vor sich geht. Wenn es ein DNS-Problem wäre, dürfte ich auch per nslookup & Co keine vernünftige Auflösung erhalten. Genauso wenig scheint es sich aber auch um einen Filter auf dem Application Layer zu handeln – HTTP-Requests anhand des Host-Headers umzuleiten, ist mit einem transparenten Proxy keine große Kunst. Rein IP-basierte Netzdienste wie etwa ICMP Echo Requests zu verbiegen (auch die laufen zum Telekom-Host), scheint mir jedoch nochmals eine ganz andere Nummer zu sein. Das alles deutet eher auf ein Routing-Problem hin, wenn, ja wenn nicht der direkte Zugriff über die IP problemlos möglich wäre. Was um alles in der Welt passiert also gerade im Telekom-DSL-Netz? Eine wirklich schlüssige Erklärung habe ich bisher jedenfalls nicht gefunden…

1 comment | Defined tags for this entry: network, paranoia, privacy

Comments