Schon seit Juli blockiert Vodafone in Teilen seines UMTS-Netzes den Traffic zu DNS-Servern. Andere Provider werden vermutlich bald folgen. ZDNet zeigt, wie man die Sperre umgeht und freie Server nutzt.
Das Internetzensurgesetz[1] ist noch nicht in Kraft getreten. Derzeit liegt es bei der EU im sogenannten Notifizierungsverfahren[2], das anderen EU-Ländern eine Einspruchsmöglichkeit einräumt. Die Einspruchsfrist endet am 8. Oktober. Danach wird es Bundespräsident Horst Köhler zur Unterschrift vorgelegt. Seine Zustimmung gilt trotz zahlreicher Proteste und verfassungsrechtlicher Bedenken als sicher.
Die Internetprovider unternehmen indes bereits Anstrengungen, die Verwendung von freien DNS-Servern zu unterbinden. Die German Privacy Foundation[3] hat herausgefunden[4], dass Vodafone bereits allen Traffic auf den UDP-Ports Port 53 sperrt. Das gilt zunächst nur für Teile des UMTS-Netzes. Es ist davon auszugehen, dass andere Provider diesem "Test" folgen werden.
Betroffen sind alle Anwender, die einen Internetzugang über den APN[5] event.vodafone.de nutzen. Über diesen APN erhalten Vodafone-Kunden einen eingeschränkten Internet-Zugang mit einer privaten IP-Adresse und NAT-Routing aus dem Bereich 10.0.0.0/8. UDP-Traffic auf Port 53, der nicht zu den Vodafone-DNS-Servern führt, ist bei diesem Zugang gesperrt. Einen technischen Grund dafür gibt es nicht. Andere Provider, die einen NAT-Zugang anbieten, kommen ohne Sperren aus.
Nicht betroffen sind hingegen die Vodafone-Kunden, die den APN web.vodafone.de nutzen. Dieser Zugang steht nur Kunden mit Laufzeitvertrag zur Verfügung. Sie erhalten einen vollwertigen, aber meist kostenintensiveren Internetzugang mit öffentlicher IP-Adresse. ZDNet hat dabei keine Behinderung beim Zugang zu DNS-Servern festgestellt.
Ein Eingriff in das Fernmeldegeheimnis, wie ihn Vodafone für manche UMTS-Kunden vornimmt, ist durch kein Gesetz gedeckt. Über DNS auf den TCP- und UDP-Ports 53 werden heutzutage weit mehr Dienste abgewickelt als die bloße Namensauflösung, beispielsweise der Zonentransfer von Blacklisten zur Spambekämpfung oder privaten Intranet-Domains. Eine zensierte DNS-Antwort mit gefälschtem Absender seitens des Providers unterbindet eine ganze Reihe legitimer DNS-Nutzungen, die mit der Bekämpfung von Kinderpornografie nichts zu tun haben.
Zudem kann man nicht oft genug wiederholen, dass die Nutzung der staatlich zensierten DNS-Server für Internetnutzer gefährlich sein kann. Wer etwa durch Anklicken eines Links in einer Spam-Mail versehentlich auf eine Stopp-Seite geleitet wird, muss befürchten, zumindest auf der "Beobachtungsliste" der Provider und der Behörden zu landen. Die Logfiles dürfen zwar nicht zur Strafverfolgung verwendet werden, eine generelle Auswertung verbietet das Internetzensurgesetz jedoch nicht.
Einer solchen Beobachtung sollte man sich proaktiv entziehen, indem man die DNS-Server der Zensurprovider erst gar nicht nutzt. Wenn die Provider damit beginnen, den Zugang zu freien DNS-Servern zu sperren, muss man weitere Maßnahmen treffen.
Eine Möglichkeit ist der Betrieb eines sogenannten Caching-DNS-Servers nur für den eigenen Computer oder für das eigene Heimnetzwerk. So ist man nicht nur völlig autark, sondern kann auch eine Portsperre oder IP-Verkehrsfälschung auf bestimmten Ports umgehen. Diese Maßnahme ist notwendig, da sich in den heutigen Betriebssystemen kein alternativer Port für DNS-Server einstellen lässt.
Nutzer von Unix-Betriebssystemen wie Linux oder Mac OS können dazu bind[6] verwenden, das mit den meisten Distributionen ausgeliefert wird. Windows-Anwender können mit Bordmitteln keinen eigenen DNS-Server betreiben, sofern sie nicht eine der Server-Varianten einsetzen. Die Windows-Workstation-Betriebssysteme besitzen nur einen DNS-Client. Zudem mangelt es dem Windows-DNS-Server an vielen Ecken und Enden, nicht nur an der Möglichkeit, einen anderen Port als 53 zu nutzen. Jedoch gibt es bind auch als Windows-Version.
Bildergalerie
Providerblockade mit eigenem DNS-Server umgehen[7]
» zur Bildergalerie ...[7]
bind gilt als umständlich und kompliziert. Dies ist jedoch bestenfalls richtig, wenn man DNS-Dienste für eigene Domains aufsetzen möchte. Wer bind lediglich als Alternative zum zensierten Provider-Server nutzen möchte, kann das mit wenigen Konfigurationsschritten erledigen. Der Aufwand besteht im Wesentlichen darin, vier fertige Konfigurationsdateien in die richtigen Verzeichnisse zu kopieren. Wer sich exakt an die nachfolgende Anleitung hält, kann praktisch nichts falsch machen.
Obwohl bind sich auch als DNS-Server für sehr große Domaindatenbanken eignet, ist er als Caching-DNS-Server recht schlank. Der Hauptspeicherbedarf lässt sich im Config-File begrenzen, so dass bind auf einem Windows-Rechner gute Dienste leistet und dabei weniger Ressourcen benötigt als zweifelhafte Updater oder Quickstarter, die häufig von Firmen wie Google oder Adobe ungefragt in die Autostartliste von Windows eingetragen werden.
Um bind unter Windows zu installieren, lädt man sich die aktuelle Version vom Internet Systems Consortium[8] (ISC) herunter. Das ZIP-File packt man in ein beliebiges Verzeichnis aus und ruft die Datei BINDInstall.exe auf. Dazu sind Administratorrechte erforderlich. Unter Vista und Windows 7 muss das Programm bei aktivierter Benutzerkontensteuerung mit der Option "Als Administrator ausführen" gestartet werden. Danach erscheint ein Dialog wie in Bild 1[9] gezeigt.
Als "Target Directory" schlägt das Installationsprogramm C:\Windows\System32\dns vor. Von dieser Voreinstellung rät ZDNet dringend ab: C:\Windows und seine Unterverzeichnisse sollten dem Betriebssystem selbst vorbehalten bleiben. Stattdessen wählt man zweckmäßigerweise C:\bind. Alle folgenden Beispielkonfigurationsdateien gehen von einer Installation in diesem Verzeichnis aus.
Der "Service Account Name" named sollte nur geändert werden, wenn schon ein Benutzer mit demselben Namen existiert. Als "Service Account Password" kann man ein beliebiges sicheres Kennwort verwenden. Es muss nie wieder eingegeben werden. Unter "Options" sollten alle Kontrollkästchen unverändert gelassen werden.
Nach dem Klick auf "Install" installiert sich bind automatisch. Das Programm legt den Service Account an und installiert den Dienst ISC BIND (Kurzname named). Ein paar Dinge müssen jedoch von Hand erledigt werden: Dazu ist es nötig, die Kommandozeile zu benutzen, die ebenfalls mit Administratorrechten ausgestattet sein muss. Dort gibt man nacheinander die folgenden Befehle ein:
c:
cd \bind\bin
rndc-confgen -a
mkdir c:\bind\zone
mkdir c:\bind\log
cacls c:\bind /T /E /C /G named:F
Damit legt man einige notwendige Verzeichnisse an, generiert den MD5-Key für das Steuerprogramm rndc und erteilt dem Service Account Vollzugriff auf den Verzeichnisbaum C:\bind.
Im Verzeichnis c:\bind\zone müssen drei Dateien angelegt werden: localhost.zone, localhost.rev und db.cache. Die Datei localhost.zone hat folgenden Inhalt:
Die Datei localhost.rev sieht wie folgt aus:
Diese beiden Dateien sorgen dafür, dass der Name localhost immer zur IP-Adresse 127.0.0.1 aufgelöst wird und umgekehrt. Sie ändern sich nie und können unverändert gelassen werden. Als letzte Datei wird die Datei db.cache benötigt. Sie ändert sich selten, meist weniger als einmal pro Jahr. Die aktuelle Version kann man von ftp.internic.net[10] herunterladen. Sie enthält die DNS-Root-Server und ihre IP-Adressen. Diese Information muss jeder unabhängige DNS-Server besitzen.
Die wichtigste Datei ist die Datei named.conf. Sie enthält die Master-Konfiguration von bind und gehört ins Verzeichnis C:\bind\etc. Solange man über einen Provider ins Internet angebunden ist, der TCP- und UDP-Port 53 unangetastet lässt, kann man folgende Konfiguration für named.conf verwenden:
Die wichtigsten Informationen stehen in der Sektion options. Mit allow-query { localhost; }; legt man fest, dass nur der eigene Rechner Anfragen an den Caching-DNS-Server senden darf. Grundsätzlich kann man auch anderen Rechnern die Benutzung erlauben. Sinnvoll ist das nur, wenn man in seinem Heimnetzwerk eine feste IP-Adresse hat und der Rechner ständig eingeschaltet ist, wie das etwa bei einem Home-Server der Fall ist. Dann ersetzt man localhost; durch any; oder durch localhost; 192.168.0.0/16; 10.0.0.0/8;.
Vorsicht ist bei mobilen Geräten wie Netbooks geboten: Auch die Angabe eines privaten Adressraums schützt in öffentlichen Netzen wie WLAN-Hotspots nicht, da man dort meist ebenfalls eine Adresse aus dem Bereich 192.168.x.0/24 oder 10.0.0.0/8 bekommt. Man sollte den DNS-Server auf solchen Geräten nur lokal betreiben.
Pflichtangabe ist ein Versionsstring wie version "Anti-Zensursula-Server";. Ansonsten können andere Rechner die echte Version erfragen und versionsspezifische Sicherheitslücken ausnutzen. Die Zeile max-cache-size 16M; begrenzt die Cache-Größe auf 16 MByte. Das stellt sicher, dass sich bind nicht zu viel Hauptspeicher genehmigt.
Bevor man seinen eigenen DNS-Server als Dienst startet, ist es sinnvoll, auf der Kommandozeile im Verzeichnis C:\bind\bin einen Testlauf mit dem Befehl named -g durchzuführen, siehe Bild 2[11]. Wenn das funktioniert, kann man bind mit der Tastenkombination Strg-C wieder beenden.
Hat man einen Fehler gemacht, so sieht man anhand der Bildschirmausgabe, woran das liegt. Im Beispiel von Bild 3[12] wurde in der Datei named.conf in Zeile 9 statt rndc.key die Datei rdc.key eingebunden. In diesem Fall bricht bind ab. Wenn die Konfiguration korrekt ist, kann man den Dienst "ISC BIND" mit dem Befehl net start "ISC BIND" oder net start named starten. Alternativ lässt sich der Dienst über die Taskleiste mit Start - Systemsteuerung - Verwaltung - Dienste hochfahren.
Sobald der Dienst gestartet ist, sollte man testen, ob er tatsächlich funktioniert. Das geht am einfachsten mit dem Befehl host auf der Kommandozeile im Verzeichnis C:\bind\bin. Der Befehl host -a example.com 127.0.0.1 sollte eine Ausgabe wie in Bild 4[13] erzeugen. Wenn das der Fall ist, kann man in der IP-Konfiguration für seine Netzwerkinterfaces als einzigen DNS-Server 127.0.0.1 angeben, siehe Bild 5[14]. Eine ausführliche Anleitung, wie man DNS-Server einträgt findet sich im ZDNet-Artikel Internetzensur: Freie DNS-Server schützen vor falschem Verdacht[15].
Wenn der eigene Provider an den TCP- und UDP-Ports 53 herumspielt, so dass alle DNS-Server mit Ausnahme der eigenen Zensurserver gesperrt sind, oder der Verkehr so umgeleitet wird, dass DNS-Abfragen abgefangen und von Zensurservern beantwortet werden, muss man die Datei named.conf nur geringfügig anpassen, so dass man freie DNS-Server als Forwarder erreichen kann.
In der Sektion options fügt man zunächst die Zeile forward only; ein. Das stellt sicher, dass nur über freie DNS-Server aufgelöst wird. Als zweites fügt man eine Zeile wie forwarders { 85.214.117.11 port 110; 209.59.210.167 port 110; }; ein. Das führt dazu, dass der lokale Caching-DNS-Server die freien Server 85.214.117.11 und 209.59.210.167 über die TCP- und UDP-Ports 110 zur Namensauflösung nutzt. Nach einem Neustart des Dienstes sind eine Sperre oder eine Fälschung von Port 53 des Providers umgangen.
Die gesamte Datei named.conf im Verzeichnis C:\bind\etc sieht beispielsweise wie folgt aus:
Eine Liste mit freien DNS-Servern, die neben Port 53 weitere Ports (meist 110) anbieten, findet sich ebenfalls im Artikel Internetzensur: Freie DNS-Server schützen vor falschem Verdacht[15]. Generell sollte man bei der Anzahl der Forwarder nicht sparsam sein. Die Betreiber der freien DNS-Server können keine Hochverfügbarkeit garantieren. Daher ist es sinnvoll, immer ein paar "Reserveserver" in der Konfiguration zu haben.
Unter Mac OS X ist bind bereits mit dem Betriebssystem installiert. Es muss nur noch konfiguriert werden. Auch unter Mac OS kommt man dabei nicht um die Kommandozeile herum. Dazu wird ein Terminal aufgemacht. Danach gibt man folgende Befehle ein:
sudo -s
rndc-confgen -a
Anschließend wird die Datei /System/Library/LaunchDaemons/org.isc.named.plist editiert, beispielsweise mit nano oder vi. Unter dem Eintrag <key>Disabled</key> befindet sich der Eintrag <true/>. Diesen ändert man auf <false/>. Anschließend speichert man die Datei und beendet den Editor.
Wenn der Provider TCP- und UDP-Port 53 manipuliert, editiert man die Datei /etc/named.conf. In der Sektion options fügt man wie unter Windows die Zeile forward only; hinzu und anschließend eine Zeile wie forwarders { 85.214.117.11 port 110; 209.59.210.167 port 110; 87.118.100.175 port 110; 62.141.58.13 port 110; };. Auch unter Mac OS sollte man einen Versionsstring wie version "Anti-Zensursula-Server"; einfügen und die Cachegröße durch die Zeile max-cache-size 16M; begrenzen.
Danach lässt sich bind mit dem Befehl /usr/sbin/named -g testen. Wie unter Windows bricht man mit der Tastenkombination Strg-C ab, wenn die Konfiguration erfolgreich war.
Danach wird der Befehl launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist eingegeben, damit bind bei jedem Hochfahren des Rechners automatisch startet. Anschließend lässt sich bind mit dem Befehl launchctl start org.isc.named sofort aktivieren. Das erspart einen Neustart des Rechners. In den Systemeinstellungen trägt man unter Netzwerk als DNS-Server 127.0.0.1 ein, siehe Bild 6[16]. Nun sollte die DNS-Auflösung mit dem eigenen bind funktionieren.
Aktivierung und Konfiguration unter Linux und anderen Unix-Varianten
In vielen Linux-Distributionen ist bind nicht standardmäßig installiert. In diesem Fall kann der Paketmanager genutzt werden, um bind auf den Rechner zu bringen. Wie unter Mac OS erhält man eine Standard-Konfiguration als Caching-DNS-Server. Unter Debian und Ubuntu kann man dafür den Befehl sudo aptitude install bind9 nutzen. Bei Suse-Linux ruft man dazu mit sudo yast das Kontrollzentrum auf und wählt Software - Software Management.
Die Hauptkonfigurationsdatei heißt bei fast allen Distributionen /etc/named.conf. Prominente Ausnahmen sind Debian und Ubuntu. Die Datei heißt bei diesen Distributionen /etc/bind/named.conf. Wenn alternative Ports nötig sind, editiert man die Konfigurationsdatei wie bei Mac OS und trägt die freien Server als Forwarder ein.
Um bind automatisch beim Hochfahren des Rechners zu starten, nutzt man einen Runlevel-Editor der jeweiligen Distribution. bind sollte in den Runleveln 2, 3 und 5 aktiviert werden.
Damit der Rechner den eigenen DNS-Server auch nutzt, ist bei allen Unix-Varianten grundsätzlich die Zeile nameserver 127.0.0.1 in die Datei /etc/resolv.conf einzutragen. Außerdem sind alle anderen Nameserver-Einträge zu löschen. Meist überschreibt jedoch der jeweilige DHCP-Client-Daemon diese Einträge spätestens beim nächsten Reboot. Es ist daher der Dokumentation der jeweiligen Linux-Distribution zu entnehmen, wie man den DNS-Server dauerhaft anpasst. Bei Red Hat, Fedora und CentOS gibt man dazu den Befehl sudo setup ein und wählt Netzwerk-Konfiguration. Bei Suse nutzt man sudo yast und wählt Netzwerk - DNS- und Hostname.
Ein eigener lokaler Caching-DNS-Server ist eine geeignete Lösung, wenn die Provider die TCP- und UDP-Ports 53 sperren oder den Verkehr fälschen, um weiterhin freie DNS-Server nutzen zu können. Wenn Provider jedoch damit beginnen, Technologien wie Deep Packet Inspection[17] (DPI) zu nutzen, dann hilft der eigene lokale DNS-Server zunächst nicht weiter. In diesem Fall muss der DNS-Verkehr getunnelt werden.
Auch wenn die einmalige Installation einen gewissen Aufwand erfordert, lohnt sich die Mühe. Da bind sowohl quelloffen als auch für nahezu jede Plattform verfügbar ist, lässt sich der Quellcode bei weiteren Sperr- und Zensuraktionen der Provider so anpassen, dass eine verschlüsselte Tunnelung zu freien DNS-Servern möglich ist.
Die generelle Entwicklung weg von der Netzneutralität und hin zur informationellen Einbahnstraße, wie sie Vodafone bereits jetzt praktiziert, kann nur als äußerst bedenklich eingestuft werden. Während die Provider in den USA zur Netzneutralität verpflichtet[18] werden, beginnen sie in Deutschland mit der wohlwollenden Duldung durch Regierung und Regulierungsbehörde damit, immer mehr Verkehr zu blockieren und zu fälschen. Das Internet verkommt so zum kontrollierten und zensierten Web- und E-Mail-Dienst. Die Entwicklung neuer Anwendungen und Protokolle wird stark behindert.
Hinweis der Redaktion
Die ursprüngliche Fassung des Artikels ging davon aus, dass alle Vodafone-UMTS-Kunden keinen Zugang zu freien DNS-Servern erhalten. Dies gilt jedoch nur für Teile des Netzes in Abhängigkeit vom genutzten APN. Ferner leitet Vodafone keinen Traffic auf eigene Server um, wie ursprünglich angenommen, sondern sperrt jeglichen Traffic auf UDP-Port 53 mit Ausnahme der hauseigenen DNS-Server. In diesem Zusammenhang Dank an Vodafone für den detaillierten technischen Input, der zur genaueren Analyse der Situation beitragen konnte.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = https:/
[4] = https:/
[5] = http:/
[6] = https:/
[7] = http:/
[8] = https:/
[9] = http:/
[10] = ftp:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/