Hinter dem, was die Internetprovider hierzulande einfach Umlaut-Domain nennen, verbirgt sich ein komplexes Verfahren, das weit über die Kodierung der deutschen ä-, ö- und ü-Zeichen hinausgeht. Die internationalisierten Domainnamen (IDN, Internationalized Domain Name) reißen allerdings nicht nur alte Barrieren ein, sie schaffen leider auch neue. Für Linux-Anwender - und nicht nur für die - stellen sich damit wichtige Fragen: Welche Anwendungen sind bereits IDN-tauglich? Welche werden es in absehbarer Zeit sein? Wo hilft nur der Griff in die Trickkiste?
Bisher erlaubte der RFC 1034 für Domainnamen nur die Buchstaben A bis Z, die Ziffern und das Minuszeichen aus dem Ascii-Zeichensatz. Nun unterstützen die Registrare verschiedener Toplevel-Domains auch Namen, die Unicode enthalten. Dabei stehen theoretisch rund 95000 unterschiedliche Zeichen zur Auswahl.
Praktisch ist der freie Zeichenvorrat im deutschsprachigen Raum allerdings begrenzt. So hat das deutsche DENIC nur genau 92 zusätzliche Zeichen aus den Codesets Latin-1-Supplement und Latin-Extended-A zugelassen[9], die Schweizer sind noch viel vorsichtiger und begnügen sich vorerst mit 31 neuen Zeichen aus dem Latin-1-Supplement.
Diese Einschränkung verhindert eine Reihe potenzieller Fehler von vornherein. So mögen japanische Schriftzeichen als Blickfang inmitten lateinischer Lettern zwar reizvoll sein, doch wären für den Benutzer Probleme mit fehlenden Fonts programmiert. Außerdem vermindert sich die Gefahr, grafisch ähnliche Zeichen zu verwechseln. Nicht alles, was möglich wäre, hat wirklich Sinn.
Für Serverdienste bleibt alles beim Alten
Administratoren dürfen sich freuen: Sie brauchen weder in den sensiblen DNS-Dienst, noch in die Konfiguration des Webservers einzugreifen, denn diese Dienste operieren auch künftig nur mit ihrem beschränkten Ascii-Code. Umstellen müssen sich dagegen die Clients, in erster Linie die Browser. Von ihnen sind bisher beispielsweise Netscape (ab 7.1), Mozilla (ab 1.4), Konqueror (ab 3.2 mit der GNU IDN-Library) und Galeon (ab 1.3.14) fit für IDN.
Tippt der Besitzer eines derart befähigten Browsers eine Unicode-URL ein, wandelt das Programm sie in einem mehrstufigen Prozess in ein spezielles Ascii-Format und befragt damit den Nameserver nach der zugehörigen IP. So kommen Web- wie Nameserver nur mit Namen in Kontakt, die aus dem bisher gültigen Zeichenvorrat der 37 Ascii-Zeichen gebildet wurden.
Aus einem Domainnamen entstehen auf diese Weise zwei Versionen, die je nach Verwendungszweck eingesetzt werden: Benutzer und IDN-fähige Applikationen arbeiten mit der Unicode-Version - alle anderen Anwendungen werden mit der daraus berechneten Ascii-Form bedient. (siehe Abbildung 1).
Dieses Konzept mündete im RFC 3490: Internationalizing Domain Names in Applications (IDNA). Der im März 2003 verabschiedete Standard sieht vor, dass jener Teil eines Domainnamens, der Unicode-Zeichen enthält, mit dem Präfix »xn--« gekennzeichnet wird. Daher verweigert die zentralen Registrierungsstelle für DE-Domains DENIC bereits seit Anfang 2002 Domains mit jeweils einem Minuszeichen an dritter und vierter Stelle.
Abbildung 1: Der lange Marsch vom User-Interface bis zum Webserver: IDN-fähige Anwendungen müssen die gesamte Übersetzung in das Ascii- Format selbst übernehmen. Erst der fünfte Schritt liefert die Zeichenkette, die ein Nameserver in eine IP-Adresse umsetzen kann.
Punycode
Das Beispiel aus Abbildung 2 zeigt, wie die Kodierung der Sonderzeichen genau bewerkstelligt wird: Aus dem Domainnamen »grün-wölfel.de« wird dabei die Ascii-Variante »xn-grn-wlfel-47a6d.de«. Dieser String, der als ACE-Form (Ascii Compatible Encoding) bezeichnet wird, kommt bei der Namensauflösung zum Zug. Er beginnt mit dem erwähnten Präfix, gefolgt von den Zeichen, die keiner Umschreibung bedürfen.
Abbildung 2: Die Konvertierung von Unicode nach ACE erzeugt Domainnamen in dem für Web- und Nameservern vertrauten Ascii.
Die Sonderzeichen und deren Position in der Zeichenkette kodiert eine besondere Ziffern-Buchstaben-Kombination (47a6d), die ein Minuszeichen abtrennt. Die speziell für IDN-Domains entwickelte Kodierungsvorschrift RFC 3492[6] - der so genannte Punycode - gründet sich auf dem allgemeineren Bootstring-Algorithmus. Der Informatiker erwartet von diesem Code Eineindeutigkeit (Bijektivität), die gewährleistet, dass jedem Punycode nur genau ein Ascii-Pendant entspricht (und umgekehrt). Der Anwender möchte, dass die ACE-Form des Domainnamens nicht zu lang wird.
Punycode erfüllt beide Anforderungen. Lange Namen wären nicht nur dort unbequem, wo der Benutzer sie eintippen muss, sie liefen auch Gefahr, mit der Obergrenze von maximal 63 Zeichen Länge zu kollidieren. Ob dieses Limit eingehalten wird, erweist sich erst nach der Konvertierung, für die sich geeignete CGIs oder Applets auf vielen Webseiten finden (darunter auch der des DENIC). Das weiter unten vorgestellte Kommandozeilen-Tool IDN bietet diesen Service ebenfalls.
Abbildung 3: Die 92 Neuen - diese Zeichen unterstützen deutsche Registrare seit März 2004 in Domainnamen.