Seit geraumer Zeit bietet DeNIC die Möglichkeit, für Glue Records IPv6-Adressen anzugeben.

Glue Records bieten die Möglichkeit, Nameserver-Adressen unter der eigenen Domain zu verwenden. Beispielsweise also ns1.tech-nerds.de und ns2.tech-nerds für die Domain tech-nerds.de. Damit diese Ausflösung funktioniert, müssen neben den Namen der Nameserver natürlich auch deren IP-Adressen bekannt sein. Diese in IP-Version 4 mit anzugeben, ist praktisch bei jedem Registrar möglich. Um Seiten gänzlich per IPv6 erreichbar zu machen, ist es natürlich erforderlich, dass auch Glue Records nicht mehr nur per IPv4 angegeben werden. DeNIC erfordert zwar weiterhin die zwangsweise Angabe einer IPv4-Adresse für Glue Records, aber diese können durchaus durch IPv6-Adressen ergänzt werden. Bei der DeNIC selbst ist bisher ein einziger Nameserver für die Zone de. IPv6-fähig. Genau genommen der letzte im Bunde:
f.nic.de 2a02:568:0:2::53


Mein Domain-Hoster war nun so freundlich, diese Einträge für meine Nameserver manuell vorzunehmen (automatisiert geht es dort noch nicht). Somit sind meine Seiten auch komplett IPv4-frei zu erreichen.

; <<>> DiG 9.7.3 <<>> tech-nerds.de @f.nic.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14810
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;tech-nerds.de. IN A

;; AUTHORITY SECTION:
tech-nerds.de. 86400 IN NS ns1.tech-nerds.de.
tech-nerds.de. 86400 IN NS ns2.tech-nerds.de.

;; ADDITIONAL SECTION:
ns1.tech-nerds.de. 86400 IN A 87.98.178.251
ns1.tech-nerds.de. 86400 IN AAAA 2001:41d0:2:4887::d1
ns2.tech-nerds.de. 86400 IN A 85.183.2.9
ns2.tech-nerds.de. 86400 IN AAAA 2001:6f8:11ea:1337::deed

;; Query time: 13 msec
;; SERVER: 2a02:568:0:2::53#53(2a02:568:0:2::53)
;; WHEN: Sat Feb 4 23:11:10 2012
;; MSG SIZE rcvd: 155

Daran kann sich der Rest des Internet doch mal ein Beispiel nehmen.

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.