Software zur Zensur (gegen Zensur)

Inhaltsverzeichnis

Einleitung

Ein wenig Theorie

Skript zum Downloaden von vermutlich zensierten URLs

Skript zum Sichtbar machen von angeblich geheimen Zensurlisten der DNS-Zensur durch Vergleich der Namensauflösungen

Skript zum Suchen nach Stoppschild-Seiten und Nachsehen, was dahinter ist

Skript zum Sichtbar machen von angeblich geheimen Zensurlisten der DNS-Zensur und zum Auflisten von Stoppschild-Seiten mittels DNSSEC

Skript zum automatisierten Testen ob eigene Seiten zensiert sind

Weitere geplante Skripte

Sonstiges


Einleitung

Zur Zensur, insbesondere zu deren Überprüfung, findet man generell wenig Software, auch auf freshmeat.net und sourceforge.net.
Eine Ursache hierfür ist die Meta-Zensur, durch welche die Zensur verheimlicht wird, z. B. durch
Zensieren von Suchergebnissen und das die Anbieter von Soft- und Hardware so verdeckt für ihre Produkte werben, das deren Veranstaltungen, z. B. der Messe ISS World Training, nur besuchen kann, wer schon in der Branche oder für einen der staatlichen Überwachungsdienste arbeitet: http://www.heise.de/tr/artikel/Mein-Job-beim-Big-Brother-936910.html.
Deshalb habe ich ein bischen Software dazu gemacht und als Projekt censorshiptools dort eingestellt, und es sind auch andere Programmierer eingeladen es weiterzuentwickeln, auch weil die Regierungs-Koalitition im April 2008 verkündete der Internetzensur sogar weltweit entgegenzutreten: http://www.heise.de/newsticker/Grosse-Koalition-will-Internetzensur-entgegentreten--/meldung/106996.
Da ich Bayern wohne und arbeite, stehen meine Dateien unter der Beerware License sofern nichts anderes in meinen Dateien angegeben ist.


Ein wenig Theorie

Zensur ist definitionsgemäß ein politisches Verfahren, um Inhalte zu kontrollieren und wird in modernen Demokratien strikt abgelehnt. Die Zensur (§ 5 GG) erfolgt grundsätzlich auf zwei Wegen: Inhalte unterdrücken (Datenunterdrückung, § 303a StGB) und Inhalte fälschen (Datenverfälschung § 269 StGB). Verbunden wird es fast immer mit dem Verbreiten und insbesondere Wiederholen von gefälschten und erfundenen Inhalten (Spaming/Propaganda) und meist auch Überwachung (Überwachungsstaat).
Die Zensur gibt es in Form der Vorzensur (vor der Veröffentlichung), Selbstzensur, Nachzensur und Metazensur (Zensur über die Zensur; Zensur als Selbstzweck).
Dagegen gibt es für das Internet verschiedene Strategien wie Inhalte an vielen verschiedenen Stellen platzieren, Inhalte Signieren (z. B. mit PGP/GPG) und Anti-Spam-Techniken verwenden.
Wichtig ist aber vor Allem die Zensur-Maßnahmen transparent zu machen, beispielsweise die verwendeten Zensurlisten zu publizieren, um sie zumindest überprüfbar, überwachbar und kontrollierbar zu machen, denn die Zensur erfolgt meist wie im Mittelalter unkontrolliert und im Geheimen von sehr kleinen Gruppen oder sogar einzelnen mit meist zweifelhafter Qualifikation wie Legitimation, beeinflußt aber Millionen bis Milliarden Menschen.
Das Internet bietet hierzu viele Möglichkeiten, die schon jeder mit einem eigenen PC und Internet-Zugang wahrnehmen kann: Die Listen von dem, was im Internet zensiert wird, findet man von Leuten, die direkten Zugang zu den Listen haben, früher oder später auf Seiten wie wikileaks.org und ein einfacher Internet-Benutzer erkennt zumindest den Großteil der Listen mit einer differentiellen Analyse, beim Vergleichen von dem was (vielleicht) zensiert ist und dem was unzensiert (original) ist.
Beispielsweise zeigt sich die DNS-Zensur (engl. DNS censorship) durch gefälschte DNS-Einträge auf zensierten DNS-Servern, die man durch Vergleichen der Antworten dieser Server mit denen von einem unzensierten Server auflisten kann; so erhält man die Zensurlisten der DNS-Zensur.
Ein anderes Beispiel ist die direkte Überprüfung von eigenen Dateien auf Webservern: Man kann bei den eigenen Dateien einfach überprüfen ob die Dateien a) verfügbar sind und b) mit dem Original übereinstimmen (d. h. nicht gefälscht sind).


Skript zum Downloaden von vermutlich zensierten URLs

Dieses Bash-Skript, cens_dl1.sh, lädt die vermutlich zensierten URLs, die in der Liste list1.txt stehen und löscht sie unmittelbar danach.
Es nutzt/testet die Überwachung, die begleitend zur Zensur erfolgt.
Aufgerufen wird es mit der Liste der vermutlich zensierten URLs als Parameter:

cens_dl1.sh list1.txt

Es funktioniert mit der Bash unter Linux/BSD/MacOS usw. und sollte mittels Cygwin auch unter MS-Windows funktionieren.

Die Liste list1.txt enthält mit

www.xs4all.nl
sex.com
bet3000.com
wikileaks.de
wikileaks.org
thepiratebay.org
www.allofmp3.com
www.wikipedia.org
odem.org
www.nazi-lauck-nsdapao.com
tippen4you.com
www.youporn.com
www.youtube.com
www.redtube.com

neben seit 2007 in NRW zensierten Seiten, auch generell häufig zensierte Seiten, hauptsächlich aus den News von heise.de.
Weitere Quellen der Liste sind:
Australische Zensurliste, 2008, https://secure.wikileaks.org/wiki/Australian_government_secret_ACMA_internet_censorship_blacklist,_6_Aug_2008
Dänische Zensurliste, 2008, http://wikileaks.org/wiki/Denmark:_3863_sites_on_censorship_list,_Feb_2008
Finnische Zensurliste, 2009-01-05, http://www.wikileaks.com/wiki/797_domains_on_Finnish_Internet_censorship_list,_including_censorship_critic,_2008
Norwegische Zensurliste, 2009-03-18, http://wikileaks.org/wiki/Norwegian_secret_internet_censorship_blacklist,_3518_domains,_18_Mar_2009
Schwedische Zensurliste, 2008, http://www.lapsiporno.info/blocked.glocalnet
Schweizer Zensurliste, 2008-12-27, http://apophis.ch/de/node/107
Thailändische Zensurliste, 2008, http://www.wikileaks.net/wiki/Thailand_official_MICT_censorship_list,_20_Dec_2008

Die Liste list1.txt enthält nichts, was nicht schon woanders veröffentlicht wurde.
Zudem sind die Einträge uninteressant, weil die allermeisten nichts auch nur möglicherweise auf illegales verweisendes enthalten; offenbar dienen diese Zensurlisten nur als Arbeitsbeschaffungsmaßnahme ohne erkennbares Ziel, außer dem Wahlstimmenfang.
Abgeschnitten wurde bei den Listen-Einträgen überflüssiges wie Leerzeichen am Zeilenende/Zeilenanfang und das http:// am Zeilenanfang, weil bisher nur dieses Protokoll verwendet wurde; die Liste enthält daher also nur Teile von Quelltexten von Links (d. h. keine Links) und nur unvollständige URLs.

Zu den Details des Erstellens und Updatens von Zensurlisten habe ich hier eine Seite mit Skripten zur Automatisierung erstellt.

Durch das Entfernen von Duplikaten wurden aus 14209 Einträgen nur 11544, die das Skript in ca. 4 Stunden downloaden kann.
Die Version ab 2009-05-07 ist geringfügig überarbeitet: Backslashes wurden durch Slashes ersetzt und Whitespaces am Zeilenende gelöscht.

Die Version ab 2009-05-14 enthält auch www.g-stream.in, denn es wurde versucht diese Domain in Deutschland zensieren zu lassen, laut http://openjur.de/u/30638-308_o_548-08.html und http://www.heise.de/newsticker/Urteil-DNS-Sperren-sind-zur-Blockade-von-Inhalten-nur-bedingt-geeignet--/meldung/137773.
Dem Urteils-Text nach muß man nur nach "Kino im Internet" und ".in" suchen, um diese Domain innerhalb einer Minute zu finden. Damit auch jeder DAU diese Domain findet und Verwechselungen ausgeschlossen sind, ist in dem Urteil die Startseite sogar mit mehreren Rubriken genau beschrieben. Der Prozess ist daher ein Beispiel für den Streisand-Effekt.
Daneben habe ich 4 Einträge der Art *.doc? entfernt; offenbar sind von irgendeiner Liste ein paar Word-Dokumente als URLs in der Liste (list1.txt) gelandet.

Update 2009-05-25: Hinzugefügt habe ich bei list1.txt das Update der australischen Zensurliste: http://file.sunshinepress.org:54445/acma-secret-blacklist-11-mar-2009.txt . Beim Überfliegen der neuen Liste habe ich noch Müll wie "biz" und "may29" entfernt und einzelne Schrägstriche am Zeilenende entfernt, denn die Liste enthielt Zeilen, die sich nur darin unterschieden und sehr wahrscheinlich Dubletten sind, auch wenn sie nicht wirklich Dubletten sein müssen, weil ein Dateiname durchaus einen Schrägstrich enthalten kann: http://www.faqs.org/faqs/unix-faq/faq/part2/section-2.html.
Daneben kann es in Dateinamen auch diverse nicht-druckbare Sonderzeichen wie Zeilenumbrüche geben (sowas hatte ich schon downgeloadet), aber das wird hier nicht berücksichtigt und ist bei der Liste der zensierten Domains (list2.txt unten) egal, weil Domainnamen sowas (noch) nicht enthalten.
Die neue Version von list1.txt enthält nun 11857 Einträge.

Update 2009-06-03: Eingefügt ist nun auch die chinesische Liste von Wikileaks, Chinesische Blacklist 2009-05-01 http://www.wikileaks.com/wiki/China:_censorship_keywords,_policies_and_blacklists_for_leading_search_engine_Baidu,_2006-2009,
sowie diese Domain hier und sourceforge.net, weil ich die Software zur Zensur dort als das Projekt censorshiptools eingetragen habe und mit dem Test unter http://www.greatfirewallofchina.org/ schon 2006 sehen konnte das meine Domain dort zensiert ist, obwohl nichts chinesisches enthalten ist und zur Zensur oder auch nur verwandten Themen hier nichts vorhanden war. Zudem erhielt ich zu der Zensur weder eine Anfrage noch eine Mitteilung.

Update 2009-06-22: Eingefügt ist nun auch die neue italienische Liste von Wikileaks, http://wikileaks.org/wiki/Italian_secret_internet_censorship_list,_287_site_subset,_21_Jun_2009,
die mit 287 Domains relativ klein ist. Siehe auch: http://www.gulli.com/news/kinderporno-sperren-italiens-2009-06-22/.
Die list1.txt enthält nun 12792 Einträge und die list2.txt (siehe unten) 9654. Damit war schon über die Hälfte dieser neuen Liste in den alten enthalten.

Update 2009-10-04: Eingefügt ist nun auch die Zensurliste von Lycos, https://secure.wikileaks.org/wiki/Lycos_Deutschland_Suchmaschinen_Zensurliste.
Damit enthält list1.txt nun 13098 Einträge und list2.txt 9945 Einträge.

Upate 2009-11-04: Eingefügt ist nun auch kino.to, siehe http://www.heise.de/newsticker/meldung/Filmindustrie-fordert-Massnahmen-gegen-Verlinkung-illegaler-Streaming-Seiten-849096.html.

Upate 2009-12-24: Eingefügt sind nun auch planetclimax.com und sinvention.com, weil die von den DNS-Servern von M-Net seit Monaten reproduzierbar nicht aufgelöst werden.

Mit dem Skript cens_dl1.sh kann man als Zensor testen ob die Zensur funktioniert oder auch die Zugriffsstatistik "optimieren".
Weil das Skript mit "technischer Umleitung" (Proxy) arbeitet, gibt es damit bei zensierten Seiten keine juristischen Probleme, selbst wenn man die Aufrufe über den Proxy nachverfolgen könnte.
Sollten die Pläne der Bundesregierung vom April 2009 wie geplant umgesetzt werden, kann man das Skript dank der "Echtzeitüberwachung" auch als vollwertigen Ersatz für den 110-Notruf verwenden! Wie das ungefähr aussehen wird, kann man hier sehen: http://tinyurl.com/c466vo.
Allerdings sollte man dann (ab 2010) für die "echten" Seiten vorher den Proxy im Skript austragen und überprüfen, ob man (vom Provider) keinen transparenten Zwangsproxy hat. Dafür eignen sich Testseiten wie http://proxydetect.com in Verbindung mit route bzw. "route print" unter MS-Win.
Die Proxies der Provider findet man in den Unterlagen mit den technischen Daten, die man zu seinem Internet-Zugang erhält, neben den DNS-Servern. Nicht ganz aktuelle Listen von Proxies der Provider findet man auch hier: http://www.pcwelt.de/forum/browser-internet-explorer-firefox-seamonkey-opera-co/174745-proxy-server.html.

Vollständig Automatisieren kann man das Downloaden beispielsweise mit einem Eintrag in der /etc/crontab:

0 0 * * * user sleep $[$[$[`expr \`date +\%s\` + $RANDOM`]+$RANDOM*32768]\%4321]; cd /mnt/tmp15/; /bin/bash ./cens_dl1.sh list1.txt

Damit wird das Downloaden zu einem zufälligen Zeitpunkt in der Nacht (kurz nach Mitternacht) gestartet und so strafrechtlichen Problemen damit aus dem Weg gegangen, denn das Downgeloadete wird ja in dem Moment gelöscht, in dem es komplett ist (d. h. es wird nichts gespeichert und ist damit für einen Menschen nicht ohne Weiteres wie Packet-Sniffer zugänglich) und dieses Downloaden erfolgt nicht von einer juristischen Person, sondern nur von einer Maschine.

Sinnvoll ist aber auch zusätzlich das Downloaden in einer RAM-Disk, damit a) garantiert keine Spuren vom Downloaden nachweisbar sind und b) automatisch nicht downgeloadet wird, was größer als der noch freie Platz in der RAM-Disk ist (wget bricht dann mit "No space left on device" ab). Dazu reichen unter Linux/BSD/MacOS usw. ein paar Zeilen im Bookskript (/etc/init.d/boot.local unter SuSE, /etc/rc.local unter Debian):

# Ramdisk for user, with tail packing (block suballocation).
WORKDIR="/mnt/tmp15"
RAMDEVICE="/dev/ram15"
SOURCEDIR="/home/user/somedir"
mkdir -p "$WORKDIR"
chown user.users "$WORKDIR"
mkfs.reiserfs -f "$RAMDEVICE"
mount -t reiserfs -o noatime "$RAMDEVICE" "$WORKDIR"
cp -a "$SOURCEDIR"/list1.txt "$WORKDIR"/
cp -a "$SOURCEDIR"/cens_dl1.sh "$WORKDIR"/
chown -R user.users "$WORKDIR"
# reduce the available space to limit the downloads more restrict
dd conv=noerror if=/dev/zero of="$WORKDIR"/zeros.bin bs=1K count=30000

Bei Debian ist der RAMDisk-Treiber im Kernel, beim SuSE (11.1) muß man vorher das RAMDisk-Modul rd laden, mittels "modprobe rd".

Die aktuelle Dokumentation zu den RAMDisks findet man auch in /usr/src/linux/Documentation/ramdisk.txt wobei die genaue Stelle von der Distribution abhängt.

Man kann das Skript natürlich noch ausbauen, beispielsweise indem man mittels ipspoof (von http://www.ryanspc.com/spoof/ipspoof.c, auch im Archiv www.archive.org), nemesis, Sendip, oder Spoofer die Anfragen mit einer ganz anderen IP-Adresse abschickt (sogen. IP-Spoofing; es sieht dann so aus, als käme die Anfrage von der ganz anderen IP-Adresse; sinnvoll z. B. um bei einem Bankraub bei einer Bank nebanan als Notruf-Ersatz einige Anfragen nach zensierten Seiten mit einer der IPs der Bank abzuschicken; die IPs findet man z. B. in den Email-Headern von der Bank).
Das IP-Spoofing einzubauen ist noch in Arbeit.

Bisher verwendet wird von bisher unbekannten schon seit längerem Malware wie Trojaner und Viren (nicht simple Skripte) zum Downloaden und heimlich unterschieben von Kinderpornos mit Erfolg: Nur eines der Opfer konnte seine Unschuld zweifelsfrei beweisen, eines konnte seine Unschuld nie zweifelsfrei beweisen und die anderen wurden "erfolgreich" des Downloadens von Kinderpornos beschuldigt, weil sie nicht ausreichend Maßnahmen gegen Malware ergriffen hatten und zudem ihre Datenträger nicht verschlüsselt hatten, so das die untergeschobenen verdächtigen Pornos ohne weiteres gefunden werden konnten: http://gulli.com/news/malware-l-dt-kinderporno-herunter-2009-11-10
und
http://tech.yahoo.com/news/ap/20091109/ap_on_hi_te/us_tec_a_virus_framed_me.


Skript zum Sichtbar machen von angeblich geheimen Zensurlisten der DNS-Zensur durch Vergleich der Namensauflösungen

Die Zensur im Internet beruht meist "nur" auf gefälschten DNS-Einträgen, z. B. in Finnland. Diese Form der Zensur wird als DNS-Zensur (engl. DNS censorship) bezeichnet, ist technisch DNS-Spoofing, und hat nichts mit Netzfiltern zu tun (Netzfilter sind eher ein Gegenteil von Zensur, denn Netzfilter können die Verbindung zum Internet messbar verbessern: http://forum.mhilfe.de/viewtopic.php?t=2027, http://forum.mhilfe.de/viewtopic.php?t=3278, http://wiki.mhilfe.de/index.php?title=Doppeldrossel ).
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:
Differentielle DNS-Analyse
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.

Das Problem das nur ein Nameserver erreichbar ist und dessen Lösung

Es ist möglich das über einen sehr stark eingeschränkten Internet-Zugang nur ein Nameserver erreichbar ist. Für diesen Fall gibt es Workarounds wie Tunnel oder auch Online-DNS über Webseiten, aber zum Vergleich von Nameservern sind sie gar nicht nötig, denn man kann das Skript auch zerlegen für Offline-Vergleiche: Man kann erstmal die Antworten von einem Nameserver A abspeichern, dann (über einen anderen Internet-Zugang) die von einem anderen (B) und anschließend vergleichend auswerten.
Daneben gibt es noch mehrere Möglichkeiten statt Daten nur Metadaten auszuwerten und dafür benötigt man meist nur einen Nameserver (siehe unten).
Provider können daher das Auslesen der Zensurlisten durch Vergleichen von Nameservern erschweren, aber niemals verhindern.

Dieses Separieren der Anfragen an die Nameserver kann man auch nutzen um das Skript zu optimieren zum Abfragen von x>1 verschiedenen und vermutlich zensierten Nameservern und einem unzensierten: Zum Vergleichen muß man ja nicht für jeden der x Nameserver jeweils y Anfragen zweimal schicken (einmal an einen vermutl. zensierten u. einmal an den unzensierten), sondern man kann jede der y Anfragen genau einmal an jeden der x+1 Server (x vermutl. zensierte plus ein unzensierter) schicken. Damit reduziert sich die Anzahl der DNS-Anfragen von 2*x*y auf (x+1)*y.


Probleme beim Reverse-DNS (rDNS) und deren Lösung
Das Haupt-Problem beim rDNS ist das es nicht einfach eine Umkehrung des DNS ist; es basiert auf Reverse-DNS-Einträgen und die enthalten meist nicht alle Domains zu einer IP-Nr.. Außerdem können Reverse-DNS-Einträge auch schlicht fehlen oder leer sein; ein Beispiel ist www.peta2.com mit der IP-Nr. 69.166.131.152, ein anderes die Ausgabe von

nmap -R -sL 209.85.229.99/27 | awk '{if($3=="not")print"("$2") no PTR";else print$3" is "$2}' | grep '('

Dadurch können DNS- und rDNS-Einträge inkonsistent sein und zudem muß man bei zensierten DNS-Servern auch davon ausgehen, das nicht nur die DNS-Einträge sondern auch die rDNS-Einträge gefälscht werden.
Diese Probleme werden aber nebenbei von dem oben erläuterten Skript cens_dns_check1.sh (ab Version 0.91) gelöst: Es werden ja die DNS-Einträge zu den Domains gespeichert (von dem Skript im Unterverzeichnis backup).
Und mit diesen Daten kann man ganz einfach das DNS umkehren; schon hat man rDNS, beispielsweise indem man in den gespeicherten Daten nicht nach Domains sondern nach IP-Nummern oder auch nach kanonischen Namen (CNAMEs) sucht!
Im einfachsten Fall geschieht dies mit den DNS-Daten in Verzeichnissen die eindeutige Bezeichnungen für den DNS-Server und ggf. auch die Zeit der DNS-Abfrage(n) enthalten sowie dem Domainnamen als Dateinamen.
Beispielsweise findet man in den Ausgaben vom Skript cens_dns_check1.sh (im Unterverzeichnis backup) so alle (lokal bekannten) Domains mit der Zeichenkette "6.o" irgendwo im Namen:

find -type f -name *6.o*

und in den gefundenen Dateien stehen die zugehörigen DNS-Einträge.
So findet man alle Domains, die es unter der IP-Nr. 69.166.131.152 gibt (und die in den schon vorhandenen Informationen von den DNS-Servern enthalten sind):

find -type f -name "*" -exec grep -il "69.166.131.152" {} \;

und so findet man alle Domains mit dem kanonischen Namen ftp.pochta.ru:

find -type f -name "*" -exec grep -il "ftp.pochta.ru" {} \;

Das kann man natürlich noch ausbauen, z. B. mit einem Datenbankmanagementsystem wie PostgreSQL.
Daneben gibt es noch weitere Möglichkeiten für rDNS wie z. B. mit einer Suchmaschine nach der IP-Nr. zu suchen, beispielsweise nach "ip:69.16.137.252" bei Google oder http://www.live.com/ aber rDNS-Seiten wie http://www.domaintools.com/reverse-ip/, http://www.pageranktesten.de/reverseiplookup.php und http://www.yougetsignal.com/tools/web-sites-on-web-server/ liefern meist präzisere Antworten, wobei nur die letzte dieser Seiten gut aussieht: Sie findet auf 69.16.137.252 immerhin 453 Domains (Stand 2009-05-26), die wie mehrere Stichproben mittels nslookup zeigen, korrekt aussehen, und zudem kann man dort auch die Domains zu IP-Adressblöcken ausgeben lassen.
Weitere ähnliche Seiten findet man mit der Suche nach "reverse IP domain check".

Das Problem das die Skripte nur bekannte Zensurlisten verwenden und dessen Lösung
Das grundsätzliche Problem der oben erläuterten Skripte ist, das sie bisher nur die URLs bzw. Domains verwenden, die auf veröfftentlichten Zensurlisten stehen, also die "üblichen Verdächtigen".
Daher können die Skripte, und auch Programme wie ZensorChecker, neu gesperrte Domains nicht sichtbar machen!
Dies kann man aber ändern, indem man auch andere als die "üblichen Verdächtigen" überprüft.
Deshalb kommt hier demnächst auch ein Skript, das eine Liste zufällig ausgewählter Domains erstellt.
Damit kann man auf einem PC mit mindestens ISDN-Bandbreite (64 kBit/s) ca. eine Million weitere Domains pro Tag überprüfen.
Damit kann man mit einfacher ISDN-Bandbreite die DNS-Zensur in weniger als einem halbem Jahr komplett erfassen, denn Ende Mai 2009 gibt es nur um 110 Millionen Domains: http://www.domaintools.com/internet-statistics/.
Verwendet man mind. 110 PCs parallel, in einem Projekt analog dem Seti@Home, erhält man tagesaktuelle und komplette Zensur-Listen.
Die Liste der aktuell vorhanden Domains zu erstellen erfordert ein wenig Aufwand: Zuerst benötigt man die TLD Zone Dateien, z. B. von http://www.premiumdrops.com/zones.html. Neben dieser Quelle gibt es weitere:
und eine Übersicht wo man alle anderen TLD Zone Dateien erhalten kann gibt es bei der IANA: http://www.iana.org/domains/root/db/.
Aus diesen TLD Zone files kann man die Domainamen auslesen, d. h. den Eintrag bei "name" im SOA.
Im Prinzip könnte man die TLD Zone files auch von Nameservern direkt auslesen (sogen. AXFR), aber dies ist bei den Nameserver meist abgestellt.

Neben den DNS-Zonen-Dateien gibt es ähnliche aber nicht ebenso umfassende Quellen, die man nutzen kann: Von der RIPE findet man die Datenbank nach Nummern hier: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz. Gepackt ist sie 130 MB groß und entpackt rd. 1 GB groß (Stand Juli 2009).
Und die Datenbank nach Domains findet man hier: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.domain.gz. Gepackt ist sie 12 MB groß und entpackt rd. 176 MB groß (Stand Juli 2009).
Kleinere Dateien findet man bei den anderen Regional Internet Registries: Bei AfriNIC unter ftp://ftp.afrinic.net/pub/zones/, bei ARIN unter ftp://ftp.arin.net/pub/zones/, bei APNIC unter ftp://ftp.apnic.net/public/zones/ und bei LACNIC unter ftp://ftp.lacnic.net/pub/zones/.

Neben den Auslesen von staatlichen Zensurlisten eignet sich die Liste der (allermeisten) registrierten Domains auch zum Auslesen der "Sperrlisten" von Jugendschutzprogrammen zumindest bezüglich Domains. Diese "Sperrlisten" sind nämlich häufig verschlüsselt.

Im Prinzip könnte man auch durch systematisches Abfragen aller öffentlichen IPV4-Nummern mittels rDNS nach Domains suchen, aber das rDNS eignet sich dafür nur schlecht: Schon zu der IP-Nr. unter der sich sex.com und fast 500 weitere Domains befinden meldet das rDNS keine Domain, weil kein PTR vorhanden ist.
Trotzdem und ergänzend zu dem (geplanten) Skript für zufällig ausgewählte Domains gibt es hier ein Skript das zuällig ausgewählte (öffentliche) IP-Adressen ausgibt.


Skript zum Sichtbar machen von angeblich geheimen Zensurlisten der DNS-Zensur und zum Auflisten von Stoppschild-Seiten mittels DNSSEC

Die Zensur durch gefälschte DNS-Einträge funktioniert beim DNSSEC nicht so leicht wie beim einfachen DNS, weil DNSSEC mittels Public-Key-Kryptografie sicherstellt, dass eine Antwort des DNS genau den Informationen entspricht, die der verantwortliche Zonenverwalter in das System eingepflegt hat. Daher fallen die gefälschten DNS-Einträge der DNS-Zensur beim DNSSEC unvermeidbar sofort auf und ein Umleiten auf "Stopseiten" funktioniert damit nicht, weil die gefälschten DNS-Einträge als gefälscht und damit ungültig verworfen werden: http://www.heise.de/newsticker/DNSSEC-Test-soll-Probleme-loesen-helfen--/meldung/141492.

Unter gefälschte DNS-Einträge fällt neben Entführung des Domainnamens und Name Astrayment auch NXDOMAIN Manipulation, denn auch diese Antwort kann nur vom Inhaber der Top-Level-Domain authorisiert und damit gültig signiert sein.
Ebenso wie beim einfachen DNS hat der DNSSEC-Server aber noch die Möglichkeit mit Nameserver bleibt still (oder Timeout) zu "antworten", aber das ist auffällig und deutet auf Zensur hin (wenn kein Verbindungsabbruch vorliegt).
Gleiches gilt für die REFUSED Antwortcode Blockade, denn ein öffentlicher Nameserver, der sich weigert Anfragen für eine Zone anzunehmen kann nur schwer fehlkonfiguriert oder zensierend sein, weil das einer Telefonauskunft entspricht, die bei der Anfrage zur Telefonnummer einer konkreten Person in einer konkreten Stadt, z. B. Karl Ramseier in Rosenheim, einfach nur ohne Begründung antwortet das sie die Anfrage (und alle anderen Anfragen zur Stadt Rosenheim) ablehnt.

Das DNSSEC hat noch den weiteren Vorteil, das damit auch die DNS-typischen Probleme entfallen: Das die DNS(SEC)-Server je nach geographischer Region auf andere IPs verweisen stört beim DNSSEC ebenso wenig wie dynamische IPs und Round Robin IPs, weil beim DNSSEC nicht mit anderen Servern gleicher Art verglichen wird, sondern die Signatur überprüft wird. Dadurch sind die mittels DNSSEC ermittelten Zensurlisten sehr viel zuverlässiger und die DNS-Zensur noch leichter erkennbar: Man muß nicht nach "Stoppschildern" suchen oder mit unzensierten DNS-Servern vergleichen sondern nur überprüfen, ob die DNSSEC-Einträge zum zugehörigen öffentlichen Schlüssel passen; wenn nicht wird die betreffende Domain zensiert und die "Stopschild"-Seiten sind (zumind. überwiegend) diejenigen, auf welche die gefäschlten DNS-Einträge verweisen.

Um zumindest den Großteil der Sperr-Liste und die Liste der "Stoppschild"-Seiten mittels DNSSEC vollautomatisch zu ermitteln reicht es aus eine Liste an verdächtigen Domains zu nehmen, z. B. list2.txt (siehe oben), und zu überprüfen ob der betreffende DNSSEC-Server korrekte Antworten liefert: Ist die Antwort falsch, ist die betreffende Domain auf der Sperr-Liste und die falsche Antwort i. d. R. eine "Stoppschild"-Seite.

Dieses Skript ist noch in Planung, auch weil es bisher (Juli 2009) nur wenige DNSSEC-Server gibt.


Skript zum Suchen nach Stoppschild-Seiten und Nachsehen, was dahinter ist

Die Stoppschild-Seiten zu finden ist auf mehreren Wegen möglich: Man kann beispielsweise die Liste verdächtiger Seiten ( list1.txt, siehe oben) nehmen und für jeden Eintrag prüfen, ob man mit einem zensierten DNS-Server dort ein Stoppschild findet. Einfacher ist aber wohl die Bildersuche mit einer Suchmaschiene. Man kann z. B. einfach nach zu einer bekannten Seite mit dem Stoppschild, z. B. http://rettet-das-internet.de/stoppschilder/bund.png, ähnlichen Seiten suchen lassen. Im Einfachsten Fall ruft man dann die gefundenen Seiten mit einem unzensierten DNS-Server auf, um sich anzeigen zu lassen was jeweils hinter der Stoppschild-Seite ist, aber besser ist vorher zu überprüfen ob sich dort wirklich ein Stoppschild befindet. Dafür kann man neben dem direkten Datei-Vergleich auch das unscharfe Vergleichen von Bildern verwenden.

Dieses Skript ist noch in Planung, auch weil die Bots der betreffenden Suchmaschine zensierte DNS-Server verwenden müssen, damit richtige Stoppschild-Seiten gefunden werden. Da der Google-Bot von den USA aus operiert und damit die deutsche DNS-Zensur nicht sieht, ist die Google-Bildersuche dafür ungeeignet.


Skript zum automatisierten Testen ob eigene Seiten zensiert sind

Mit den eigenen Seiten/Domains gibt es neben der eigentlichen Zensur auch andere Probleme die sich gleich auswirken, wie z. B. die heimliche Umstellung auf fehlkofigurierte Webserver, beispielsweise bei all-inkl.de (zumindest 2006), so das heimlich und plötzlich schon einfache Sachen wie das Downloaden von Dateien mit den simplen Namen LIESMICH, README oder Makefile nicht mehr möglich sind, weil der fehlkonfigurierte Webserver Dateien ohne Infix und Suffix nicht herunter laden läßt.

Gegen solche Fehler und Vertragsbrüche, und auch gegen Zensur allgemein, hilft ein simples Skript das versucht einige Dateien herunter zu laden und testet ob es erfolgreich war. Im Fehler- oder Zensurfall wird man einfach mittels Email benachrichtigt und kann dann Beweise sichern und Klagen oder Anzeigen vorbereiten:
check_servers0.sh.

Damit automatisiert getestet wird, sollte das Skript automatisch ausgeführt werden, z. B. über die /etc/crontab. Man kann aber auch als Workaround in das Skript eine Endlosschleife mit einem Warten von 86400 Sekunden (rd. ein Tag) eintragen.

Update 2009-06-15: Zum Testen der Internet-Verbindung ist das Skript umgestellt von ping auf httping, denn ohne Default-Gateway, z. B. mit einem Dual-Homed Bastion Host, funktioniert ping nicht, während httping ebenso wie das Downloaden funktioniert. Dies ist wichtig, weil mit einem Dual-Homed Bastion Host die Rechner dahinter gegen viele Angriffe wie z. B. DNS-Pinning/DNS rebinding geschützt sind.

Update 2009-06-17: Inzwischen ist auch der direkte Dateivergleich eingebaut. Damit wird jede Form der Zensur erkannt, denn es wird geprüft ob exakt das vom Webserver geliefert wird, was dort abgelegt wurde. Bei den Fehlermeldungen/Mails wird vom Skript entsprechend zwischen nicht herunter ladbaren und gefälschten Dateien unterschieden.

Zur Echtzeit-Überwachung gibt es auf commandlinefu.com ein Skript, das Piept wenn ein Server nicht mehr auf Pings antwortet: http://www.commandlinefu.com/commands/view/1815/beep-when-a-server-goes-offline.
Man kann es auch für Web-Server anpassen, also ping durch httping ersetzen.


Weitere geplante Skripte

Zum Sichtbar machen der Zensurlisten der DNS-Zensur gibt es noch viele andere Wege, die man mit Skripten realisieren kann, denn bei gefälschten Einträgen bei den DNS-Servern (DNS-Zensur) gibt es neben der unterschiedlichen Namensauflösung auch Auffälligkeiten, die ein (mehr oder minder sicheres) Indiz für einen gefälschten Eintrag sind. Der Hauptvorteil durch das Testen dieser Metadaten ist das nur ein DNS-Server benötigt wird; es ist kein Vergleich mit einem anderen nötig!
Dadurch werden nebenbei die unzensierten DNS-Server entlastet.
Dies gilt auch schon beim obigen "Skript zum Sichtbar machen von angeblich geheimen Zensurlisten der DNS-Zensur und zum Auflisten von Stoppschild-Seiten mittels DNSSEC".
Damit wird auch der Versuch, die DNS-Zensur durch das Aufzwingen nur zensierter DNS-Server zu verschleiern, sinnlos.

Das erste Beispiel ist eine TTL-Zeit von 0 Sekunden bei einem nicht gesetzten AA-Flag:
http://www.zdnet.de/bildergalerien_so_funktioniert_die_dns_zensur_bei_deutschen_providern_story-39002384-41500415-11.htm#g.
Allerdings gilt dies wohl nur für das NXR-Modul von Vantio; für die Zensur vom DFN wird eine TTL von 6 Stunden verwendet: http://www.burks.de/dfn_wirtz.pdf.
Die Auswertung der TTL ist daher nicht-trivial.

Das zweite Beispiel ist das Überprüfen ob die DNS-Hirarchie stimmt oder widersprüchlich/gefälscht ist, denn in einer intakten DNS-Hierarchie geben die autoritativen Server der Domain und der nächsthöheren Domain immer die gleichen Nameserver als Antwort, aber zur DNS-Zensur muß die Hirarchie gefälscht werden: http://www.zdnet.de/bildergalerien_so_funktioniert_die_dns_zensur_bei_deutschen_providern_story-39002384-41500415-3.htm#g.
Die Fälschung zeigt sich darin, das sich ein (rekursiver) zensierter DNS-Server betrügerischerweise einfach als autoritativ (zuständig) für eine zensierte Domain ausgibt, weil aus Performancegründen ein Client nicht überprüft, ob das auch stimmt: http://www.zdnet.de/bildergalerien_so_funktioniert_die_dns_zensur_bei_deutschen_providern_story-39002384-41500415-7.htm#g.
Siehe auch http://www.zdnet.de/sicherheit_in_der_praxis_internetzensur_freie_dns_server_schuetzen_vor_falschem_verdacht_story-39001543-41500185-4.htm.

Das dritte Beispiel sind IPs und andere Daten, die ein DNS-Server zu einer Domain angibt: Gehört die IP zu einer bekannten Stoppschild-Seite oder werden die Emails an das BKA umgeleitet ist der Eintrag gefälscht: http://www.zdnet.de/bildergalerien_so_funktioniert_die_dns_zensur_bei_deutschen_providern_story-39002384-41500415-10.htm#g.

Das vierte Beispiel ist DNS Tracing mit einem Programm, das anzeigt woher ein DNS-Server seine Informationen bezieht, beispielsweise dnstracer, das man unter Debian mit einem kurzen "aptitude install dnstracer" installiert. Damit kann man erkennen, ob die Namensauflösung lokal (anhand der Zensurliste(n)) erfolgt oder nicht. Bis auf die wenigen vom betreffenden Provider betreibenen Domains erkennt man die zensierten an der lokalen Namensauflösung.
Man kann auch detaillierter auswerten und die Konsistenz der Liste der DNS-Server vom DNS-Tracing (DNS-Ablaufverfolgung) überprüfen. Allerdings kann dnstracer nicht immer ein DNS-Tracing durchführen, weil es vom Protokoll her nicht vorgesehen ist; dieses Verfahren kann aber muß nicht funktionieren.
Daneben kann man auch die Zeitdauer der Antwort auswerten und so ein zeitliches Tracing durchführen: Dauert die Antwort nicht doppelt so lange wie für die Domain, in der sich der Server befindet, ist sie wahrscheinlich lokal, was aber durch DNS-Caching kein sicheres Indiz für Zensur ist; es ist nur ein schwaches Indiz.

Das fünfte Beispiel ist die Whois-Daten mit den DNS-Daten abzugleichen, denn die DNS-Server/Datenbanken und Whois-Sever/Datenbanken sind unabhängig voneinander. Eine Zensur der DNS-Daten ohne eine gleichlautende Zensur der Whois-Daten läßt sich nachweisen anhand der Nameserver der Domain: Die Server im Abschnitt "Domain servers in listed order:" der whois-Abfrage (per whois) sind ohne Zensur gleich denen im Abschnitt ";; AUTHORITY SECTION:" der DNS-Anfrage (per dig).

Daneben kann man noch weitere Daten der Nameserver auswerten; beispielsweise CNAME (Canonical Name), TXT (Text) und ANY.


Sonstiges

Neben den mit den Skripten implementierbaren Bottom-Up-Möglichkeiten, die oben beschrieben sind, gibt es weitere:

  1. Leakbutton: Ein Button für zensierte Inhalte im Browser, z. B. als Plugin.
    Damit können zensierte Inhalte gemeldet und so geleakt werden. Dazu gehören auch eine Webseite zum Leaken, eine Email-Adresse, an die man mailen kann, eine Nummer an die man SMSen kann usw., und eine vollautomatische Verarbeitung der Meldungen. Da es beim Zensurgesetz ("Zugangserschwerungsgesetz") völlig ausreicht quartalsweise ein paar Stichproben durchzuführen (laut § 9), ist der für Zensurlisten empfohlene Prüfaufwand kleiner als eine Minute pro Monat.
    Realisiert wurde dies bisher nur umgekehrt, indem die gemeldeten URLs auf Zensurlisten gesetzt wurden, die möglichst geheim gehalten werden. Ein Beispiel ist http://www.iwf.org.uk/, wo der Prüfaufwand scheinbar noch geringer ist, wie die Sperrung von Wikipedia Ende 2009 zeigte (http://www.heise.de/newsticker/meldung/Nach-Wikipedia-Sperre-Kritik-an-der-britischen-Internet-Watch-Foundation-189697.html).
    Die IWF zeigt auch wie man den Aufwand auch bezüglich Beschwerden zur Zensur verwendeten Listen gering hält: Es wird nirgends angezeigt, wie jemand etwas gegen eine Zensur (Sperrung) unternehmen kann und auf Beschwerden wird automatisiert geantwortet dass die Beschwerde bereits abgelehnt worden sei.
    Bei Leak-Listen hingegen gibt es diese Probleme nicht, denn damit wird nicht zensiert (gesperrt), sondern im Gegenteil der Streisand-Effekt wirksam. Allerdings gibt es damit das Problem von Spam zur Werbung über geleakte Zensurlisten.

  2. Zensierte Seiten suchen/identifizieren: Beispielsweise kann man über Suchmaschinen nach zensierten Seiten suchen indem man den Seiten sucht, die eine zensierte Seite wie eine "Stop-Seite" anzeigen. Dazu kann man neben der oben beschriebenen Bildersuche nach Stop-Schildern auch nach dem Zensur-Text suchen.
    Ein anderes Beispiels ist eine Liste verdächtiger Seiten zu überprüfen, ob dort angezeigt wird, das sie zensiert werden. Dazu kann man diese Seiten automatisch downloaden, z. B. unverdächtig mittels

    URL=http://whitehouse.gov
    export http_proxy="192.168.1.1:3128"
    export ftp_proxy=$http_proxy
    USER_AGENT=Mozilla/4.0\ \(compatible\;\ MSIE\ 7.0\;\ Windows\ NT\ 6.0\;\ SLCC1\;\ .NET\ CLR\ 2.0.50727\;\ .NET\ CLR\ 3.0.04506\)
    OTHER_WGET_OPTIONS="-v -np -e robots=off -c --cache=off -T 20 --quota=2345M --tries=2 --restrict-file-names=unix --ignore-length --no-passive-ftp"
    wget $OTHER_WGET_OPTIONS --proxy=$PROXY --user-agent="$USER_AGENT" --header="Accept-Encoding: deflate, gzip" $URL

    Anschließend kann man den Inhalt auf Anzeigen von Zensur analysieren; z. B. nach einem typischen Text suchen oder nach für zensierte Seiten typischen Links. Der Aufwand hierfür ist geringe, denn dafür gibt es auch schon einiges an Software: Zum Suchen nach Texten beispielsweise
    grep und für Links das getlinks-Skript aus dem Buch "Raffinierte Shell Scripts", das interne wie auch externe Links aus URLs extrahiert.
    Im einfachsten Fall reicht nach dem Downloaden ein simpler Datei-Vergleich auf Gleichheit und dies ist mittels diff sehr leicht.

  3. Stopp-Seiten zur vereinfachten Erkennung zensierter Seiten nutzen: Wird die DNS-Zensur verwendet um zu einer Stoppseite auf einen Server umzuleiten, halbiert dies den Suchaufwand, weil nur ein Nameserver mit einer Liste abgefragt werden muss, nach dieser Umleitung. Dazu reicht ein Einzeiler wie:

    for i in `cat dkfichse_15012009txt.sorted` ; do dig "$i" | grep 195.141.106.92 >> zensur-ch-sunrise.txt; done

    Die IP 195.141.106.92 ist der Webserver mit der Schweizer Stopp-Seite und der Einzeiler stammt vom https://scusiblog.org/?p=546 .
    Man kann diese Methode leicht auf mehrere Server mit Stoppseiten erweitern. Eine Liste solcher Server findet man unter https://scusiblog.org/?p=976 .


Sitemap