Inzwischen fehlt auch der A-Record. NS- und SOA-Records sind (zumindest bisher) noch auflösbar.

Wie schon zu vernehmen war, basiert ENUM also auf DNS. Genau genommen auf der arpa-Zone e164.arpa. Unter dieser werden, wie beim RDNS, ENUM-Zonen aus dem E164-Dialplan der ITU vergeben. Dabei verwaltet eine Oranisation in jedem Land (bzw. in den teilnehmenden) die Zone mit der internationalen Vorwahl. In Deutschland ist dies die DeNIC mit der Zone 4.9.e164.arpa. Unter dieser können dann die eindeutigen Zonen registriert werden, welche aus einer vollständigen, internationen Rufnummer (E164) bestehen. Auch Sonderrufnummern sind zulässig. Eine ENUM-Zone kann also z.B. 0.0.0.0.0.9.1.1.0.4.9.4.e164.arpa. lauten, wobei dies eine fiktive Rufnummer im Hamburger Ortsnetz (40) ist.

Bei einem Lookup auf diese Zone kann ein Endgerät (z.B. VoIP-Telefon/Asterisk-Server) dann anhand der angegebenen Prioritäten, unter Berücksichtigung der eigenen Fähigkeiten, entscheiden, welches Ziel angewählt wird.

Hier eine Beispiel-Zonendatei für die oben genannte Rufnummer.

0.0.0.0.0.9.1.1.0.4.9.4.e164.arpa.  IN SOA ns1.example.com.
hostmaster.example.com.

(2010053000  10000 3600 604800 1800)
@  IN NS ns1.example.com.
@  IN NS ns2.example.com.

@  IN NAPTR 10 10 "u" "E2U+tel" "!^.*$!tel:+494911900000!" .
@  IN NAPTR 10 20 "u" "E2U+sip" "!^.*$!sip:+user1@example.com!" .

Update:
Inzwischen hat Portunity meine Name-Server übernommen. Ich hatte nicht bedacht, dass ja auch eine openeum.eu-Zone benötigt wird.

Wer über einen Resolver verfügt, der den Algorithmus RSASHA256 beherrscht (Unbound ab 1.4 oder BIND ab 9.7), kann die beiden DNSSEC-Nameserver der DeNIC in Frankfurt und Amsterdam nutzen. Der Server in Frankfurt kann dabei auch IPv6. Konfigurationsbeispiele für BIND und Unbound sind auf der DeNIC-Seite angegeben.

Eigene de-Domains lassen sich natürlich auch signieren. Damit die Chain-of-Trust (im Idealfall sieht die folgendermaßen aus: . (Root-Zone) -> de. -> example.de.) vollständig ist, muss aber der öffentliche Teil des Schlüssels bei der DeNIC hinterlegt werden und hier spielen bisher leider nur wenige Provider mit. Mir ist aktuell nur Hostserver bekannt, der auch die Registration der Domain tech-nerds-dnssec.de übernommen hat. Die Domain ist selbstverständlich signiert und eignet sich so auch, um den eigenen Resolver zu testen. Das geht in gewohnter Weise mit dem Tool dig.
dig +dnssec tech-nerds-dnssec.de

Wenn dig hier das Flag ad ausgibt, konnte die Antwort erfolgreich authentifiziert werden.

Wie auf root-dnssec.org zu lesen ist, ist die Terminverschiebung notwendig geworden, um ICANN und VeriSign (den Betreibern der signierten Root-Zone und der genannten Seite) mehr Zeit zu geben, die Sicherheit und Stablilität der DNSSEC-Implementierung zu geben.

Bereits seit 1. Dezember 2009 ist die Root-Zone signiert, liefert aber keine validierbaren Daten. Am 5. Mai 2010 wurde dann der letzte Root-Server mit DNSSEC ausgestattet.

Inzwischen hat DeNIC dieses Verhalten offenbar geändert.

Da die Domains auf dem SOA-Server korrekt aufgelöst wurden, die DeNIC-Server aber NXDOMAIN zurück lieferten, war relativ schnell klar, dass das Problem bei DeNIC selbst liegen musste. Auf Anfrage hat DeNIC das Problem bestätigt.

Ein wenig verwundert war ich, dass Heise nichts dazu wusste. Golem.de wusste zumindest um 14:21 etwas.

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: 32870
;; 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 ns2.tech-nerds.de.
tech-nerds.de. 86400 IN NS ns1.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: 20 msec
;; SERVER: 2a02:568:0:2::53#53(2a02:568:0:2::53)
;; WHEN: Sat Feb 4 23:05:59 2012
;; MSG SIZE rcvd: 155

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

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.