Nun kann das DNS ja nur vereinfachtes ASCII, d.h. es gibt gar keinen Raum dafür, direkt Sonderzeichen in das DNS zu bauen. Solche Dinge wie Unicode gab es bei der Entwicklung von DNS nicht und nachträglich lässt sich das ohne eine wirklich ganz große Umstellung im Internet nicht.

Also bedient man sich einem Verfahren namens IDN. IDN ist eine einheitliche Möglichkeit, eine Domain mit Sonderzeichen in eine normale Domain mit dem vereinfachten ASCII-Zeichensatz zu übersetzen. Aus einer Domain namens grünkohländerungsvöllerei.de würde hinter den Kulissen xn--grnkohlnderungsvllerei-64b55boe.de übersetzt werden. Die Kennung „xn--“ gibt dabei an, dass es sich bei diesem Domainnamen um einen in IDN übersetzten Namen handelt. Das IDN-Verfahren funktioniert soweit recht passabel und bildet Sonderzeichen und Schriftzeichen vieler Sprachen problemlos im DNS ab. Und das eben so, dass jeder DNS-Server damit auch klar kommt.

An was man sich bisher nicht herangetraut hat, ist das IDN auch für Top-Level-Domains einzusetzen. Top-Level-Domains kennen wir nur in Klartext, aber man denkt bei der ICANN – natürlich absolut ohne monetäre Hintergedanken – daran, weitere Namensräume zu erschließen und dazu könnten eben auch Top-Level-Domains mit Sonderzeichen gehören. Beispielsweise schleppen ja schon unsere österreichischen Freunde ein Sonderzeichen in ihrem Landesnamen mit, da könnte man in einem zukünftigen Adressplan durchaus auch auf die Idee kommen, eine Top-Level-Domain namens „.österreich“ einzuführen. (Disclaimer: Ich will das persönlich NICHT und zwar NICHT deshalb, weil ich Österreicher nicht als Menschen respektiere, sondern weil ich solche DNS-Spielereien für sinnlos halte.)

Probieren geht, gerade im Internet, gern über studieren und deshalb hat sich die ICANN dazu entschieden, eine Reihe von Top-Level-Domains ab Mitte Oktober vorübergehend in die Root-Zone zu nehmen, die den Begriff „test“ in verschiedenen Sprache und Zeichensätzen enthalten. Jede dieser testweisen Top-Level-Domains enthält eine Second-Level-Domain namens „example“, mit der entsprechend getestet werden kann.

Da jetzt vermutlich die meisten das Problem haben werden, mit ihren Betriebssystemen überhaupt eines dieser Sonderzeichen zu erzeugen und einen Übersetzer dafür haben, der das übersetzt, kann jeder natürlich eben auch mit dem IDN-Code und mit dem DNS-Werkzeug nslookup entsprechende Abfragen machen. Und wenn man http://xn--e1afmkfd.xn--80akhbyknj4f/ in den Browser eingibt (oder der Einfachheit halber auf den Link klickt), funktioniert das sogar.

Das NIC México und die Latin American and Caribbean Federation for Internet and E-commerce (eCOM-LAC), eine gemeinsame Organisation südamerikanischer NICs (also Verwalter der jeweiligen, nationalen Top-Level-Domain), einiger großer Internet Service Provider, der Internet Society und der ICANN, haben am 14. November 2007 eine fast schon überschwängliche Pressemeldung veröffentlicht, in der sie euphorisch „offiziell“ die neue Top-Level-Domain „.lat“ für die Latino-Community angekündigt haben. Die „Entscheidung“ wurde mit dem Hintergedanken herbeigeführt, um „Internet Ressourcen, die mit Latinos verbunden sind, zu identifizieren, differenzieren und um Wert zu steigern, da ihre geographischen Grenzen immer stärker nach hinten treten und sie auf diese Weise ihre kulturellen, sozialen und wirtschaftlichen Identifikationen zu äußern“.

Also das übliche Blabla, weshalb wir im Internet unbedingt eine weitere Top-Level-Domains für eine Community brauchen, wie beispielsweise .cat für die katalanische Community und .asia für die asiatische. Vielleicht ja irgendwann auch ein .bav für die bajuwarische Community oder ein .preu für die preußische.

Der wichtigste und eigentlich wirklich interessanteste Punkt findet sich am Ende, denn da steht, dass nun diese „offizielle Entscheidung“ dazu führt, einen offiziellen Antrag an die ICANN zu stellen, der dann voraussichtlich im „vierten Quartal 2008“ (!) beraten wird. Demnach werden bis zu einer endgültigen Entscheidung für ein „.lat“ vermutlich noch einige IP-Pakete durch die Backbones rauschen.

Kim Davies von der ICANN hat im ICANN Blog eine interessante Feststellung und wohl auch etwas seinem Ärger Luft gemacht. Alle Welt spricht von 13 Root-Servern im DNS. Warum eigentlich, wo wir gerade bei diesem Punkt, ausgerechnet 13 Root-Server?

Das hat seine Ursache in technischen Grenzen von UDP, das für Übertragungen von DNS-Informationen genutzt wird. UDP hat bekanntlicherweise im Gegensatz zu TCP die Einschränkung, dass es verbindungslos arbeitet, also muss die Antwort auf eine Anfrage komplett in das UDP-Paket hineinpassen, wenn nicht aufwendig ein Mechanismus benötigt werden soll, der mehrere UDP-Pakete wieder zusammenbringt. Bei DNS nicht der Fall, deshalb passen nur 13 Adressen in ein Paket und dito.

Nun darf man sich natürlich nicht vorstellen, dass hinter jeder der 13 IP-Adressen ein einzelner Rechner steht, denn der würde die Anzahl der Anfragen sicherlich nicht bewältigen können. Denn jeder DNS-Server auf dieser weiten Welt muss mindestens alle 42,33 Tage alle diese Root-Server einmal abklappern. Da genügend DNS-Server jedoch erheblich öfter gestartet werden, genügend Administratoren ihre DNS-Server nicht im Griff haben und auch noch genügend technisch Versierte Schabernack mit den DNS-Root-Servern treiben, ist also mächtig was los bei diesen Servern. Mit Loadbalancern ist es technisch kein Thema, an einem Standort unter einer IP-Adresse eine ganze Rechnerfarm zu betreiben. Alles kein Problem.

Naja, doch noch ein kleines Problem, zumindest ein Designproblem. Wir haben jetzt zwar vielleicht ein paar Dutzend DNS-Root-Server, die an 13 Standorten stehen. Sind aber 13 Standorte nicht zu wenig? Wäre es nicht praktischer, wenn man Instanzen der DNS-Root-Server auch an weniger frequentierten Stellen im Internet positionieren könnte, um den interkontinentalen Datenverkehr zu verringern?

Kann man, und zwar mit einer Technik namens Anycast!

Mit Anycast kann man auf kontrollierte Weise etwas machen, was eigentlich in jedem größeren Netzwerk unweigerlich zu einer grande catastrophe führt, wenn man nicht hundertprozentig weiß, was man da genau tut: Rechner in einem verteilten Netzwerk mit identischen IP-Adressen ausstatten. Vereinfacht betrachtet besteht also eine DNS-Root-Server-Instanz, nehmen wir mal den Root-Server „K“, der vom RIPE betrieben wird, nicht an einer Stelle im Internet, sondern an vielen, nämlich in London, Amsterdam, Frankfurt, Athen, Doha (Katar), Mailand, Reykjavik, Helsinki, Genf, Poznan (Polen), Budapest, Abu Dhabi, Tokio, Brisbane, Miami, Delhi und Nowosibirsk. Und überall haben diese Instanzen zum einen genau die gleiche IP-Adresse und auch den genau gleichen Inhalt auf ihrem DNS-Server. Und da diese Instanzen an größeren Knotenpunkten liegen, ist in den Routingtabellen der Anbieter, die an diesen Knotenpunkten eine Verbindung haben, mit Routing-Einträgen geregelt, dass die Zugriffe an diese bestimmte IP-Adresse eben zu der Instanz gehen, die lokal oder in unmittelbarer Netznähe steht.

Ergebnis dieses Konfigurationsaufwandes – und das ist es wirklich – ist, dass diese ganze Phalanx an einzelnen Instanzen im Idealfall erheblich schwerer verwundbar ist, als wenn alles an einem Standort und über einige wenige Anbindungen erreichbar wäre. Wollte also beispielsweise ein böser Mensch die Instanz lahmlegen, müsste er alle einzelnen Instanzen gleichzeitig angreifen. Das ist pauschal nicht ganz unmöglich, jedoch extrem schwer.

Und schon haben wir mit Anycast und nur 13 offiziellen DNS-Root-Servern, die jedoch an über 130 Standorten laufen (immer gut für eine Fangfrage..) eine ziemlich stabile DNS-Oberkante.