Da die Verwendung von DNSSEC für die Root-Zone ja momentan heiß diskutiert wird, habe ich mir mal angesehen, wie ich denn meinem DNS-Resolver (BIND9) DNSSEC beibringe.

DNSSEC funktioniert, um es mal ganz grob zu umschreiben, mit zwei Schlüsselpaaren. Einem zone-signing-keypair (ZSK) und einem key-signing-keypair (KSK). Hiervon wird jeweils der öffentliche Schlüssel dem Resolver (aka Client) bekannt gemacht, indem dieser in das Zonefile auf einem DNS-Master integriert wird (hierzu später mehr).

Um das Ganze dann auch wirklich sicher zu machen, wird vom DNS-Resolver die trust-chain in der DNS-Hierarchie "nach oben" aufgelöst. So sucht der Resolver beim Auflösen einer DE-Domain nach den Schlüsseln für die Zone DE und danach für die Root-Zone "."

Klingt erstmal schlüssig. Nur sind weder DE-, noch Root-Zone mit entsprechenden Schlüsselpaaren signiert. Bis jetzt sind dies nur eine handvoll TLDs. Darunter .se, .pl, .gov, .museum und einige weitere. Um dennoch eine trust-chain zu schaffen, gibt es DLV (DNSSEC lookaside validation). Geht es in der normalen DNS-Hierarchie mit der trust-chain nicht weiter, versucht der DNS-Resolver per DLV einen trust-anchor zu finden.

In BIND9 (ab Version 9.3.3) wird das Ganze dann folgendermaßen implementiert (Dateinamen entsprechen Debian-Standardkonfiguration):

Zunächst den public key der ISC herunterladen, ggf. per wget. Ich habe diesen Key dann übersichtshalber in die Datei /etc/bind/named.conf.keys gespeichert. In der /etc/bind/named.conf.options werden dann folgende Zeilen hinzugefügt:
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside . trust-anchor dlv.isc.org.;

Natürlich muss dem BIND noch der public key der ISC bekannt gemacht werden. Und zwar durch folgende Zeile in der /etc/bind/named.conf:
include "/etc/namedb/named.conf.keys";

Nach einem BIND-restart kann nun per dig +dnssec iks-jena.de soa, bzw. dig iks-jena.de soa getestet werden, ob der Resolver DNSSEC spricht. Wird dig die Option +dnssec mitgegeben, sollten RRSIG-resource records ausgegeben werden.

Auf dem Easterhegg war heute ein interessanter Ansatz zum Umgehen der Vorratsdatenspeicherung zu erfahren.

Ziel dabei ist das Originieren des Internet-Traffics im nicht-EU Ausland, in dem es keine Vorratsdatenspeicherung gibt. Die Verbindung zum Server im Ausland geschieht dabei über einen VPN-Tunnel.

Nachzulesen ist diese Lösung, die sich im Rahmen der eigenen Kreativität sicherlich noch erweitern und verbessern lässt, auf der Homepage von Dan, der den Vortrag auf dem Easterhegg gehalten hat.

Es ist schon länger bekannt, dass Google unter der URL ipv6.google.com per IPv6 erreichbar ist.

Weniger bekannt ist den meisten wahrscheinlich, dass Google es Providern auf Anfrage gestattet, mehrere Subdomains von google.com – darunter auch www – mit AAAA-Resource Records, sprich: IPv6-Adressen, aufzulösen. Dies ist u.a. auf den Nameservern des Tunnel Brokers SixXS der Fall.

Für alle, die nicht die Nameserver von SixXS nutzen wollen, oder können, da diese ja nur den Benutzern jenes Providers zur Verfügung steht, hier alle Namen-Adressen Paare, die ich durch Ausprobieren auftreiben konnte; fertig für die /etc/hosts

• 2001:4860:a003::68    www.google.com
• 2001:4860:a003::68    www.l.google.com
• 2001:4860:a005::68    maps.google.com
• 2001:4860:a003::68    news.google.com
• 2001:4860:a003::68    blogsearch.google.com
• 2001:4860:a003::53    mail.google.com
• 2001:4860:a005::64    docs.google.com
• 2001:4860:a003::68    picasa.google.com
• 2001:4860:a005::88    picasaweb.google.com