Spielereien mit Umlaut-(Sub-)Domains

Heute geht es mal wieder nicht um Naturwissenschaft oder Mathematik sondern eher um die technische Seite des Internets.

Umlaute und andere Sonderzeichen in Domains sind seit 2003 standardisiert, aber immer noch selten anzutreffen (offiziell heißen sie internationalized domain name (IDN)). Ich hab‘ mir mal angeschaut wie man Umlaut-Domains (beziehungsweise Umlaut-Subdomains) verwenden kann und bin dabei auf ein etwas merkwürdiges Verhalten der Browser gestoßen.

Codierung der Umlaute

Beim Domain Name System (DNS), das Domains (wie www.kapslog.de) in die IP-Adressen (wie 78.47.217.170) der zugehörigen Server umwandelt, werden Domains prinzipiell Ebene für Ebene aufgelöst. Das heißt der Server, der für .de Domains zuständig ist beantwortet alle Anfragen nach direkt untergeordneten Domains wie kapslog.de mit der Antwort, welcher Server dazu weitere Informationen bereithält. So fragt sich der Browser durch, bis er einen DNS-Server findet, der die IP kennt, die zur vollständigen Domain passt. (Tatsächlich gibt es noch zusätzliche Mechanismen wie Caching die das ganze schneller machen sollen, aber die spielen hier keine Rolle. Eine etwas ausführlichere Beschreibung findet man beispielsweise in der Wikipedia)

Für Umlaut-Domains wird deshalb jede Ebene einzeln betrachtet. Da für Domains ursprünglich keine Sonderzeichen vorgesehen waren, werden die Teile von Domains, die Umlaute enthalten, so umgeschrieben, dass sie keine Umlaute mehr enthalten. Beispielsweise wird „ümläüte“ in „xn--mlute-hra9n“ umgewandelt, wobei der Browser weiterhin „ümläüte“ anzeigt (normalerweise jedenfalls). Serverseitig kann dann ohne Sonderzeichen gearbeitet, während der Nutzer „schöne“ Umlaute (oder etwas ähnliches) sieht. Das verwendete Codierungsverfahren zum Umschreiben der Domains nennt sich „Punycode“ und ist im RFC 3492 genau beschreiben.

Allerdings wurde dieser Standard einmal überarbeitet, so dass es zwei Varianten dieser Norm gibt (genannt IDNA 2003 und IDNA 2008). Der wichtigste Unterschied bei der Verwendung der deutschen Sprache besteht in der Verarbeitung des Zeichens „ß“. Nach IDNA 2003 wird diese Zeichen einfach als „ss“ behandelt, während es nach IDNA 2008 ähnlich wie auch Umlaute codiert wird. Eine Website, mit der man ausprobieren kann, welche Codierung zu welchem Ergebnis führt, findet man zum Beispiel hier. Die Konverter von heise oder der Denic konvertieren grundsätzlich nach IDNA 2008.

Ausprobiert

In der Praxis ist die Browserunterstützung für solche Domains etwas uneinheitlich. Ich habe für die Domain ümläütß.kapslog.de Testseiten (bzw. Testdomains) für beide Konvertierungsvarianten angelegt (Konfiguration von DNS und Web-Server siehe unten): xn--mltss-hra9nd.kapslog.de (nach IDNA 2003) und xn--mlt-7kax5ld.kapslog.de (nach IDNA 2008). Die verlinkte Domain bei den letzten drei Links lautet jeweils genau wie die Text der hier angezeigt wird. Wenn man die Anzeige des Browsers in der Statuszeile anschaut, während man mit der Maus über die Links fährt, stellt man fest, dass die Links unter Umständen vom Browser schon einmal hin und wieder zurück konvertiert wurden (aus „ß“ wurde „ss“).

Aufgepasst: Unterschiede zwischen Browsern (IDNA 2003 vs. IDNA 2008)

Wenn man eine Domain wie ümläütß.kapslog.de in verschiedenen Browsern öffnet, stellt man fest, dass Firefox, Chrome und Internet-Explorer die Codierung nach IDNA 2003 verwenden. Das bedeutet, dass im Moment wohl die Mehrzahl der Internet-Nutzer eine andere Codierung benötigt, als der Denic-Konverter verwendet. Von den von mir getesteten Browsern hat lediglich Opera die neuere Codierung verstanden.

Welche Sicherheitsrisiken diese unterschiedliche Behandlung von Links mit bestimmten Sonderzeichen mit sich bringen kann und eine genaue Erklärung der Unterschiede zwischen beiden Codierungen findet man auf http://www.macchiato.com/unicode/idna/security-issues (das scheint übrigens die Website von Mark Davis, einem der Mitbegründer von Unicode zu sein).

Umsetzung in Nameserver und Webserver

Will man einen DNS-Server für die Verwendung von Unicode-Domains konfigurieren, dann gibt man einfach die codierte Version der Umlaut-Domain ein. In einem BIND-Zonefile sieht das dann zum Beispiel so aus:

xn--mltss-hra9nd         IN CNAME   www

Oder mit direkter Angabe der IP-Adresse

xn--mltss-hra9nd         IN A 127.0.0.1

(nach IDNA 2003)

Entsprechend wird auch der Webserver (beispielsweise Apache) so konfiguriert, dass er für die Subdomain den entsprechenden Inhalt auslierfert. In der Konfigurationsdatei steht dazu dann ein Eintrag wie

ServerName xn--mltss-hra9nd.kapslog.de

Verwendung in Top-Level-Domains

Für viele Top-Level-Domains (TLDs) wie .de, .com, .net, .org, .au, .ch und .eu lassen sich mittlerweile Domains mit Umlauten registrieren. Allerdings gibt es jeweils Listen, in denen aufgeführt ist, welche Zeichen zulässig sind. Diese Listen unterscheiden sich von TLD zu TLD deutlich.

Die Denic hat übrigens sowohl zu „angeblichen Sicherheitsproblemen“ als auch zum Eszett eigene Infoseiten eingerichtet.

Fazit

Prinzipiell ist die Einrichtung von Domains oder Subdomains mit Umlauten recht einfach. Allerdings muss man mit Sonderzeichen, die in unterschiedlichen Stufen der Standardisierung unterschiedlich behandelt werden (z.B. „ß“), im Moment sehr vorsichtig sein, da sie von unterschiedlicher Software unterschiedlich behandelt werden (und sich das Verhalten der Software mit zukünftigen Updates auch noch ändern könnte).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.