Technik löst nicht Politikproblem der IANA

Die Automatisierungsideen für die Internet Assigned Numbers Authority (IANA) lösen bestehende Probleme beim Management der zentralen Rootzone im Internet-Namenssystem nicht. Am Rande des Treffens der Internet Engineering Task Force (IETF) in Paris hatte der Council of European National TLD Registries (Centr) zu einem so genannten Bird of Feathers-Treffen (BOF) geladen, bei dem Bill Manning von ep.net, einer der 13 Rootserverbetreiber, ein Web-basiertes System für das Update von Nameserver- oder Gluerecord-Änderungen in nationalen TLD-Zonen vorstellte. Das Konzept einer "Client Authenticated DNS Request" (CADR) soll den Managern von Länderzonen wie .de erlauben, Änderungen innerhalb ihrer DNS-Zonen so einzuspeisen, dass IANA per Knopfdruck den notwendigen Eintrag in der zentralen Rootzone generieren kann.

"Wenn ein 'Kind' -- alle Länderzonen sind aus Sicht der Root Kinder -- Änderungen in seiner Zone vornimmt und diese mit DNSSEC-Schlüsseln signiert, kann das Elternteil die Änderungen akzeptieren, wenn es den verwendeten Schlüsseln traut", beschreibt Manning die Funktionsweise. Dabei müsse auch nicht zwingend die gesamte Zone DNSSEC-signiert sein, sondern nur die für die Updates notwendigen Informationen. Mannings ep.net hat zur Erprobung des Clients ein Live-System aufgeschaltet, das völlig unabhängig von IANAs Produktionsprozess als "Sandkasten" für die Ingenieure dienen soll. Länderdomainmanager, die das System erproben und auch weiterentwickeln wollen, seien willkommen, so Manning. Vor dem ersten Login müssen sie die Spielregeln unterschreiben. Denkbar sei, dass neben den Nameserver-Änderungen auch andere Updates der Länderzonen über den Web-Client initiiert werden.

Steve Crocker, Chef des Sicherheitskomitees der Internet Corporation for Assigned Names and Numbers (ICANN), der die IANA-Aufgaben einverleibt wurden, sagte in Paris: "Ich habe keine klare Vorstellung von dem Problem, für das hier eine Lösung präsentiert wird. Ich sehe das Problem nicht." Das aber können die Manager kleinerer Länderdomains sehr wohl beschreiben. "Wir warten manchmal vier oder sechs Monate, bis die Änderung eines Nameservers durch ist", sagte Alex Mayrhofer von der Nic.at. Die Schwerfälligkeit der IANA bei Änderungen wurde in Europa zuletzt besonders heftig nach der KPM-Qwest-Pleite diskutiert, während der rasche Updates erforderlich gewesen wären, um die abgeschalteten Nameserver zu ersetzten.

Beim Treffen in Luxemburg lieferten sich IANA-Manager Doug Barton und der Verwalter der namibischen Länderdomain Eberhard Lisse eine kleine Schlacht darum, warum IANA mehrere Monate für eine technisch notwendige Nameserver-Änderungen gebraucht hat. Warum für derartige Änderungen so viel Zeit benötigt wird, ist nach wie vor völlig unklar. Doch dass ICANN bewusst ist, dass bei IANA nicht alles zum Besten steht, zeigt nicht zuletzt ICANNs Ankündigung, dass Barton sofort nach dem Treffen in Luxemburg seinen IANA-Sessel räumen werde.

Trotz des offensichtlichen Handlungsbedarfs äußerten sich Vertreter verschiedener Länderzonen, darunter der .de, .fr, .at, in Paris allerdings skeptisch über den vorgestellten Client. "Warum", so Peter Koch von der Denic eG, "ist die Bestätigung der Nameserver-Änderungen durch IANA noch notwendig?" Der gesamte Prozess auf IANA-Seite bleibt von dem System unberührt, wenn mit der Automatisierung nicht rein technische Kompetenzen stärker dezentralisiert werden. Stephane Bortzmeyer von der französischen Registry Afnic meint, damit bliebe es dabei, dass Änderungen nach wie vor vom US-Handelsministerium abgesegnet werden müssen. Das eigentliche Problem sei in erster Linie ein Politikproblem, so Bortzmeyer. Allerdings plant Centr im Verlauf der Tests auch eine Analyse der Abläufe bei IANA, versprach Kim Davies von Centr. Centr-Chef Paul Kane hatte in Luxemburg durchaus die Möglichkeit in den Raum gestellt, dass im Rahmen der Automatisierung der IANA rein technische Änderungen völlig unabhängig von ICANN und IANA vorgenommen werden können. (Monika Ermert) / (anw)