.at-Domainvergabe goes Real-Time

von Gerhard Winkler (Ausgabe 07/2, Juni 2007)

 

Ein Blick hinter die Kulissen

Wann immer Sie eine Verbindung zu einem Server einer bestimmten Domain (z.B. univie.ac.at) aufbauen, muss Ihr Rechner zuerst herausfinden, unter welcher IP-Adresse dieser Server erreichbar ist. Dazu bedient er sich des Do­main Name Service (DNS), einer weltweit verteilten, hierarchisch aufgebauten Datenbasis, die sich auf die Einträge in den jeweiligen Registrierungsdatenbanken stützt, wo Infor­mationen zu allen offiziell registrierten Domains verzeich­net sind: einerseits organisatorische Informationen wie der Inhaber einer Domain und seine Kontaktdaten, andererseits technische Informationen wie z.B. die Daten der Nameser­ver, auf denen die Domain betrieben wird.

Registries und Registrare ...

Domains unterhalb einer nationalen Toplevel-Domain (wie .at für Österreich) werden von nationalen Registrie­rungs­stellen (Registries) vergeben bzw. verwaltet. Um eine Do­main zu erwerben, muss man seinen Antrag aber nicht unbedingt direkt an die jeweilige Registry senden - es besteht auch die Möglichkeit, die Dienste ihrer "Vertriebspartner" in Anspruch zu nehmen. Diese so genann­ten Registrare sind Firmen mit unterschiedlichen Produk­ten und Leistungsan­geboten, die aber jedenfalls auch im Auftrag ihrer Kunden Domainregistrierungen bei der Registry abwickeln.

... und ihr Umgang miteinander

Eine Domain kann unter Umständen einen beachtlichen Wert darstellen, daher spielt bei der Domainvergabe die feh­lerfreie und rasche elektronische Kommunikation zwischen Registraren und Registry eine wesentliche Rolle. Die klassische Variante hiervon ist eine formalisierte Abwicklung via eMail: Der Registrar sendet eine eMail-Nachricht mit dem "An­tragsformular" an die Registry und erhält die automatisch generierte Antwort (ob die Registrierung positiv erledigt wurde oder nicht bzw. welcher Fehler aufgetreten ist) ebenfalls per eMail. Auf dieselbe Weise werden auch viele andere Transaktionen wie das Aktualisieren und Löschen von Domaindaten oder der Wechsel eines Kunden von einem Registrar zu einem anderen abgehandelt.

Der Nachteil ist klar erkennbar: Auch wenn eine eMail-Nachricht im Allgemeinen innerhalb weniger Minuten zu­gestellt wird, ist das in Zeiten von Webshopping für einen Geschäftsablauf zu lang; außerdem kann es über eMail keine unmittelbare Antwort auf ein Transaktionskommando geben. Die Implementierung einer geeigneten Client-Soft­ware für Registry und Registrare (die sich ja immer den entsprechenden Status einer Transaktion "merken" muss) ist zudem relativ aufwendig. Aus diesen Gründen wurde für die elektronische Kommunikation zwischen Registries und Registra­ren ein eigenes Netzwerkprotokoll entwickelt, das Extensible Provisioning Protocol (EPP).

EPP: Erweitert Passt?s Perfekt

EPP wurde als Internet-Standard eingeführt1) und bedient sich der eXtensible Markup Language (XML) zur Definition der Datenstruktur sowie einer permanent bestehenden Da­ten­verbin­dung zwischen Client und Server, auf der Anfra­gen und Ant­wor­ten synchron ausgetauscht werden.

Eine wesentliche Anforderung bei der Entwicklung von EPP war, dass es erweiterbar sein muss, um unterschied­liche Rahmenbedingungen abbilden zu können: Die Ver­gaberegeln jeder Registry sind geprägt durch ein nationales Umfeld aus Gesetzen und Vergabeprinzipien (etwa zum Schutz der Interessen der Domain-Inhaber) sowie durch Wünsche und Forderungen von Registraren und Internet-Community. Die Folge davon ist, dass die Vergaberegeln von Land zu Land mitunter stark differieren. Viele Registrare sind aber international tätig und infolgedessen mit unterschiedlichen Ver­gaberegeln (und somit auch unterschied­lichen Geschäftsprozessen und Datenanforderungen) konfrontiert - die leider auch kaum geändert werden können, weil auf eine Unmenge von historischen Daten und Ver­tragsverhältnissen Rück­sicht genommen werden muss.

Die Entwicklung von EPP wurde vor allem im Umfeld der .com-Registry vorangetrieben, deren Vergabeprozesse von denen der nationalen Registries deutlich abweichen. Diese müssen daher entsprechende Erweiterungen entwickeln und ihre jeweilige Client-Software anpassen, um EPP einsetzen zu können. Je mehr sich die Vergaberegeln einer Registry von denen der .com-Registry unterscheiden, desto zahlreicher sind die nötigen EPP-Erweiterungen und desto aufwen­diger die Client-Anpassungen, um diese Erweite­rungen implementieren zu können.

EPP in .at

Ausgehend von diesen internationalen Entwicklungen wurde auch hierzulande ein Projekt gestartet, um bei der .at-Domainvergabe ebenfalls EPP als Kommunika­tions­protokoll zwischen der Registry und den Registraren anbieten zu können. In Österreich ist die nic.at Internet Verwal­tungs- und Betriebsgesellschaft m.b.H. (www.nic.at) für die Registrierung und Verwaltung aller Domains unter .at, .co.at und .or.at zuständig - also für die gesamte öster­reichische Topleveldomain mit Ausnahme der Bereiche .ac.at (Bildung) und .gv.at (öffentliche Verwaltung). Die Entwicklung der Registry-Software sowie der technische Betrieb des Registry-Service für die .at-Topleveldo­main wird von der Arbeitsgruppe Internet-Domainver­wal­tung des ZID durchgeführt.

Dieser Arbeitsgruppe oblag es also, Erweiterungen für EPP zu definieren, die sowohl die nationale Vergabepolicy wi­derspie­geln als auch dem Gedanken einer "einheitlichen" EPP-Schnittstelle entsprechen. Das Unterfangen glückte: Es konnte ein Kompromiss gefunden werden, der sehr nahe an der Standard-EPP-Welt angesiedelt ist. Darauf aufbauend wurde im Laufe des Jahres 2006 die komplette Registry-Software für die .at-Topleveldomain dahingehend erweitert und adap­tiert, dass Anträge sowohl per eMail als auch mittels EPP an die Registry übermittelt werden können. Das bedeutet eine komplette Dual-Channel-Verarbeitung, also eine "Verheiratung" der asynchronen eMail-Welt mit dem synchronen EPP-Verhalten.

Ende des Jahres 2006 wurde den österreichischen Registra­ren ein voll funktionsfähiges System zum Testen zur Verfü­gung gestellt. Dabei zeigte sich, dass keinerlei Fehler auszumerzen oder Änderungen notwendig waren - die Soft­ware war reif für den Produktionsbetrieb. Die endgültige Um­stellung fand schließlich am 15. März 2007 statt: An diesem Tag blieb die Registry "geschlossen", die neue Software wurde eingespielt, und der Produktionsbetrieb konnte ohne weitere Probleme im Rahmen des vorgegebenen Zeitplans wieder aufgenommen werden.

Internationale Erfolge

Der Betrieb einer Registry ist eine durchaus dynamische Angelegenheit: Ausgehend von internationalen Entwicklun­gen, lokalen Änderungen der Vergabepolitik oder einfach Verbesserungswünschen der Registrare muss die Registry-Software laufend angepasst und weiterentwickelt werden. Diese Rahmenbedingungen führten dazu, dass die .at-Registry-Software im Laufe der Zeit zu einem höchst modularen und konfigurierbaren System umgestaltet wurde, mit dem Änderungswünschen relativ leicht nachgekommen werden kann. Speziell der Auftrag, auch eine Registry-Soft­ware für ENUM und Infrastructure ENUM2) zu entwickeln, war ein treibender Faktor, die Software so zu konzipieren, dass alle diese unterschiedlichen Registry-Anforderungen durch möglichst gleichartige Komponenten realisiert werden kön­nen. Dies wurde durch ein generisches, abstraktes Kernsystem erreicht, an das Registry-spezifische Module angebunden werden. Das aktuelle ".at-Registry-Baukasten­sys­tem" ist so flexibel, dass damit auch andere Registries realisiert werden können.

Eine internationale Ausschreibung für eine ENUM-Registry in Irland war schließlich der Anlass, den Schritt über die Gren­zen zu wagen - und tatsächlich konnte sich das Ange­bot mit dem österreichischen ENUM-System (basierend auf der .at-Registry-Software), das vom Konsortium der irischen Registry und der IPA
3) gemeinsam abgegeben wurde, gegen hochkarätige Mitbewerber (z.B. DENIC) durch­setzen. Damit wurde der erste Auftrag erzielt, eine ausländi­sche Registry mit dem österreichischen System auszustatten.

Ende des vergangenen Jahres starteten Gespräche mit ei­nem weiteren Interessenten, die heuer vertieft wurden und kürz­lich ebenfalls zu einem positiven Abschluss führten. In diesem Fall soll im Rahmen eines Software-Ent­wick­lungs­auf­trags die .at-Registry-Software dahingehend modifiziert werden, dass sie für die Registry in Norwegen (.no) eingesetzt werden kann: Die dort notwendig gewordene Ablöse des alten Registry-Systems stellte die Betreiber vor die Wahl zwischen einer Eigenentwicklung oder der Adaption eines Fremd­systems. Bei den folgenden "Besichtigungen" konnte das österreichische System so weit punkten, dass schließlich die Entscheidung zu seinen Gunsten fiel. Dieser Auftrag, bei dem die in vielen Bereichen unterschiedliche Vergabe­politik eine besondere Herausforderung darstellt, ist ein wei­terer Qualitätsbeweis für die von der Internet-Domain­ver­waltung am ZID entwickelte Software. In diesem Sinne sehen wir der Zukunft optimistisch und gerüstet entgegen.

 

 

1) siehe RFC 3735, RFC 3915, RFC 4114, RFC 4310 und RFCs 4930 bis 4934 (alle zu finden unter www.rfc-editor.org)

2) siehe www.enum.at sowie Artikel ENUM: Eine Nummer Und Mehr ? Telefonie und Internet verbünden sich in Comment 05/1, Seite 27 (http://comment.univie.ac.at/05-1/27/) und Infrastructure ENUM ? Die Inter-Net(z)-Verbindung für Tele­fonprovider in Comment 06/2, Seite 36 (http://comment.univie.ac.at/06-2/36/)

3) Die Internet Privatstiftung Austria (www.nic.at/ipa/) ist Eigentümerin der nic.at GmbH.