blog@netplanet

Eine recht hübsche Statistik hat John L. Crain im ICANN-Blog über den DNS-Root-Server namens “L” veröffentlicht. Diese Root-Server-Instanz wird von der ICANN selbst betrieben und ist in Miami stationiert. In seinem Artikel hat Crain einen vermutlich recht typischen Tag, nämlich den 26. November 2007, als Basis für allerlei interessante Abfragestatistiken genommen.

Wir holen uns nochmal unsere ersten/letzten DNS-Kenntnisse heraus und rufen uns im Hinterkopf auf, dass die DNS-Root-Server die oberste Instanz im DNS darstellen und überhaupt darüber Auskunft geben, welchen Nameserver im Internet man kontaktieren muss, um zu den einzelnen Top-Level-Domains zu kommen. Sprich: In den Zonendateien der Root-Server steht beispielsweise drin, welcher Nameserver für die Top-Level-Domain “.de” zuständig ist. Daraus ergibt sich fast schon automatisch, dass die DNS-Root-Server dementsprechend genügend Geschäft haben.

Die erste Grafik ist eigentlich schon die interessanteste, denn sie enthält die Abfragen aufgeschlüsselt nach Top-Level-Domains. Die Farbunterteilungen stellen die unterschiedlichen Abfragetypen dar. Rot sind beispielsweise normale A-Records, also beispielsweise die Auskunft, welche IP-Adresse sich hinter www.netplanet.org verbirgt. Es ist also nicht sonderlich verwunderlich, dass die Abfrage von A-Records alle anderen überragt (mit Ausnahme von .arpa, naturgemäss sind aber in dieser Top-Level-Domain die PTR-Records wichtig).

Dass zu allererst die großen und vor allem alten Zonen “.com”, “.net”, “.arpa” und “.org” vorkommen, ist einleuchtend. Bei den Länder-TLD wird es dann aber schon interessanter, denn vor “.de”, die mit Abstand die grösste Länder-TLD weltweit ist, erscheint “.br” für Brasilien. Auf den ersten Blick verwunderlich, auf den zweiten Blick jedoch durch den Standort des Root-Servers erklärbar, da dieser - netzwerktechnisch gesehen - in unmittelbarer Nähe zu großen Datenaustauschpunkten zu südamerikanischen Netzen steht, bekommt dieser natürlich auch dementsprechend viel Abfragen aus der Region ab. Witzig sind hier auch so Top-Level-Domain-Abfragen wie “.belkin”, “.local” oder “.localdomain”, alles Abfragen aus eher angemurksten DNS-Implementierungen.

Die zweite Grafik enthält eine Aufteilung über die Antwortkategorien des Root-Servers. Grün, und damit rund 70 % aller Antworten, steht für “NOERROR” und gibt an, dass eine Abfrage korrekt beantwortet wurde. Rot wiederum steht für “NXDOMAIN” und ist die Antwort dafür, wenn eine Anfrage für eine Domain-Information eintrifft, für die der Root-Server jedoch nicht zuständig ist (nicht zu verwechseln mit falschen Anfragen). Der Rest an Antworten ist offensichtlich vernachlässigbar, da sie nicht in der Grafik auftauchen.

Die dritte Grafik gibt an, in welchem IP-Protokoll die empfangenen Anfragen daherkamen. Es überrascht den Insider weitgehend nicht, dass über 90 % aller Anfragen per UDP daherkommen, da UDP das Standardprotokoll ist, in dem DNS-Kommunikation abgewickelt wird. Nichtsdestotrotz funktioniert aber, wie man sieht, auch TCP dafür, was durchaus genügend Systemadministratoren nicht wissen. Das kleine Stückchen Rot steht übrigens für ICMP und vermutlich sind das schlicht und einfach solche Dinge wie Pings und Traceroutes, die offensichtlich von genügend Leuten an DNS-Root-Server gesendet werden.

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. Für “<kyrillische Version von example>.<kyrillische Version von test>” sieht das so aus:

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, derwü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.

Aus einer Spam:

fetch all kind of medical stuff on a very less price.

pharmstoregone.com.

Remove the dot from the end of the link to use it, thanks.

Fast schade, dass ich den Absender nicht erreichen kann. Sonst hätte ich dem Armleuchter erklärt, dass sein Punkt hinter dem URL gar kein Fehler ist, sondern eigentlich absolut korrekt ist, denn der Punkt stellt im DNS die Root-Zone dar. Im Eifer des Gefechtes hat er sogar etwas richtig gemacht.

Zugegeben, ich musste schon kurz schlucken, als ich in der einschlägigen Online-Tickerei las, dass angeblich der Support von BIND eingestellt werden solle. Ein zweites Lesen ergab dann, dass lediglich BIND in der Version 8 kurzerhand am Ende des Supports angelangen soll. Was aber ist eigentlich BIND und warum soll uns das interessieren?

Nun, BIND steht für Berkeley Internet Name Daemon und ist eine DNS-Nameserver-Software. Eigentlich müsste man sagen: Die DNS-Nameserver-Software, denn sie gilt als Referenzimplementierung für Nameserver, deren Wurzeln tatsächlich aus der frühesten DNS-Geschichte ab 1983 kommen. BIND ist zwar nicht die erste DNS-Nameserver-Software (das war eine Software namens JEEVES), dafür aber eine Weiterentwicklung, die ursprünglich an der University Berkeley in Kalifornien (daher das “B” im Namen) begonnen wurde. Danach landete die offizielle BIND-Entwicklung kurzfristig bei der Digital Equipment Corporation und dann bei Paul Vixie im Unternehmen Vixie Enterprises - kein wirklich Unbekannter, denn Vixie war schon zu diesem Zeitpunkt einer der Hauptakteure in der BIND-Entwicklung und gehörte Anfang der 1980er Jahre zu den Koryphäen der Internet-Bewegung. Seit 1997 ist die BIND-Entwicklung nun bei einer non-kommerziellen Unternehmung namens Internet Software Consortium (ISC), an der auch Vixie beteiligt ist.

Der Ruf von BIND ist legendär und es ist keinesfalls übertrieben, zu sagen, dass Nameserver, die mit BIND betrieben werden, buchstäblich die Grundsäulen des DNS bilden, denn genügend Root-Server und deren einzelne Instanzen laufen mit BIND-Software, aber auch genügend Nameserver-Instanzen bei Internet Service Providern und Firmen weltweit. Gerade aus diesem Grund läuft die Weiterentwicklung und Pflege von solch eminent wichtiger Software eher behutsam bis konservativ. Die Support-Zyklen für Hauptversionen sind relativ lang, dementsprechend wurde die Hauptversion 8 bis vor kurzem trotzdem noch offiziell gepflegt, obwohl es schon seit längerem die Hauptversion 9 gab.

Richtiggehend geknallt hat es in der BIND-Community im Juli, als in BIND 8 ein schwerer Fehler gefunden wurde, er es ermöglichte, den so genannten DNS-Cache zu manipulieren. Dieser DNS-Cache enthält in einem Nameserver die bereits aufgelösten DNS-Namen und IP-Adressen für einen bestimmten Zeitraum, um bei gleichen Anfragen diese aus dem DNS-Cache bedienen zu können. Essentiell ist es deshalb, dass dieser DNS-Cache fälschungssicher sein muss und nur vom DNS-Server selbst gefüllt werden darf. Genau hier gab es in BIND 8 eine derart schwere Sicherheitslücke, die es mit relativ geringem Aufwand ermöglichen konnte, Einträge im DNS-Cache beliebig zu manipulieren. Nameserver-Administratoren, die BIND einsetzen, waren deshalb in selten so dringendem Maße aufgefordert, ihre BIND-Installationen zu patchen, allen voran die Administratoren der Root-Server, um die Integrität des gesamten Domain Name Systems nicht vorübergehend massiv beeinträchtigen zu lassen. Interessanterweise tauchte dieses Sicherheitsproblem auch bei BIND 9 auf, dort allerdings in einem erheblich kleinerem Umfang.

Die jetzige Ankündigung, den Support für BIND 8 praktisch sofort einzustellen, wird deshalb mit “grundlegenden architekturellen Problemen” begründet und mit einer dringenden Empfehlung versehen, umgehend auf BIND 9 zu wechseln. Das hört sich sehr danach an, als ob gewissen Leuten die Situation ziemlich peinlich ist.

Es ist ja eigentlich zum Lachen, wenn es nicht so traurig wäre: Im Februar 2004 hat die US-Patentbehörde einer Firma namens Ideaflood in Fresno/Kalifornien ein Patent zugesprochen, mit dem dieser Firma die Idee des Subdomaining zugesprochen wird. Man glaubt es kaum, tatsächlich damit die Möglichkeit gemeint, beispielsweise unter dem Domainnamen netplanet.org einen Hostnamen namens www und blog zu haben. Und diese Firma Ideaflood, in dessen Mitarbeiterteam niemand zu finden ist, der auch annähernd an der Entwicklung des Domain Name System zu finden, will von sich sagen, sie habe das erfunden. Was natürlich völliger Unsinn ist. Das Subdomaining ist fester Bestandteil des DNS, sonst gäbe es ja schon netplanet.org nicht, da in diesem Beispiel genau genommen “netplanet” schon eine Subdomain von “org” ist.

Das Fatale ist, dass diese Firma schon angefangen hat, vornehmlich kleine Firmen in den USA abzumahnen. Und genau das ist wohl auch die Masche: Man versucht als kleine Firma, der US-Patentbehörde einfach einmal eine angeblich neue Idee unterzujubeln und darauf zu hoffen, dass sich schon ein überforderter Ingenieur finden lässt, der das als neuartiges Patent anerkennt und mache sich gleich danach heran, möglichst kleine und unauffällige Firmen abzuklappern und Lizenzkosten einzutreiben. Selten wird sich jemand finden, der die Mühen und Kosten nicht scheut, das Patent einmal entsprechend überprüfen zu lassen, wie es in Fall des Subdomaining-Patens nun die Bürgerrechtsorganisation EFF tut, besser bekannt als Mutterhaus der Blue-Ribbon-Kampagne.

Wenn du nicht mehr weiter weißt, gründe einen Arbeitskreis. Oder organisiere eine Anhörung. Meine Lieblings-Internet-Organisation, die ICANN, macht wieder mal so eine, ironischerweise zur dicksten Urlaubszeit. Seit letzten Freitag haben wir nun alle bis zum 30. August die Ehre, der ICANN mal so richtig unsere Meinung zur Einführung neuer Top-Level-Domains geigen zu dürfen.

Allerdings will die ICANN nicht wissen, welche Top-Level-Domains wir noch gern hätten (oder nicht), sondern die ICANN möchte gern, dass nun nicht mehr sie allein den DNS-Buhmann spielen muss und fragt deshalb die Internet-Community, welche Regeln und Prozeduren sie gern zur Prüfung von neuen Top-Level-Domains sehen würde. Und offenbar kann es der ICANN nun gerade nicht schnell genug und auffälligerweise nicht transparent und augenscheinlich unbürokratisch genug gehen, denn die Einreichungen sollen kurz nach Anhörungsende veröffentlicht werden.

Die Einreichungen prüfen und zu einer daraus entstehenden Empfehlung kommen soll die GNSO, die Generic Names Supporting Organization. Während die ICANN noch generös dazu vermeldet, dass sie sich der Empfehlung der GNSO anschließen will, zollt dazu nur der Laie Lob, denn die GNSO ist ein festes Organ der ICANN. Es darf also vermutlich ziemlich fest damit gerechnet werden, dass es zu keinen besonderen Überraschungen kommen dürfte. ICANN-Chef Paul Twomey ließ allerdings einen Satz in der Pressemeldung zum Anhörungsstart los, der aufhorchen lässt:

“When coupled with ICANN’s current work on introducing internationalized domain names, it is possible that hundreds and, eventually, more than 1,000 new TLDs could be created.”

Ganz ehrlich: Das will keiner wirklich. Und ich überlege wirklich noch, ob Twomeys Auswurf ein Angebot oder eine Drohung ist.

Dass bei ICANN-Meetings vor allem das beiläufig dahergeplapperte Wort das meist erheblich interessantere ist, ist nun wirklich nichts mehr neues und eigentlich fast schon eine beliebte Tautologie in der Internet-Community. Das gerade erst zu Ende gegangene 29. ICANN-Meeting steht dem nicht nach.

Wenn sich die ICANN schon besonders schwer bei der Einrichtung neuer Top-Level-Domains tut, so tut man eben am liebsten Dinge, die augenscheinlich eher den Weg für neue Top-Level-Domains bereiten sollen. Und so ist eine ICANN-Arbeitsgruppe auf den äußerst bemerkenswerten Einfall gekommen, die Regularien für neue, generische Top-Level-Domains auf die Weise zu ändern, dass Begriffe, die “moralisch”, “religiös” oder “politisch” bedenklich oder in Markenrechtsstreitigkeiten befindlich sind, nicht als Top-Level-Domains eingetragen werden können.

Das mag auf den ersten Blick zunächst kein Problem sein, allerdings hat es schon ein gewisses “G’schmäckle”, dass Regierungen in der Root-Zone ihnen nicht gefallende Begriffe ablehnen können. Sicherlich wäre ein Konsens zu erreichen, um beispielsweise “.arier” nicht haben zu wollen. Doch wie sieht es aus mit so Begriffen wie “Gay”, “Bisexuality”, “Imperialism” etc.? Wo setzen moralische Werte an und wo endet die Wertemessung? Und was interessiert das letztendlich die jeweils aktuelle US-Regierung, die praktisch auf der Root-Zone sitzt?

Andererseits: Die Idee der Zensur in der Root-Zone mag verwerflich sein, ist aber letztendlich nicht das Papier wert, auf der sie gedruckt ist. Dass die ICANN bereits mit moralischen Maßstäben misst bzw. moralische Bedenken vorträgt, um möglicherweise anders geartete Interessen zu blockieren, wurde schon sehr deutlich, als im März diesen Jahres die Pläne der Top-Level-Domain “.xxx” als virtueller Rotlichtbezirk im Internet versenkt wurden.

Da ich ja nun berufsbedingt nicht gerade wenig mit gängigen und eher nicht so gängigen Top-Level-Domains zu tun habe und mich es inzwischen auch nicht überraschen würde, wenn der Betreiber einer exotischen Top-Level-Domain im Laufe einer Domainregistrierung darauf besteht, persönlich im jeweiligen Land vorbeizukommen und die Schuhe des Betreiberchefs sauberzulecken, kam ich doch kurz ins Stocken, als ich den Begriff “GeoTLD” las. Ich kenne ja nun “gTLD” für “generische Top-Level-Domains” wie .com und .net, “ccTLD” für “Country-coded TLD” wie .de oder .uk und seit einiger Zeit auch “sTLD” für “sponsored TLD” wie .museum oder .aero.

“GeoTLD”, so haben wir zu lernen, stehen für “geografische” TLD, also beispielsweise das in den Startlöchern befindliche .asia. GeoTLD unterscheiden sich also wohl damit definitiv von offiziellen, nationalen Domains und sind für geografische Regionen gedacht, wie auch immer man die definieren mag.

Sinnigerweise gibt es auch hier keine Regel ohne Ausnahme, denn die EU ist eigentlich ja kein souveränes Land, hat aber dennoch keine GeoTLD, sondern eine richtige ccTLD, was letztendlich dadurch erkannt werden kann, dass ccTLD grundsätzlich immer nur zwei Buchstaben lang sein dürfen, ccTLD, sTLD, GeoTLD und was weiß ich noch alles mindestens drei - wenn nicht irgendjemand auch hier noch Ausnahmen montiert. Fürwahr ist das wohl auch nicht mehr unbedingt außer Reichweite, da ein Feldversuch mit Umlauten in Top-Level-Domains (die auch hier mit dem Punycode-Verfahren in einfache ASCII-Zeichen kodiert werden), der in den letzten Wochen geführt wurde, positiv verlaufen ist.

Der Gelddruckmaschinerie ist also weiterhin keine natürliche Grenze gesetzt und erhöht gleichzeitig im Quadrat den Verwirrungsgrad des Normalbenutzers. Aber das scheint inzwischen auch niemanden mehr wirklich zu stören.