Alles begann mit der Verordnung Nr. 733/2002 vom 22. April 2002. Verordnet wurde

[...] gestützt auf den Vertrag zur Gründung der Europäischen Gemeinschaft, insbesondere auf Artikel 156, auf Vorschlag der Kommission (1), nach Stellungnahme des Wirtschafts- und Sozialausschusses (2), nach Anhörung des Ausschusses der Regionen, gemäß dem Verfahren des Artikels 251 des Vertrags (3), in Erwägung nachstehender Gründe [...]

zur Förderung des elektronischen Geschäftsverkehrs und der Interoperabilität der transeuropäischen Netze die Konnektierung der

Domäne oberster Stufe „.eu“

Ein schöner Beitrag zur europäischen Identitätsstiftung. Als Vorsilbe steht eu seit der Anike für das Gute und Schöne, so wie in Euphemismus und Evangelium. Als Domainendung steht .eu für europäische Identität und Überregionalität, ja für Demokratie und Humanismus, und natürlich für internationalen Güterverkehr und Reisebusunternehmen.

Der Start war jedoch schwierig, denn es gab viel schlechte Presse. Der Landrush geriet zum Fiasko, da man versäumt hatte, zu verhindern, dass sich Registrare hundertfach akkredieren konnten, um den Kuchen auf ganz uneuropäische Art unter sich aufzuteilen. Auch technisch lief es nicht rund. Es folgten Skandale wie die Sache mit der Zypern-Connection und andere Fälle, wo Zehntausende von Namen als Spekulationsobjekt wegregistriert wurden, bis schließlich ein viel zu großer Teil der Zone nur noch auf Parkingseiten routete und die schöne TLD in Verruf kam.

Obwohl man sich bei der Registry EURid doch eigentlich große Mühe gegeben hatte, alles ganz genau richtig zu machen. Es ist ja schon komisch: bei den Briten laufen die Transfers im Linksverkehr, eine russische Domain kann man nur transferieren, wenn die ganze "Familie" mitkommt, die Deutschen konstruierten sich gleich ein eigenes Registrierungsprotokoll und die Europäer – als wollten sie sämtliche Klischees von bürokratischer Ineffizienz und Überregulierung auf das Domainreglement abbilden – erfanden das intransparenteste und umständlichste Verfahren zum Provider- und Inhaberwechsel, das einem als Registrar so unterkommt.

Dies jedoch sei hier nur für die Annalen der Internetgeschichte festgehalten, denn nun ist alles anders geworden. Am 21. November 2012 ging die Registry für 3 Stunden auf Tauchstation, und erstarkte planmäßig um 9:00 Uhr CET wie Phönix aus der Asche im frischen Gewand eines aufgeräumten und übersichtlichen Regulariums über den transeuropäischen Netzen.

• Inhaberwechsel
  • Früher:
    Alter und neuer Inhaber mussten den Vorgang mit Captcha und Verifikationscode auf einer Webseite der Registry bestätigen. Inhaberwechsel (bzw. Namensänderung ohne hinreichenden Identitätsnachweis) zog einen Neustart der Laufzeit nach sich.
  • Heute:
    Der Registrar nimmt im Auftrag des Kunden einen Inhaberwechsel vor, ohne dass sich Laufzeit oder der Status der Domain ändert.
• Transfer ohne Inhaberwechsel
  • Früher:
    Der neue Registrar beantragte im Auftrag des Kunden bei der Registry die Übernahme der Domain unter Angabe der Inhaberdaten. Der Domaininhaber musste den Transfer auf einer Webseite der Registry bestätigen. Die Registry behilelt sich jedoch vor, aufgrund einer undurchsichtigen Plausibilitätsprüfung zu entscheiden, ob neue und alte Inhaberdaten die gleiche natürliche oder juristische Person bezeichneten, so dass ggf. der Transfer abgelehnt wurde, weil gleichzeitig auch ein Inhaberwechsel zu beantragen war.
  • Heute:
    Der Inhaber beantragt über den abgebenden Registrar (oder, falls dies nicht möglich ist, direkt über die Registry) einen Authorisierungscode für seine Domain. Den Authorisierungscode übergibt er dem neuen Registrar, der damit den Transfer sofort durchführen kann.
• Transfer mit Inhaberwechsel
  • Früher:
    Der neue Registrar beantragte im Auftrag des Kunden bei der Registry die Übernahme der Domain unter Angabe der neuen Inhaberdaten mit einer speziellen Auftragsart, die nur für diese Registry und nur für diesen Fall vorgesehen war. Alter und neuer Inhaber musste den Transfer auf einer Webseite der Registry bestätigen.
  • Heute:
    Der Inhaber beantragt über den abgebenden Registrar einen Authorisierungscode für seine Domain, übergibt diesen an den neuen Inhaber, der ihn an den neuen Registrar weiterreicht, der damit den Transfer sofort durchführen kann.

Die gutgemeinte Intention des alten Systems lag sicherlich darin, dass man höchsten Wert auf den Schutz des Eigentumsrechts des Domaininhabers legen wollte. Aus den alten Regeln spricht ein grundsätzliches Misstrauen gegenüber den Registraren (was natürlich irgendwo auch berechtigt ist, wenn man, wie wir beim Landrush gesehen haben, praktisch jeder hergelaufenen Briefkastenfirma eine Akkreditierung erteilt). Damit hatte man jedoch den Ausnahmefall, also die böswillige oder versehentliche Übertragung einer Domain oder die Nichterreichbarkeit oder Unwilligkeit eines Registrars, zur Grundlage des täglichen Geschäfts gemacht und die asynchronen Bestätigungs- und Einwilligungsprozesse kosteten alle Beteiligten Zeit, Geld und Nerven. Nun ist man dem modernen Trend gefolgt, die Wahrung des Eigentumsrechts an den Domainnamen zu dezentralisieren und den Ausnahmefall als Ausnahme zu behandeln und nicht als Regel.

Das neue Transfer-Verfahren von EURid übertrifft an Stromlinienförmigkeit auch den Transferprocess der DENIC, der zwar auch ein Segen im Vergleich zum früheren de-Procedere ist, aber in seinen Feinheiten ja doch auch wieder etwas intellektuell überfrachtet geraten ist. Denn während bei DENIC der Authorisierungscode (AuthInfo1) durch den Registrar erstellt und verwaltet wird und ein Hashwert bei der Registry zu hinterlegen ist, die ihn wiederum später unter verschiedenen Umständen für ungültig erklären kann, wird der EURid-Authorisierungscode von vorne herein nur durch die Registry verwaltet. Das Leben des Informatikers wird so viel einfacher, wenn man sich mal für einen einzigen Ort entscheidet, an dem ein Datum vorgehalten wird, so dass sich komplizierte Synchronisierungsverfahren vermeiden lassen.

Der Registrar hat zu gewährleisten, dass im Auftrag des Domaininhabers ein Authorisierungscode erzeugt werden kann. Dieser gilt dann 40 Tage oder bis zu seiner Benutzung, wobei die Registry bei erneuter Anfrage innerhalb von 24 Stunden einfach den gleichen Code ausgibt und ansonsten einen neuen 40-Tage-Code generiert. Somit besteht seitens des Registrars weder eine Notwendigkeit, den Authorisierungscode zu speichern noch das Ablaufdatum zu verwalten. Chapeau!

Bei dieser Gelegenheit hat auch mal jemand ausgerechnet, dass die Sicherheit eines Codes der Form

XXXX-AAAA-BBBB-CCCC

hierfür absolut ausreichend ist (XXXX ist eine Konstante für den Registrar). Das kann man sich ohne Weiteres auch auf einen Zettel schreiben oder am Telefon durchgeben, ohne dass man sich das Leben mit Groß- und Kleinschreibung und Sonderzeichenregeln erschweren muss.