German Privacy Foundation
09. December 2024HTTPS-DNS wurde 2009 als Abwehrmaßnahme gegen die damals geplante DNS-Zensur entwickelt. Dabei tunnelt eine Client-Software die DNS-Abfragen über HTTPS von einem HTTPS-DNS-Server.
Sowohl der Server als auch die Client-Software sind prinzipiell funktionsfähig, befinden sich aber in einem Alpha-Stadium. Da eine reine DNS-Zensur zumindest in Deutschland nicht mehr zu erwarten ist, findet z.Zt. keine Weiterentwicklung statt.
Zur Dokumentation stellen wir hier weiterhin alle Informationen zur Verfügung. Es wird aber kein Support mehr für HTTPS-DNS seitens der GPF geleistet. Auch ist zu erwarten, daß in Zukunft nicht mehr alle hier genannten HTTPS-DNS-Server aktiv sein werden.
Die Zensur-Provider könnten den DNS-Traffic zu alternativen Servern blockieren oder auf die eigenen kompromittierten DNS-Server umlenken. Möglicherweise ist dieses Angriffs-Szenario bereits in Vorbereitung. Vodafone leitet bereits seit Juli 09 im UMTS-Netz DNS-Anfragen auf die eigenen, zukünftig zensierten Server um. Im DFN Forschungsnetz soll die Nutzung unzensierter DNS-Server durch Sperrung des Port 53 unterbunden werden (im Wiki des AK Zensur gibt es die Dokumente).
Das am 18.05.2009 vom Deutschen Bundestag verabschiedete "Gesetz zur Bekämpfung der Kinderpornografie in Kommunikationsnetzen" (Zugangserschwerungsgesetz) ist technik-offen formuliert. Es sieht vor, dass die DSL-Zugangsprovider alle nötigen Maßnahmen zur effektiven Sperrung von Websites umzusetzen haben, die das BKA ohne juristische Kontrolle auf eine Sperrliste setzt. Eine einfache Manipulation der DNS-Server, die man mit hunderten Anleitungen aus dem Netz in 27 Sekunden umgehen kann, ist sicher keine effektive Sperrung im Sinne des Gesetzes.
(Bemerkung: Eine mindestens vierteljährliche, stichprobenartige Überprüfung der Sperrliste durch ein zahnloses Gremium sehen wir nicht als rechtsstaatliche Überprüfung an, welche die notwendige Gewaltenteilung in einer Demokratie gewährleistet.)
Der DNS-Traffic wird über eine HTTPS-verschlüsselte Verbindung zu unzensierten DNS-Servern geleitet. Eine großflächige Kompromittierung der HTTPS-Verschlüsselung ist sicher nicht durchsetzbar. Die gesamte kommerzielle Nutzung des Internet wäre betroffen.
Eine Sperrung des Dienstes ist nur durch Sperrung des gesamten Webangebotes des HTTPS-Servers realisierbar. Nach der aktuellen Gesetzeslage dürfte es dafür keine juristische Handhabe geben, solange der Inhalt des Webangebotes nicht gegen geltendes Recht verstößt.
Ziel des Projektes ist es lediglich, eine unzensierte, schnelle Abfrage von DNS-Namen zu ermöglichen. Im Gegensatz zur Nutzung von Anonymisierungsdiensten erfolgt keine Verschlüsselung von Inhalten. Das Projekt ist als niedrigschwellige Ergänzung zu Anonymisierungsdiensten gedacht, nicht als Konkurrenz.
Eine erste Version ist in dem Tar-Archiv https-dns-client-v0.2.4.8.tar.gz (Signatur) enthalten. Diese Version ist für einen ersten Eindruck gedacht. Prinzipiell funktioniert die Software schon ganz gut. Sie ist in Perl implementiert, nutzt einige Perl-Module vom CPAN, ist jedoch wenig performant, da sie single-threaded arbeitet und Möglichkeiten von HTTP1.1 nicht nutzt. Außerdem werden die SSL-Zertifikate der HTTPS-DNS-Server noch nicht validiert. Es gibt viele Verbesserungsmöglichkeiten. Installation ist in der README beschrieben.
Folgende Perl-Module werden benötigt: Log::Log4perl, Net::Server::Daemonize, Net::SSLeay, XML::Simple, Net::DNS, Net::DNS::Nameserver
Der Daemon lauscht per Default an Port 1053. Wir empfehlen, einen DNS Cache Daemon zusammen mit HTTPS-DNS zu nutzen, um die Performance zu erhöhen und die Server zu entlasten. bind9 oder pdnsd können genutzt werden. Diese Daemons nehmen an Port 53 die DNS-Anfragen entgegen und leiten sie an Port 1053 weiter, wenn sie nicht aus dem Cache beantwortet werden können. Beispiele für die Konfiguration der beiden Daemons sind im Paket im Unterverzeichnis misc enthalten.
Eine angepasste Version des Linux-Clients kann hier als Installationspaket für Mac OS X ab 10.5 Leopard heruntergeladen werden: mirror.dotplex.de/gpf/
Nach der Installation muß nur noch in den Systemeinstellungen unter "Netzwerk" als DNS-Server 127.0.0.1 eingetragen werden.
Es ist möglich, die vorhandenen Server via Webbrowser abzufragen. Die Abfrage kann mit der IP-Adresse der Web-Server erfolgen (so werden es die HTPPS-DNS-Clients später tun) oder mit der URL des Webservers, um SSL-Zertifikatsfehler zu vermeiden. Es ist möglich, die folgenden Parameter der Anfrage an das Script zur übergeben:
Einfachstes Beispiel für query: Abfrage der IP-Adresse des Rechners privacyfoundation.de:
https://privacybox.de/cgi-bin/dns2.fcgi?query=privacyfoundation.de&answer=human
Beispiel für Abfrage des record MX:
https://privacybox.de/cgi-bin/dns2.fcgi?record=MX&query=privacyfoundation.de&answer=human
Standardmäßig wird die Internet Class (IN) abgefragt. Um andere DNS classes abzufragen, ist zusätzlch der Parameter "class" möglich. Dabei werden folgende DNS classes unterstützt: IN (default), CH (chaos class), HS (hesiod class) oder ANY.
Wird statt eines Rechnernamens eine IP-Adresse für den Parameter "query" übergeben, erfolgt standardmäßig die Ermittlung des Reverse-DNS. Der Parameter "record=ptr" kann ebenfalls entfallen.
Derzeit sind 6 Server für HTTPS-DNS verfügbar:
Beispiel für Antwort als xml (?answer=xml&query=privacybox.de)
<httpsdns>
<result>
<name>privacybox.de</name>
94.75.228.29
<class>IN</class>
<rdlength>4</rdlength>
<ttl>42444</ttl>
<type>A</type>
</result>
</httpsdns>
Beispiel für Antwort als xmlattr (?answer=xmlattr&record=mx&query=privacybox.de). Die Antwort ist in die einzelnen Zeilen zu zerlegen. Die Zeilen können als XML-Dokumente behandelt werden.
<result name="privacybox.de" class="IN" exchange="mx.dotplex.de" preference="10" rdlength="15" ttl="43200" type="MX"/>
<result name="privacybox.de" class="IN" exchange="mx2.dotplex.de" preference="20" rdlength="8" ttl="43200" type="MX"/>
Unser Ziel ist es, vorhandene und ausgereifte Software zu nutzen. Diese soll lediglich um eine kleine Komponente ergänzt werden.
Vorraussetzungen für einen HTTPS-DNS-Server:
Der Server muss eine unzensierte Auflösung von DNS-Namen gewährleisten.
Es wird ein Webserver benötigt, der HTTPS und Perl-CGI-Scripte unterstützt.
Die erste Alpha-Version ist ein einfaches Perl-CGI-Script. Es werden die Perl-Module CGI, Data::Validate::Domain, XML::Simple, HTML::Template, Net::DNS und Net::DNS::Resolver::Programmable benötigt. Debian bietet alles Nötige in fertigen Paketen, die mit aptitude installiert werden können.
aptitude install libnet-dns-perl libxml-simple-perl libhtml-template-perl libdata-validate-domain-perl libnet-dns-resolver-programmable-perl
Wer einen solchen Server bereitstellen kann, findet das kleine CGI-Script dns2.pl im Archiv https-dns-server.tar.gz. Es sind die nötigen Perl-Module zu installieren, die HTML-Template Seite kann angepasst werden und in dem Script dns2.pl ist der Path zum Template anzupassen (Zeile 11).
Das Script kann alle Standard-Records zur Auflösung an den DNS-Nameserver weiterreichen: A AAAA AFSDB CERT CNAME DHCID DLV DNAME DNSKEY DS HIP IPSECKEY KEY LOC NAPTR NS NSEC NSEC3 MX NSEC3PARAM SRV PTR RRSIG SIG SOA SPF SSHFP TA TXT. Es bietet eine Build-In Domain für einfache Tests. Für die Domian "welcome.httpsdns" wird die IP-Adresse 85.25.251.247 geliefert. Beim Aufruf im Webbrowser sieht man die Welcome-Seite für einige unzensierte DNS-Server.
Die HTML-Template-Seite benötigt die folgende Variablendefinition. Die Variable TABELLE enhält die Parameter der Antwort als <table>.
<TMPL_VAR NAME=TABELLE>
Das Archiv https-dns-server.tar.gz enthält auch ein Fast-CGI-Script dns2.fcgi. Dieses Script ist performanter als die einfache CGI-Version. Um es zu nutzen benötigt der Webserver das passende FCGI-Modul und das Perl-Modul Fast:CGI ist zu installieren. Für Debian + Apache kann man alles nötige via aptitude installieren:
aptitude install libapache2-mod-fcgid libcgi-fast-perl
Anschließend ist die Datei /etc/apache2/mods-enabled/fcgi.conf zu editieren und die folgende Zeile ist hinzu zu fügen:
AppClass /path/to/dns2.fcgi -processes 3
Nach einem Restart des Webservers sollte alles funktionieren:
invoke-rc.d apache2 restart