Die DNS-Zensur erfolgt häufig mit einem DNS-Proxy, aber für die DNS-Antworten die man als User erhält ist es egal ob der DNS-Server selbst oder ein vorgeschalteter DNS-Proxy zensiert.
Bemerkbar macht sich diese Zensur unter Anderem dadurch, das die zensierten DNS-Server die Namensauflösung fälschen, also falsche IP-Nummern ausgeben. Durch Vergleich der Namensauflösung eines unzensierten DNS-Servers und eines vielleicht zensierten kann man die Zensurlisten Sichtbar machen.
In Ländern, die das Internet mit weiteren Methoden umfassender zensieren, z. B. China, ist die DNS-Zensur ein wichtiger Bestandteil der Zensur.
Es wird zwar fast immmer versucht die dafür verwendeten Sperr-Listen geheim zu halten, aber dadurch das sie auf öffentlichen DNS-Servern verwendet werden, werden Sie veröffentlicht, so wie Telefonnummern im Telefonbuch oder Gewinn- und Verlustrechnungen im Handelsregister. Zudem ist auch die Information, woher DNS-Server seine Informationen bezieht, nicht geheim; man bekommt sie von Programmen wie dnstracer angezeigt.
Und man erhält sogar noch mehr Informationen von den DNS-Servern: Mittels
dig -t txt -c chaos VERSION.BIND @<nameserver> | grep VERSION
kann man die Bind-Version (die der Server ausgibt) auslesen und mittels
for i in `cat names.txt`; do host -r $i <nameserver>; done
sieht man welche der Domains (in der Liste names.txt) kürzlich vom Server aufgelöst wurde, also welche Domains mit diesem Server besucht wurden.
Daher sind auch die Zensurlisten auf DNS-Servern nur angeblich aber nicht tatsächlich geheim und auch prinzipiell nicht geheim zu halten, denn zumindest die Administratoren des DNS-Servers und die Kunden des DNS-Server-Betreibers können die Zensurlisten auslesen. Welche Einträge auf der Zensurliste stehen, sieht ein Administrator des DNS-Servers direkt und für die Benutzer zeigt sie sich mittels "Stoppseiten" oder beim Vergleich mit unzensierten DNS-Servern.
Ein Beispiel ist der Klassiker thepiratebay.org, einmal beim unzensierten Server 134.60.1.111 in Ulm und einmal beim zensierten dänischen Server 82.192.177.2 (ns11.struer.net) angefragt (Stand Juni 2009):
> dig @134.60.1.111 +short thepiratebay.org
192.121.86.15
und
> dig @82.192.177.2 +short thepiratebay.org
(schnelle leere Antwort)
D. h. von beiden Servern kommt sofort eine Antwort, aber der zensierte Server liefert eine leere Antwort, so als ob die Domain nicht existieren würde. Ebenso verhält sich der australischen Server 220.233.167.31 bei dailybunnies.com (Stand 2009-07-01).
Zu www.caw2.com liefert der 134.60.1.111 (neben vielen anderen DNS-Servern und z. B. das Online NsLookup unter http://centralops.net/co/) sofort die IP 208.109.164.175 während der 82.192.177.2 (ns11.struer.net) keine IP sondern nur ein Timeout liefert, und zwar reproduzierbar (Stand 2009-07-13).
Listen von zensierten und unzensierten öffentlichen DNS-Servern findet man nach Ländern geordnet beispielsweise auf http://www.ungefiltert-surfen.de.
Bevor man nach zensierten Domains sucht, sollte man aber testen, ob die Server auch für einen selbst öffentlich sind, und nicht nur für die Kunden des jeweiligen Betreibers zugänglich sind. Hierfür nimmt man zum Testen einfach eine Domain, die sicherlich nicht zensiert ist, z. B. whitehouse.gov, ibm.com, google.com oder apple.com.
Ebenso offensichtlich wie die Zensur durch eine falsche leere Antwort ist die Zensur mit Stoppschildern, die gefälschte IP-Nummern ausgibt und deshalb schreibt beispielsweise die BITKOM in ihrer Stellungnahme zur geplanten DNS-Zensur mit "Stoppseiten": "Da die Rückübermittlung einer Stoppseite per Definition öffentlich ist, schließen sich Stoppseitenbetrieb und Geheimhaltung der Liste faktisch gegenseitig aus.". Quelle: 16_9_1538.pdf von http://www.bundestag.de/ausschuesse/a09/anhoerungen/21_Anhoerung/Stellungnahmen/16_9_1538.pdf.
Das die Daten des DNS öffentlich ist zeigt sich schon auf Protokoll-Ebene: Die sichere DNS-Erweiterung DNSSEC verwendet ein asymmetrisches Kryptosystem zum Sichern der übertragenen DNS-Daten, verzeichtet aber auf Verschlüsselung, weil DNS-Daten öffentlich sind.
Das Vergleichen der Antworten von DNS-Servern ist sehr effizient, denn viele DNS-Server kann man auch aus der Ferne (auch im Ausland) abfragen; man braucht meist nicht zu Reisen oder Root-Server in der Ferne. Zudem kann man das mit einem Skript (s. u.) auch vollautomatisch erledigen lassen; man muß nicht aufwendig danach recherchieren.
Um erstmal den Großteil so einer Sperr-Liste vollautomatisch leicht lesbar zu machen reicht es aus eine Liste an verdächtigen Domains zu nehmen, z. B. list1.txt (siehe oben), und dann die Liste der zugehörigen IPs einmal mit einem verdächtigen DNS-Server und einmal mit einem unzensierten. Listen deutscher DNS-Server findet man unter http://www.stanar.de/, http://provider-stoerung.de/blog/ubersicht-dns-server/, http://www.netzwerkguide.com/dns-serverliste und internationale Listen unter http://www.dnsserverlist.org und http://www.ungefiltert-surfen.de. Listen unzensierter DNS-Server findet man z. B. beim CCC, GPF oder FoeBuD, unter http://www.ccc.de/censorship/dns-howto/?language=de#dnsserver, http://server.privacyfoundation.de/, http://www.foebud.org/aboutus/gegen-internetsperren-in-einer-freien-gesellschaft-foebud-richtet-anti-zensur-dns-server-ein/ .
Und auch Google bietet unzensierte DNS-Server an, unter 8.8.8.8 und 8.8.4.4: http://www.golem.de/0912/71643.html, http://code.google.com/intl/de-DE/speed/public-dns/index.html.
Im Prinzip könnte die Zensur auch das Routing so manipulieren, das die Anfragen zum unzensierten DNS-Servern umgeleitet werden auf zensierte DNS-Server (so ähnliche wie dies bei transparenten Zwangsproxies geschieht), und so das Lesen der Zensurliste erschweren. Diese Manipulation wäre aber aufwendig, weil ja die DNS-Antwort mit einer gefälschten IP-Adresse erfolgen muß, sie würde einige Kollateralschäden verursachen und sie wäre leicht aufzudecken, denn die Antwort vom DNS-Server enthält immer auch dessen IP-Adresse. Man sieht dies beispielsweise mittels
dig @85.214.73.63 | grep "SERVER:"
Dieses Umleiten zeigt sich beispielsweise beim Provider Comcast: http://comcastisfuckingwithyourport53traffic.wordpress.com/.
Im Prinzip könnte auch zusätzlich die IP-Adresse der Selbstauskunft vom DNS-Server gefälscht werden, aber dafür müßte der DNS-Server seine Antworten abhängig vom Routing fälschen, was erheblichen Aufwand bedeutet und bisher wohl nicht realisiert wurde. Das wäre auch wenig sinnvoll, denn zum einen wird über DNS auf Port 53 weit mehr abgewickelt als die bloße Namensauflösung, beispielsweise der Zonentransfer von Blacklisten zur Spambekämpfung oder privaten Intranet-Domains und zum anderen kann man auch diese Manipulation umgehen mit DNS-Servern die nicht den Default-Port 53 verwenden (Bsp.: dig @85.25.251.254 -p 110 +short yahoo.com) oder TorDNS oder HTTPS-DNS (z. B. 88.84.155.209:5667). Zudem ist der Nachweis der Port-Manipulation nicht schwer: Man benötigt einfach auf einem anderen Rechner, z. B. mittels PPPoE PassThrough oder beim Nachbarn oder einem Root-Server ein Lauschen auf Port 53, das alle Anfragen anzeigt, z. B. sudo nc -l -p 53 -u | od -hc, und schickt dort DNS-Anfragen hin (z. B. nslookup comcast.sucks.com mydomain.com); kommen die Anfragen nicht an, werden sie abgefangen (Datenunterdrückung) und werden die Anfragen beantwortet, wird nicht nur der Absender gefälscht, sondern auch der Inhalt der Antwort und zusätzlich die Existenz der Antwort, weil nc (netcat), wenn es nur lauscht, keinerlei Antwort schickt (dreifache Datenfälschung und Datenunterdrückung; in Summe also 4 Straftagen nach StGB).
Zudem legt § 88 TKG fest, dass die dabei übermittelten Inhalte dem Fernmeldegeheimnis unterliegen.
Die Unterschiede der Namensauflösung von den DNS-Servern zeigen die zensierten Seiten und die gefälschten Einträge, z. B. "Stopschild-Seiten" (neben anderen Unterschieden z. B. bei echten Timeout-Fehlern, die auch durch Disconnects/IP-Wechsel entstehen können). Diese Unterschiede zeigen jede Art der DNS-Zensur, also REFUSED Antwortcode Blockade, NXDOMAIN Manipulation, Entführung des Domainnamens, Name Astrayment und Nameserver bleibt still (siehe http://hp.kairaven.de/zensur/filterpilot2.html ). So entstanden beispielsweise 2008 die finnische und die schweizer Zensurliste (siehe oben).
Deshalb hier ein Skript, das die Ergebnisse vom zwei Servern in zwei Dateien (und abgestuft gefilterten Blacklists) ablegt, die man mit Vergleichs-Programmen wie kompare (Linux/BSD/MacOS usw.) oder Files Compare (MS-Windows) vergleichen kann: cens_dns_check1.sh.
Aufgerufen wird es mit der Liste der vermutlich zensierten Domains:
cens_dns_check1.sh list2.txt
Es funktioniert mit der Bash unter Linux/BSD/MacOS usw. und sollte mittels Cygwin auch unter MS-Windows funktionieren. Weil nslookup/host/dig nicht für URLs allgemein sondern nur Domains gemacht wurde, habe ich dazu aus der ersten Liste, list1.txt, eine zweite erstellt, die nur Domains enthält, mittels:
sed 's/\/.*//' list1.txt > tmpfile.txt
egrep -v -e "^([01]?[0-9][0-9]?|2[0-4][0-9]|25[0-5])\.([01]?[0-9][0-9]?|2[0-4][0-9]|25[0-5])\.([01]?[0-9][0-9]?|2[0-4][0-9]|25[0-5])\.([01]?[0-9][0-9]?|2[0-4][0-9]|25[0-5])$" tmpfile.txt > tmplist.txt
uniq tmplist.txt > list2.txt
rm tmpfile.txt tmplist.txt
Hierbei filtert das egrep diejenigen Zeilen aus, die nur eine IP-Nr. enthalten und mit denen daher keine Namensauflösung und folglich auch keine DNS-Zensur möglich ist.
Die erste Version dieser Liste list2.txt enthält 8812 Domains, wie "wc -l list2.txt" verrät.
Diese Liste wurde ebenso wie list1.txt upgedatet.
Für die 17624 DNS-Anfragen dazu benötigt das Skript vor Version 0.4 ca. 6 Stunden, ab Version 0.41 nur ca. eine Stunde und ab Vers. 0.7 nur ca. eine Viertelstunde, zumindest wenn man es in einer RAMDisk laufen läßt (siehe oben). Durch Reduzieren der Verzögerung im Skript (sleep 0.1) kann man es noch weiter beschleunigen, wenn man möchte, aber normalerweise sind knapp 10 DNS-Abfragen pro Sekunde und DNS-Server genug.
Ab der Version 0.3 erstellt das Skript auch die Blacklist, die der zensierte DNS-Server verwendet (wobei noch Fehlmeldungen enthalten sind, siehe unten). Es sind genau genommen mehrere Blacklists: Die erste enthält die Domains, zu denen die DNS-Server unterschiedlich antworteten. Die zweite baut darauf auf, ausgefiltert wurden aber die Domains mit IPs, die sich in den ersten drei Bytes der IP-Adr. nicht unterscheiden (fast immer Round Robin IPs).
Nachdem zuerst für die DNS-Abfragen im Skript nslookup verwendet wurde und dann kurzzeitig host verwendet wurde, wird nun dig verwendet. Allgemein kann man die DNS-Abfragen auch über Webseiten von verschiedenen Firmen durchführen; dort kann man den verwendeten DNS-Server angeben, so wie bei nslookup/host/dig.
Dabei muß man beachten, das dieses Verfahren nicht hundertprozentig zuverlässig ist: Getestet wird ja nur mit den "üblichen Verdächtigen"; ist die Blacklist umfangreicher, ist dies mit dem Skript nicht feststellbar. Zudem sind einige Seiten so gehostet, dass sie je nach geographischer Region auf andere IPs verweisen (z. B. www.symantec.com); die verwendeten DNS-Server sollten also zumindest im gleichen Land sein. Zudem gibt es zu Seiten wie google.com auch mehrere IPs, unterschiedliche Namensauflösung zu dynamischen IPs, hauptsächlich dann wenn die Abfragen nicht zeitgleich durchgeführt werden sowie Probleme wenn die Abfragen über Verbindungen mit Unterbrechungen wie Zwangs-Trennungen oder Verbindungsabbrüchen erfolgen. Außerdem zeigte sich das Seiten wie google.com je nach Auslastung der Server andere IPs angeben und dies auch abhängig von dem anfragenden DNS-Server (sogen. Round Robin IPs), die sich meist nur im letzten Byte, häufig nur in der letzten Ziffer, unterschieden. Allerdings verwenden Domains wie youtube.com Round Robin IPs, die sich in den letzten drei Bytes unterscheiden.
Weitere Unterschiede der DNS-Server gibt es durch unterschiedliche Konfiguration, wie ob Glue-Records zur Namensauflösung verwendet werden oder nicht; entsprechend werden Domains wie zoophilelinks.net aufgelöst oder nicht. Dies ist aber schon an der Grenze zur Zensur, weil es sich, außer für die Administratoren des betreffenden DNS-Servers, nicht von "gewöhnlicher Zensur" unterscheiden läßt und folglich von den Usern als Zensur interpretiert wird: http://www.heise.de/newsticker/foren/S-M-Net-sperrt-sinvention-com/forum-162741/msg-17095132/read/ .
Sicherlich nicht zensiert sind nur diejenigen Domains, zu denen der unzensierte und der eventuell zensierte DNS-Server die gleiche Antwort liefern, zumindest wenn die Abfragen nicht durch einen Verbindungsabbruch o. Ä. gestört wurden. Schon bei den ersten Tests mit dem Skript zeigte sich aber, das die anderen Domains generell nicht zensiert sind und die Grenze zwischen Schwächen der DNS-Server und Zensur fließend ist: Zu einigen Domains zeigte der Server vom Provider eine IP während der von FoeBuD einen anderen kanonischen Namen (CNAME) und zwei ganz andere IPs anzeigt; ein anderes Beispiel ist einmal SERVFAIL während der andere Server (von FoeBud) klaglos eine IP anzeigt, die aber nur zu google.com führt und als Default-IP ausgegeben wird (englisch: hijacking DNS Error pages, das entspricht beim Telefonieren statt der Fehlermeldung "Kein Anschluß unter dieser Nummer" Spam der Kategorie Cold Call, ist daher in D illegal und, weil Vortäuschung falscher Tatsachen, auch Betrug sowie Verletzung der Netzneutralität; siehe auch http://www.heise.de/newsticker/Internet-Engineering-Task-Force-streitet-ueber-DNS-Umleitungen--/meldung/142648 ). Das DNS Hijacking wird manchmal verharmlosend Wildcarding genannt: http://www.heise.de/newsticker/ICANN-Sicherheitsexperten-kritisieren-das-Umleiten-von-DNS-Anfragen--/meldung/140906 und es schadet dem Surfer auch direkt: Weil auf die Hijacking-URL umgeleitet wird, kann man nicht einfach einen Tippfehler ausbessern sondern muß die Adresse neu eintippen und das kostet Zeit und somit auch Geld. Und automatisierte Downloads werden damit sabotiert: Anstatt mit einer Fehlermeldung korrekt abzubrechen wird Spam downgeloadet. Hinzu kommt, das beim DNS Hijacking die Netzneutralität verletzt wird und vom Provider auch protokolliert wird, auf welchen Seiten der Kunde surft, bzw. wo er hinwollte und welche Tippfehler er machte; beim DNS Hijacking wird Deep Packet Inspection durchgeführt.
Dieser fließende Übergang zur Zensur zeigt sich auch bei allen anderen Zensur-Formen, z. B. gezieltem Traffic Shaping, bei dem die Datenrate kontinuierlich eingestellt werden kann.
Es sind auch die gegen DNS-Zensur empfohlenen DNS-Server nicht immer unproblematisch: OpenDNS hat eine Zensurinfrastruktur eingebaut, denn es ist auch ein konfigurierbarer Internet-Filter, der z. B. auch surfende Kinder schützen soll: http://www.opendns.com/about/announcements/116 und zudem DNS Hijacking.
Über alle diese Unterschieden zwischen den DNS-Servern kann sich die Zensur bemerkbar machen, aber ohne weitere Prüfung können es auch mehr oder minder gewöhnliche Unterschiede der Server sein. Durch Abgleich mit Listen von Zensur-Seiten wie "Stoppschild-Seiten" kann man aber Zensurlisten erhalten, die nur zensierte Domains enthalten.
Zumindest kann man mit dem Ausfiltern der gleichen Antworten von den verschiedenen DNS-Servern eine sehr lange Domain-Liste auf eine viel kleinere Liste verdächtiger Domains reduzieren, die durch die viel kleinere Länge viel leichter überprüft werden kann (das Skript ab Version 0.9 reduziert die Liste um rund 99%).
Überprüfen kann man sie manuell z. B. durch Aufrufen aller Seiten der Blacklist mit einem Browser, beispielsweise mittels
opera& sleep 2; while read line; do opera http://"$line"; done<medium_filtered_blacklist.txt
Das "http://" ist nötig weil die Browser es nicht automatisch verwenden, wie man am Beispiel ftp.pochta.ru sieht.
Dieses automatische Laden der Seiten, zu dem man natürlich auch andere Browser wie Firefox nehmen kann, kann man mit einem Alias weiter Vereinfachen um weniger Tippen zu müssen. Zudem kann man es mit Tools wie CensoRaser verbinden, um im Browser gleichzeitig die zensierte und die unzensierte Version der einzelnen Seite angezeigt zu bekommen.
Das Laden der Seiten benötigt einige Zeit, die man z. B. für eine Kaffepause nutzen kann. Danach kann man aber ca. 60 Domains pro Minute überprüfen und nebenbei eine aktuelle Liste der Stopschild-Domains mittels Copy&Paste erstellen. Die knapp 9000 Domains in list2.txt kann man so, nach der Filterung, in ca. 3 Minuten überprüfen.
Zumindest ist die ab Version 0.3 erstellte minimal gefilterte Blacklist (minimal_filtered_blacklist.txt) eine gute Ausgangsbasis, denn sie enthält alle Domains, zu denen die DNS-Server unterschiedliche Antworten liefern und die daher per DNS-Server zensiert sein können.
Ein erster Testlauf mit der Version 0.3 und nicht zensierten DNS-Servern filterte 300 aus 8812 Domains; d. h. zu 97 % werden die nicht zensierten Domains schon richtig erkannt. Verschiedene Testläufte zeigten, das die Erkennungsrate auch zeitabhängig ist und spät nachts auf über 99 % ansteigt, sicherlich wegen dem stark zeitabhängigen Traffic und der entsprechend schwankenden Auslastung der DNS-Server. Optimal ist daher das Skript zwischen 5 und 6 Uhr zu starten, weil dann der Traffic minimal ist, z. B. am Internet-Knoten DE-CIX: http://www.de-cix.net/content/network/Traffic-Statistics.html.
Bei der ab Version 0.7 vorhandenen zweiten Blacklist (medium_filtered_blacklist.txt) wurden diejenigen Domains aussortiert, bei denen sich die IPs nur im letzten Byte unterscheiden (fast immer Round Robin IPs). Ebenfalls gefiltert wurde die DNS-Server-Antwort ";; connection timed out; no servers could be reached". Bei unzensierten Servern enthält diese Liste nur halb so viele Domains; ca. 1,8 % (der Domains von list2.txt).
Ab der Version 0.82 werden in der zweiten Blacklist auch diejenigen IPs ausgefiltert, die sich in den letzten beiden Bytes unterscheiden (fast immer Round Robin IPs).
Trotzdem zeigen sich schon ab dieser Version zensierte DNS-Server sehr deutlich: Bei einem DNS-Server im deutlich zensierenden NRW, konkret der nic.netzagentur.nrw.de (131.220.4.1, Uni Bonn), zeigte sich das er über zwei Drittel der Domains in list2.txt filtert; genau 7037 von 9527 ! Zum Vergleich: Ein DNS-Server von einem (bisher) nicht zensierenden Provider wie M-Net (Stand Sept. 2009) liefert nur um 100 Einträge in der zweiten Blacklist, d. h. um den Faktor 70 weniger! Und diese wenigen Einträge erwiesen sich bisher nicht als zensiert sondern z. B. als Timeouts oder hijacked DNS Error pages.
Als Stichprobe habe ich dazu am 8.6.2009 mit den ersten drei Einträgen der ermittelten Blacklist getestet und tatsächlich: Zu 004champ.com, 012bon.com und 06.puremodels.info liefert der 131.220.4.1 in Sekundenschnelle weder eine IP-Nr. noch eine Fehlermeldung wie ein Timeout, während andere Server wie der vom FoeBud die IP-Nummern zu diesen Domains in Sekundenschnelle ausgeben; der 131.220.4.1 ist also nicht überlastet oder offline sondern stark zensiert, während er 6 Jahre vorher noch nicht zensiert war: http://www.heise.de/newsticker/NRW-Nameserver-umgeht-Sperrungsverfuegung-Update--/meldung/36766.
Allerdings ist der DNS-Server unter 131.220.4.1 auch fehlkonfiguiert: Einerseits sieht man mittels dig, das er angibt keine rekursive Auflösung zu machen, andererseits macht er es bei einigen Domains doch und gibt deren kanonische Namen, z. B. youporn, aus (aber mit abgeschnittenem oder verstümmeltem Suffix). Und mit einem einfachen nslookup bekommt man Timeout-Fehler; richtig wäre aber eine iterative Antwort: http://de.wikipedia.org/wiki/Rekursive_und_iterative_Namensaufl%C3%B6sung. Ebenso fehlkonfiguriert wurde der 134.95.100.209.
Ab der Version 0.96 (2010-04-28) verwendet das Skript auch die Ports der Nameserver explizit (als konfigurierbare Parameter), denn um zu verhindern das durch Zwangsumleitungen von dem Standard-Port (53) DNS-Server zensiert werden gibt es einige auf anderen Ports, z. B. 87.118.100.175, 85.25.251.254 und 94.75.228.29 auf 110.
Ab der Version 0.97 (2010-04-29) ist das Skript erfolgreich angepaßt für Cygwin und schwächere Rechner, denn die ersten Versionen machte ich auf einem PC mit vier Opteron 875 (dual-core, 2,2 GHz) und 16 GiB RAM unter Debian Lenny 64 Bit. Auf einem älteren 32-Bit PC mit knapp 1 GB RAM, nur einem Core Duo T2050 (dual-core, 1,6 GHz) und Cygwin 1.75 unter MS WindowsXP Prof. zeigte sich, das die Version 0.96 dort zu viel RAM benötigt, weil sie für den Rechner zu viel forkt. Deshalb ist die default-Wartezeit zwischen zwei DNS-Anfragen um (fast) den Faktor vier erhöht, so das das neue Skript rund viermal länger braucht, und zwar etwas mehr als eine Stunde für knapp 10.000 Einträge in list2.txt auf einem schnellen PC.
Allerdings ist unter Cygwin die Ausgabe der Bash und anscheinend auch sonst merklich langsamer ist als unter Linux, so das es mit tracing ("set -x" im Skript) zusätzlich merklich langsamer ist und 3 Stunden benötigit; das tracing ist daher nun per default auskommentiert.
Mittels CygwinPortable sollte Cygwin und auch das Skript vom USB-Speicherstick gestartet werden können.
Ein dem Skript ähnliches Programm, ebenfalls Open Source, aber anscheinend nur für MS-Win, ist ZensorChecker.
Diesem ähnlich ist das Capt. Picards DNS Blocklist Probe, mit GUI. Es ist mit rund 160.000 Domains pro Stunde schön schnell ist. Von dem Projekt stammt dieses Bild, das die Arbeitsweise beim Sichtbar machen von angeblich geheimen DNS-Zensurlisten zeigt:
Dies zeigt die Bottom-Up-Vorgehensweise; die Top-down-Vorgehensweise ist die Listen bei einer der Quellen (Zensurbehörde/Propagandaministerium oder beim durchführenden Provider oder auf dem Weg dorthin) einzusehen oder zu kopieren und beispielsweise über Wikileaks zu veröffentlichen. Es gibt zwar Versuche die Top-down-Vorgehensweise zu blockieren, beispielsweise durch verwenden von Hash-Werten statt den Domain-Namen, aber a) ist dies ist in Deutschland illegal weil damit durch Hash-Kollisionen völlig unbeteiligte Domains gesperrt werden können und b) kann man damit durch gezielte Hash-Kollisionen Domains stillegen, beispielsweise im Rahmen eines Cyberwars, oder Domain-Inhaber erpressen.
Ein anderes Top-Down-Verfahren ist bei den Providern direkt anzufragen und deren meist korrekte Selbstauskunft auszuwerten, so wie z. B. auf http://zensurprovider.de/ (eine Kopie aus dem Google-Cache vom 1.10.2009 hier) zu sehen. Dort erhält man zumindest die generelle Auskunft ob oder ab wann zensiert wird oder nicht. Das erleichtert das Suchen nach Zensurlisten.
Bei der Bottom-Up-Vorgehensweise kann man die Ergebnisse mehrerer PCs zusammenführen, so wie dies beispielsweise bei Seti@Home geschieht, um es zu beschleunigen und tagesaktuelle sowie komplette Zensurlisten zu erhalten.
In Arbeit ist beim Skript noch das Ausfiltern von Default-IPs (hijacked DNS Error pages), die auf google.com oder andere Defaults verweisen. Damit sollten weniger als 0,5 % auf der gut gefilterten Blacklist übrig bleiben.
Ebenfalls geplant ist ein Ausfiltern und Auflisten der "Stopschild-Seiten", denn mittels Reverse-DNS, kurz rDNS, kann man evtl. feststellen (mit einem weiteren Skript) welche noch nicht in list2.txt aufgelisteten zensierten Domains ihnen zugeordnet sind und daher noch in diese Liste gehören.
Daneben kann man die Stoppschild-Server auch über die Bildersuche (nach den Stoppschild-Bildern) mit Bilder-Suchmaschinen finden, aber interessant ist ja neben einer Liste der Stoppschild-Server, für welche zensierten Seiten die Zensur diese Stoppschild-Server verwendet.
Dafür benötigt man erstmal eine Liste der Stopschild-Server-IP-Nummern, list3.txt.
Diese Liste kann man auch verwenden um die "Stopschild-Seiten" mittels Firewall zu sperren. Dazu reicht unter Linux/BSD/MacOS usw. eine Zeile:
cat list3.txt | while read line; do iptables -A INPUT -s "$line" -j REJECT ; iptables -A OUTPUT -d "$line" -j REJECT ; iptables -A FORWARD -d "$line" -j REJECT ; done
Dabei ist man nicht auf einzelne IPs beschränkt; man kann auch IP-Bereiche sperren.
Mit diesem Sperren der "Stopschild-Seiten" schränkt man sich normalerweise nicht ein: Über einen indirekten Inetnet-Zugang, z. B. über einen Proxy, kann man die gesperrten Seiten weiterhin erreichen, aber mit einer anderen IP-Nr. als der vom eigenen Anschluß.
Zu den bisherigen Ergebnissen mit dem Skript cens_dns_check1.sh habe ich hier eine Seite angelegt.