DNS was invented by technical people but commerce has changed it. If someone technical ran the DNS over at Fox network, you'd see www.sports.fox.com. But instead you see www.foxsports.com.
Aveek Datta auf der IAHC-mailinglist
Die gegenwärtige Krise des DNS besteht vor allem darin, daß sie sich nicht eindeutig technisch - wie Ingenieure es gewohnt sind - beschreiben läßt. Sie ist eine institutionelle oder politische Krise, ein Versagen der Organisationsstruktur des Internet, die Gillett & Kapor [1996] als ,,decentralized self-governance`` charakterisiert haben. Uneinigkeit herrscht, was die Suche nach Konsenslösungen nicht gerade erleichtert hat, daher bereits bei der Identifikation der aktuellen Problemlage:
Der DNS hat, halb gewollt, halb unbeabsichtigt, die Funktion eines Internet-Telefonbuchs übernommen. Im Idealfall sollen domain names leicht zu erraten sein: Den Webserver von IBM vermutet jeder auf www.ibm.com. Diese Erwartung reicht soweit, daß manche WWW-browser inzwischen wiederkehrende Namensbestandteile wie www. und .com selbsttätig ergänzen, ohne daß sie der Nutzer eintippen muß.
Letztlich wären allerdings damit solche konstanten Namensbestandteile überflüssig. Die heiß diskutierte Frage ist im Grunde, auf welchem level neue Varianzen nun am zweckmäßigsten plaziert wären. Die internet-freundliche, dem DNS kompatible und konservative Lösung wäre, den Namensraum auf der dritten (und vierten) Ebene auszunutzen: statt www.produktname.com also produktname.firma.com oder www.produktname.firma.com. Die einschneidendste Veränderung wäre es, tausende neuer top level domains zu schaffen: www.produktname.firma ist vielleicht der Traum mancher Werbeabteilung oder -agentur.
Kritiker einer allzu weitreichenden Liberalisierung des Internet-Namensraums argumentieren damit, daß auf diese Weise das Problem nur um eine Stelle nach rechts - von .com zu ,,.`` - verschoben würde. Befürworter plädieren für eine Auffächerung des top-level-Namensraums, weil damit Überfluß geschaffen werden könnte, wo heute Knappheit herrscht. Paul Vixie (siehe Abschnitt 3.2) will den Namensraum erweitern, um die Idee ad absurdum zu führen, der DNS könne als ,,Telefonbuch`` (directory service) des Internet benutzt werden.
Denn diese Knappheit ist künstlich geschaffen, sie findet keine Entsprechung in realweltlich knappen Ressourcen. Das ist ein fundamentaler Unterschied zur real world der materiellen Güter, in der Knappheiten dazu zwingen, gesellschaftlich akzeptierte Regeln für den Umgang mit solcherart knappen Gütern zu finden: Was kann dem Markt überlassen werden, was muß politisch alloziert werden?
Die Welt des Internet besteht jedoch vollständig aus software; und selbst dort, wo diese weiche Welt auf hardware basiert, wo also realweltliche Knappheiten durchschlagen, war die traditionelle Antwort (vgl. Gillett & Kapor [1996]) der Netzingenieure: Think automation! Der DNS ist selbst ein Beispiel dafür, war und ist er doch eine Lösung, die erstaunlich skalierte: Es gab nur wenige hundert Internet-Rechner, als er erfunden wurde; heute gibt es mehrere hunderttausend domains und über zwölf Millionen Netzrechner.
Wirtschaftswissenschaftler sehen beim Problem der domain names eine klassische tragedy of commons: Die Übernutzung gemeinsamer Güter (,,overgrazing``) aus eigennützigen Motiven führt am Ende zu ihrer Zerstörung. Jedoch sind die commons einer software-Welt prinzipiell erneuerbar, also durch neue software-Generationen reproduzierbar. Auf der Ebene des Gesamtnetzes sind TCP/IP und seine services traditionell so entworfen, daß Knappheiten vermieden werden. Ressourcen, die das Protokolldesign selbst bietet, sind sozusagen virtuell unbegrenzt.
Die profitgenerierende Knappheit ist in diesem Fall offensichtlich künstlich geschaffen, letztlich also ein Designfehler in der sozialen, kommerziellen Architektur des Internet.
Das explosionsartige Wachstum des Internet und die damit einhergehenden Probleme der Skalierung sind keine Neuigkeit; beide halten inzwischen schon, von niedrigem Ausgangsniveau aus, gut zwei Jahrzehnte an. Die Internet-Ingenieure haben gelernt, laufende Entwicklungen in die Zukunft zu projizieren, um drohende Skalierungsprobleme frühzeitig zu erkennen. Der Domain Name Service als technischer Artefakt und ingenieursmäßige Leistung einer zuverlässigen, verteilten Datenbank macht auf absehbare Zeit keine schwerwiegenden Probleme.
Das iterative Abfrageverfahren hält die Last der root servers niedrig. Es ist derzeit kein Problem für die acht verteilten Rechner, neben den TLDs auch noch sämtliche SLDs der populärsten internationalen TLDs .com, .org und .net zu bedienen, zur Zeit insgesamt mehr als eine Million domains. Die Internet Domain Survey der Network Wizards auf http://www.nw.com/ vom Januar 1997 bezifferte diese drei TLDs auf netto zusammen 544.503 SLDs (vgl. Anhang B). Nach Daten direkt von der Quelle (siehe http://rs.internic.net/nic-support/nicnews/stats.html) waren bis Ende Februar 1997 allein 954.139 .com-domains registriert.
Mit der technischen Fortentwicklung des DNS befaßt sich vor allem die IETF-working group DNS IXFR, Notification, and Dynamic Update (dnsind) um Paul Vixie. Vixie ist Autor von BIND, dem frei erhältlichen und weitverbreiteten name server für Unix. Die Charta der Arbeitsgruppe nennt drei Aufgabenbereiche:
Für alle drei Bereiche sind inzwischen RFCs erschienen: Incremental Zone Transfer (RFC 1995), Notification of Zone Changes (RFC 1996) und Dynamic Updates in the Domain Name System (RFC 2136).
Das Problem, das mit diesen Neuerungen gelöst werden soll, folgt aus dem weitgehend flachen Namensraum, der sich unterhalb der meisten TLDs herausgebildet hat. Auf diese Weise sind die Master Files, die alle SLDs einer TLD enthalten, zu erstaunlicher Größe angewachsen. Das wäre an sich noch kein Problem, würden diese Dateien nicht in immer kürzeren Abständen aktualisiert.
Das analoge Problem kann natürlich auch innerhalb jeder größerer domain auf anderen levels als dem top level auftreten. Zum Zwecke der Lastbalancierung werden gern mehrere reale Maschinen hinter einem Namen verborgen - ein Name kann also im Laufe der Zeit auf viele verschiedene Nummern abgebildet werden. Dazu werden die IP-Nummern im DNS ständig ausgetauscht, oftmals in Abständen bis hinunter zu einer Minute.
Ein prominentes Beispiel ist www.netscape.com: Der populäre Netscape-browser ,,Navigator`` stellt serienmäßig die firmeneigene homepage als Startseite ein, was die Last der dortigen WWW-server stark erhöht. Die IP-Adresse für www.netscape.com wird daher in kurzen Abständen geändert. Ein anderes Beispiel: Im Herbst 1996 wurde die IP-Adresse von www.xs4all.nl alle 30 Minuten ausgetauscht, um Sperrungen zu erschweren, die einige provider in Deutschland in vorauseilendem Gehorsam eingerichtet hatten. Auf www.xs4all.nl lagen zu jener Zeit Seiten der in Deutschland verbotenen Zeitschrift radikal.
Den DNS stellen solche technisch oder politisch notwendigen Maßnahmen vor grundlegende Schwierigkeiten. Denn für Änderungen im Stunden- oder gar Minutenabstand ist der DNS nicht konzipiert, hält er doch die Daten eines Verantwortungsbereichs (einer DNS zone) in nur einer großen Datei bereit, dem Master File. Bei jeder Änderung muß dieses file vom primary server zu den secondary servers transferiert werden; im Prinzip ein Mechanismus, wie er vor der Erfindung des DNS für die legendäre HOSTS.TXT-Datei benutzt wurde.
Die dnsind-working group schlägt nun einen Mechanismus vor, mit dem inkrementelle Änderungen vom primary zum secondary server übertragen werden können, ohne jedesmal die komplette Datei transferieren zu müssen. Dies ist der in RFC 1995 dokumentierte incremental zone transfer (IXFR), der den bisherigen full zone transfer mechanism (AXFR) ergänzen soll (Ohta [1996]).
RFC 1996 beschreibt den dazu komplementären Mechanismus NOTIFY, mit dem Master servers ihre slaves auf Veränderungen aufmerksam machen (Vixie [1996]). Und der in RFC 2136 definierte UPDATE opcode soll es möglich machen, resource records (RRs) eines Master Files zu ändern, ohne diese unter Umständen sehr große Datei editieren zu müssen (Vixie et al. [1997]).
Das Band, welches das Bezeichnete mit der Bezeichnung verknüpft, ist beliebig.
Ferdinand de Saussure [1967, 79]
In den juristisch ausgetragenen Konflikten um das ,,Eigentum`` an domain names spiegelt sich eine grundlegende Differenz zwischen der Internet-Kultur und der real world der Geschäftsleute. Die Buchstabenfolgen, mit denen domains bezeichnet und identifiziert werden, waren von den Erfindern dieser Idee niemals als irgendetwas anderes als mnemonics intendiert, als Merkhilfen, mit denen leichter umzugehen ist als mit den kryptischen Zahlenfolgen der IP-Adressen.
Im traditionellen Verständnis der Internet-Ordnung ist der Namensraum eine öffentliche Ressource, die in kleinen Portionen an lokale Administratoren delegiert und dort weitgehend automatisch verwaltet wird. Es gibt kein allgemein akzeptiertes Konzept des Privateigentums an solchen mnemonics, also kein besonderes Recht bestimmter Organisationen oder Firmen auf eine ganz bestimmte Zeichenfolge. Zwar erscheint es auch innerhalb der traditionellen Internet-Kultur logisch, daß sich hinter mit.edu das Massachusetts Institute of Technology verbirgt. Doch Konflikte um gleichlautende Zeichenketten gedachte man ursprünglich vermittels hierarchischer Staffelung des Namensraums zu lösen.
Die differenzierte policy der .us-domain (siehe Abschnitt 2.2.2), entwickelt unter anderem vom RFC-Editor und IANA-Kopf Jon Postel, ist ein gutes Beispiel dafür. Für die Pizzabude an der Ecke läge mit Pizza-Joe.Boston.MA.US eine weltweit eindeutige Netzadresse bereit, und auch die Namen weltbekannter Firmen wie Microsoft könnten nach dem Muster von Microsoft.Redmond.WA.US womöglich in jeder Stadt der USA einem anderen Namensinhaber dienen. Offensichtlich bietet ein flacher Namensraum nicht so viel Platz: pizza-joe.com - der Name war übrigens am 2. Dezember 1996 noch frei - kann es nur einmal geben.
Für den Fall also, daß Streit über die Nutzung eines konkreten Namens entsteht, hatte RFC 1591 in schlichter Schönheit eine policy beschrieben, der im Prinzip die meisten Registraturen weltweit folgen (vgl. http://www.netnamesusa.com/country/iso3166.html):
In case of a dispute between domain name registrants as to the rights to a particular name, the registration authority shall have no role or responsibility other than to provide the contact information to both parties.
The registration of a domain name does not have any Trademark status. It is up to the requestor to be sure he is not violating anyone else's Trademark.
Es wird also gar nicht erst der (wohl ohnehin aussichtslose) Versuch unternommen, die Prinzipien der realweltlichen Ordnung auf die Netzordnung abzubilden. Die Funktion einer Registratur beschränkt sich auf den service einer Datenbank; sie hat keine Gestaltungsaufgaben für den von ihr administrierten Namensraum. Sie entscheidet folgerichtig auch nicht über Namenskonflikte, sondern überläßt das den Gerichten.
Das InterNIC und andere Registraturen fuhren lange Zeit gut mit der einfachen policy des First come, first served - wer zuerst kommt, mahlt zuerst. Konflikte mit einer konkurrierenden Ordnung, der des Rechts, traten erst dann auf, als versucht wurde, die Idee und das komplexe, vorrangig national und nur in zweiter Linie international geprägte Recht der Warenzeichen (trademark law) auf domain names abzubilden - und die notwendigen Entscheidungen selbst zu treffen, statt sie den Gerichten zu überlassen.
Trademarks können koexistieren, domain names nicht: Niemand verwechselt das Brettspiel Clue des Herstellers Hasbro mit der in Colorado ansässigen Computerfirma Clue Computing - nur eine von beiden kann jedoch die SLD clue.com besitzen; und folgerichtig verklagte Hasbro Clue auf Herausgabe dieses Namens (vgl. http://www.clue.com/legal/index.html für den aktuellen Stand des Rechtsstreits). Das wäre kein besonderes Problem, sofern die Registratur die ihr zugedachte neutrale Rolle beibehielte. InterNIC-Betreiber NSI entschied sich anders.
Der auf Rechtsfragen des Internet spezialisierte Jurist Carl Oppedahl [1996] identifiziert die von NSI praktizierte policy als eine der Hauptursachen für die Welle von Gerichtsverfahren über domain names - neben dem neuen US-amerikanischen anti-dilution law, auf das hier nicht näher eingegangen werden kann (vgl. Agmon et al. [1996]). Die derzeit gültige Regelung geht in ihrem Kern auf die erste domain name policy vom 23. Juli 1995 zurück (vgl. ftp://rs.internic.net/policy/internic/). Immer noch erlaubt sie, wenn auch leicht modifiziert, den Eigentümern von trademarks den einfachen Zugriff auf die gleichnamige domain - im Prinzip ohne Gerichtsverfahren.
A trademark owner that wanted NSI to cut off someone's domain name had to do nothing more than write a letter to NSI stating that it owned a registered trademark identical to the domain name, and NSI would cut off the domain name after 30 days. (NSI would write what is now referred to in the Internet community as a ''30-day letter`` to the domain name owner.) The intention was apparently to promise ahead of time to do almost anything a trademark owner would have asked for in court, thus making it unlikely that the trademark owner would bother to sue NSI (Oppedahl [1996]).
Diese Praxis zwingt domain-Eigner dazu, den Namen als trademark registrieren zu lassen, wenn sie nicht dessen Verlust riskieren wollen - was das Problem auf lange Sicht eher verschärft und die Zahl der Konflikte potenziert, da es ja in den meisten Staaten der Erde möglich ist, trademarks zu registrieren, und da es keine Notwendigkeit für einen globalen Abgleich der trademarks gibt. Das internationale trademark-Recht hat viele Dimensionen, der von NSI verwaltete Namensraum hat nur eine. Die NSI-policy hat manchen domain-name-Eigner dazu veranlaßt, den Namen in Tunesien als trademark registrieren zu lassen. Dort können trademarks innerhalb von 48 Stunden eingetragen werden, ein enormer Vorteil, wenn der Postbote ein 30-day letter ins Haus gebracht hat. (NSI hat diesen Vorteil inzwischen zunichte gemacht, indem es nur noch trademarks akzeptiert, die vor dem Beginn des Rechtsstreits existierten.)
Carl Oppedahl hält die simple, an RFC 1591 orientierte policy des First come, first served auch heute noch für angebracht. Die Registraturen, schlägt der Rechtsanwalt vor, sollten sich aus den Disputen heraushalten und sie den Gerichten überlassen. Eine Registratur, die sich analog zu RFC 1591 darauf beschränke, die Kontaktadressen der beiden Konfliktparteien bereitzuhalten, ginge kaum gewichtige Klagerisiken ein. Denn in Prozessen um trademarks werde in der Regel nur die Rechtmäßigkeit eines bestimmten Verhaltens verhandelt; Klagen auf Schadenersatz hätten kaum Chancen, finanzielle Risiken seien mithin kaum zu erwarten.
Namen haben einen Handelswert erlangt und werden folgerichtig auf zahlreichen ,,grauen`` Märkten gehandelt. Um im oben verwendeten Beispiel zu bleiben: pizza.com ist längst vergeben - und auf www.pizza.com meldet sich ein Händler mit dem Angebot, diese domain zu verkaufen. Domain grabbing heißt dieser Sport im jargon der Netze. Er kam in Mode, als NSI im Herbst 1995 begann, Geld für die Registrierung zu verlangen und im gleichen Zuge alle Beschränkungen fallen ließ, die bis dahin die Zahl der domains pro Person begrenzten. Unter Gesichtspunkten des marketing vielversprechende Namen werden seitdem von etlichen domain grabbers gehortet.
Beliebt ist auch, domains unter berühmten trademarks wie coke.com zu registrieren (hijacking) und sie dann für teures Geld an den ,,rechtmäßigen`` Eigentümer abzutreten. Beides sind Folgeerscheinungen des demographischen Wandels im Netz: Die kommerziellen Nutzer machen heute, jedenfalls in den USA, den größten Teil der Netzbevölkerung aus. Den domain names ist so eine vorher unbekannte Bedeutung zugewachsen: Im Lichte des Kommerzes wurde sichtbar, daß das ursprüngliche Konzept des DNS, in dessen Rahmen die Namen als arbiträr angesehen wurden, nicht aufging - und zwar von Anfang an. Tatsächlich war und ist es ja keineswegs zufällig, daß mit.edu die domain des Massachusetts Institute of Technology ist.
Im März 1993 übernahm Network Solutions Incorporated (NSI) durch ein cooperative agreement mit der National Science Foundation (NSF) der USA das InterNIC und damit das management der TLDs und der SLDs innerhalb der generischen TLDs wie .com und .org (vgl. Bradner et al. [1996]). NSI betreibt einen der neun weltweiten root servers. Die NSF hatte 1991 die Finanzierung der Registratur für den nicht-militärischen Teil des Internet übernommen, als das US-Verteidigungsministerium seine Unterstützung aufgab. Damals war die education domain .edu die am schnellsten wachsende, und so erschien dieser Transfer nur logisch (vgl. dazu und zur Situation 1994 The National Science Foundation Workshop on Name Registration For The ,,.COM`` Domain [1994]).
Die Registrierung war bis zum September 1995 kostenlos. Zu diesem Zeitpunkt begann NSI auf Verlangen von NSF, pro Jahr und domain 50 US-Dollar zu berechnen. Dies war eine Reaktion auf das anhaltende exponentielle Wachstum des Internet und die damit einhergehende explodierende Nachfrage nach second level domains (SLDs) unterhalb der internationalen TLDs, allen voran .com. NSF sah sich nicht länger in der Lage, den notwendigerweise wachsenden Apparat InterNIC zu finanzieren. Folgt man der Bewertung von Bradner et al. [1996], so war dies eine Art Notfallreaktion auf eine aktute Finanzkrise:
The NSF decision to require NSI to impose fees for registration of 2nd level domain names within the International Top-Level Domains (iTLDs) was an emergency 'patch' to a financial crisis in domain name registration services. It was decidedly not an articulation of long-term policy or approval of the status quo.
Deutlich mehr als eine halbe Million domains haben die Krise jedoch inzwischen in ihr Gegenteil verwandelt, generieren sie doch eine Jahres-Bruttoeinnahme von (theoretisch) mindestens 25 Mio. US-Dollar - ein Betrag, der manchem attraktiv erscheint. Robert Shaw [1996] beziffert das Namensgeschäft der Registrierungsfirma NSI gar auf rund 35 Millionen US-Dollar jährlich. Mittelfristig soll die seitens der US-Regierung finanzierte NSF sich aus der Internet-Verwaltung zurückziehen, so wie sie bereits im Frühjahr 1995 den Betrieb des US-backbones einstellte und an mehrere kommerzielle provider übergab. Der geplante Rückzug, an sich unproblematisch und völlig konform mit dem amerikanischen Verständnis staatlicher Aufgaben, wird erschwert durch die offensichtliche Attraktivität des Registratur-Geschäfts.
Wer darf eine Registratur betreiben? Diese Frage wird letztlich noch immer von der IANA entschieden und durch Einträge in den root servers umgesetzt. In der Praxis sind die IANA-Entscheidungen jedoch von der Akzeptanz jedes lokalen Administrators abhängig. Technisch bedarf es nur veränderter Einträge in den Konfigurationsdateien der name servers, um die Rolle von NSI als root des DNS zu beenden. BIND-Autor Paul Vixie kündigte Ende Oktober 1996 an, Mitte Januar 1997 die default-Einträge in neuen release-Versionen des BIND named zu ändern, wenn sich bis dahin keine Lösung für die Zukunft des DNS abzeichnen würde. Derzeit gibt er jedem software-Paket die aktuellen, von der IANA sanktionierten root servers mit. Anfang 1997 erklärte er dann, die Vorschläge des IAHC (siehe Abschnitt 4.3) zu unterstützen.
Solange also nur wenige ISPs von sich aus andere als die ,,offiziellen`` root servers in ihre Konfiguration eintragen, halten die Administratoren dieser IANA-sanktionierten servers die eigentliche Macht über jede Erweiterung des Namensraums in den Händen. Bislang haben sie die Absicht bekundet, sich an die Vorgaben der IANA zu halten. Am 23. Januar 1997 annoncierte IANA-Kopf Jon Postel neue ,,echte`` root servers, die nur noch für die Wurzel des DNS, also die root zone ,,.``, und nicht mehr wie bislang nebenbei auch für die generischen TLDs zuständig sein sollen. Die ersten beiden werden vorläufig bei NSI plaziert, zwei weitere nahmen Ende Februar 1997 ihren Betrieb am ISI in Kalifornien auf.