In Luna in 2075 phone numbers were punched in, not voice-coded, and numbers were Roman alphabet. Pay for it and have your firm name in ten letters - good advertising. Pay smaller bonus and get a spell sound, easy to remember. Pay minimum and get arbitrary string of letters. ... I asked Mike for such a ... number. ,,It's a shame we can't list you as 'Mike.'``
,,In service,`` he answered. ,,MIKESGRILL, Novy Leningrad. MIKEANDLIL, Luna City. MIKESSUITS, Tycho Under. MIKES-``
Heinlein [1966], zit. nach Oppedahl [1996]
Angenommen, eine Anruferin könnte das Wissenschaftszentrum Berlin erreichen, indem sie wzb.eu in die Telefontastatur tippte. Keine kryptischen Telefonnummern wären mehr notwendig, sondern einfach zu merkende Buchstabenfolgen führten zum Ziel. wzb.eu ließe das Telefon in der Zentrale klingeln, und unter duplox.wzb.eu könnte sich ein Endgerät im vierten Stock melden.
Es muß etwas mit Abwärtskompatibilität zu tun haben, daß jedenfalls die Deutsche Telekom einen vergleichbaren service bis dato nicht anbietet. Um diese simple Idee zu realisieren, bedurfte es erst des Computernetzwerks Internet. Bis heute ist jeder teilnehmende Computer mit einer weltweit eindeutigen IP-Adresse in Form einer 32 bit umfassenden Nummer identifizierbar. Diese Nummern, Telefonnummern vergleichbar, werden in vier Blocks zu je acht bit (also je einem Byte) notiert. So benutzt zum Beispiel mein privater Rechner die IP-Nummer 160.45.216.89, wenn er über die FU Berlin ans Internet angeschlossen ist. Um alle services des Internet ohne Einschränkungen nutzen zu können, bedarf es einer solchen ,,echten`` IP-Adresse.
Die Ursprünge der Idee, diesen schwer zu merkenden Nummern Namen zuzuordnen, reichen bis in die Frühgeschichte des Internet zurück. Bereits RFC 226 vom 20. September 1971 befaßt sich mit der Standardization of host mnemonics (Karp [1971]). In dichter Folge diskutieren Requests for Comments (RFCs) dann im Herbst 1971 die Grundfragen der Namensgebung.
Das bis heute existente Network Information Center (NIC) registriert zu jener Zeit die Namen sämtlicher am Internet-Vorgänger ARPANET teilnehmenden Maschinen in einer inzwischen legendären Datei namens HOSTS.TXT. Diese Datei laden Administratoren vor Ort regelmäßig (via FTP) herunter. Um die IP-Nummern von Netzrechnern herauszufinden, genügt mithin ein einfacher Blick in ein ASCII-file.
Mit dem Wachstum des Netzwerks steigt die Last auf den NIC-Computern: Das hosts file muß in immer kürzeren Abständen aktualisiert werden, und außerdem entstehen Namenskonflikte: Angenommen, am MIT in Cambridge würde ein Rechner ghost genannt. Nun käme aber an der University of Southern California ein Administrator auf die Idee, eine Maschine ebenfalls ghost zu nennen. Vom NIC erfährt er, daß dieser Name schon besetzt ist, und sucht einen anderen. Irgendwann sind keine sinnvollen Namen mehr frei. Was dann?
Der Namensraum (namespace) muß also in irgendeiner Weise hierarchisch strukturiert werden. Mehrteilige Rechnernamen würden das Problem lösen. Im September 1981 - gerade sind die beiden bis heute gültigen RFCs zum Internet Protocol (IP) und Transmission Control Protocol (TCP) erschienen - schlägt D. L. Mills [1981] in RFC 799 ein Konzept der Name Domains vor. Zu diesem Zeitpunkt stehen mehr als vierhundert Namen und Spitznamen (nicknames) in den Tabellen. Jeder am Netz teilnehmende Rechner muß eine Kopie dieser Tabelle haben.
Um zum Beispiel email zu verschicken, reicht bis dahin eine Adressierung an <user>@<host> (<benutzer>@<rechner>), also zum Beispiel mr94@duplox. Im August 1982 führt RFC 819 die neue Namenskonvention ein (Su & Postel [1982]): Künftig müssen fully qualified domain names (FQDN) zur Adressierung bestimmter Rechner verwendet werden. Hinter dem host-Anteil jeder Mailadresse wird eine weltweit eindeutige domain ergänzt; aus mr94@duplox wird also mr94@duplox.wzb.eu. Ähnliches gilt für die anderen Dienste wie FTP: Alle Rechner im Internet sollen künftig mit ,,vollem Namen`` angesprochen werden.
Dieser Konvention liegt die Abstraktion eines nach administrativen Kriterien baumartig strukturierten Namensraums zugrunde: Von links nach rechts schreitet die Adresse von der kleinsten Einheit (der individuellen mailbox) zur allgemeinsten Ebene fort, der Wurzel des Baumes, dem ,,administrative universe`` (RFC 819). Der bislang flache Namensraum erhält auf diese Weise eine neue Dimension. Eine domain, auch als DNS zone bezeichnet, wird als Bereich verstanden, in dem die lokalen Administratoren selbständig die Zuordnung von Namen zu Rechnern und IP-Adressen verwalten.
Diese Struktur soll es erlauben, die Autorität der Namensgebung zu dezentralisieren. Ein neuer Dienst, der name service, soll diese Konvention in Form von software realisieren. Für jede domain sollen name server installiert werden, die automatisch für die Übersetzung von Namen in IP-Adressen sorgen - die Grundidee des Domain Name Service (DNS) ist geboren; RFC 830 führt sie weiter aus (Su [1982]).
Am 4. Oktober 1983 wird der militärische Zweig des Internet, das MILNET, vom ARPANET abgespalten. RFC 881 erscheint am 1. November und schlägt einen Zeitplan für den Übergang zum neuen System vor (Postel [1983]). Am 16. November werden in einem ersten Schritt des Übergangs die mehr als vierhundert Rechnernamen im ARPANET mit dem provisorischen Suffix .ARPA (für ARPANET) versehen. Die neue Tabelle heißt DHOSTS.TXT. Vom 14. März 1984 an benutzen alle Rechner die Namen neuen Stils als offizielle und primäre Namen. DHOSTS.TXT wird in HOSTS.TXT umbenannt, die alte Tabelle in OHOSTS.TXT (vgl. RFC 921, Postel [1984]).
Mit .ARPA ist die erste top level domain (TLD) eingerichtet. Sie soll im Laufe des Jahres 1984 durch weitere domains abgelöst werden: Jeder Rechner muß dazu einer der neuen second level domains (SLD) zugeordnet werden, bevor er seinen provisorischen .ARPA-Namen aufgeben kann. Die provisorische TLD .ARPA führt bis heute ein Eigenleben mit der SLD in-addr.arpa: Unterhalb von in-addr.arpa werden die DNS-Einträge für das reverse-mapping angelegt, mit dessen Hilfe gegebene IP-Adressen in Netznamen umgesetzt werden können. Die IP-Adresse 160.45.216.89 kann auf diese Weise einem konkreten Rechnernamen zugeordnet werden:
; <<>> DiG 2.2 <<>> 89.216.45.160.in-addr.arpa any ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 4, Addit: 4 ;; QUESTIONS: ;; 89.216.45.160.in-addr.arpa, type = ANY, class = IN ;; ANSWERS: 89.216.45.160.in-addr.arpa. 259200 PTR mr94.dialup.fu-berlin.de. ;; AUTHORITY RECORDS: 216.45.160.in-addr.arpa. 259200 NS pascal.zedat.fu-berlin.de. 216.45.160.in-addr.arpa. 259200 NS ns1.fu-berlin.de. 216.45.160.in-addr.arpa. 259200 NS ns2.fu-berlin.de. 216.45.160.in-addr.arpa. 259200 NS ns3.fu-berlin.de. ;; ADDITIONAL RECORDS: pascal.zedat.fu-berlin.de. 86400 A 160.45.10.6 ns1.fu-berlin.de. 86400 A 160.45.8.8 ns2.fu-berlin.de. 86400 A 160.45.10.12 ns3.fu-berlin.de. 86400 A 130.133.1.57 ;; Total query time: 141 msec ;; FROM: mr94 to SERVER: default -- 127.0.0.1 ;; WHEN: Wed May 7 15:38:20 1997 ;; MSG SIZE sent: 44 rcvd: 250
Heftige Diskussionen führen dazu, daß der Zeitplan nicht eingehalten werden kann. Umstritten ist, unter welchen Bedingungen neue domains im allgemeinen und neue top level domains im besonderen eingerichtet werden sollen. In den Debatten jener Zeit bildet sich das ,,klassische`` Verständnis von domains (siehe Abschnitt 3.3) im frühen Internet heraus, das bis heute nachwirkt. Erst im Oktober 1984 erscheint mit RFC 920 (Postel & Reynolds [1984]) ein Dokument, das die fünf neuen TLDs festlegt und wie folgt definiert:
GOV = Government, any government related domains meeting the
second level requirements.
EDU = Education, any education related domains meeting the
second level requirements.
COM = Commercial, any commercial related domains meeting the
second level requirements.
MIL = Military, any military related domains meeting the
second level requirements.
ORG = Organization, any other domains meeting the second
level requirements.
Zusätzlich sollen die im ISO-Standard ISO-3166 definierten, zweibuchstabigen Ländercodes als TLDs für andere Länder Verwendung finden. Als RFC 920 erscheint, gibt es noch keine einzige zweibuchstabige TLD.
Als Kompromiß wird in RFC 920 fixiert, daß für multiorganizations eigene TLDs etabliert werden können: ,,A multiorganization may be a top level domain if it is large, and is composed of other organizations; particularly if the multiorganization can not be easily classified into one of the categories and is international in scope.`` Jedoch sind trotz dieser Regel bis heute keine neuen TLDs für ,,Multi-Organisationen`` eingerichtet worden, mit Ausnahme der TLD .NATO, die allerdings unbenutzt ist. Neue TLDs müssen ,,specially authorized`` werden, wie es in RFC 920 vage heißt, und sollen nur für domains mit mehr als 500 hosts eingerichtet werden.
Später entstanden die iTLDs .NET - für die Computer der Internet Service Providers (ISPs) - und .INT für internationale Organisationen und Datenbanken (RFC 1591, Postel [1994]). RFC 1591 bezeichnet .GOV und .MIL als ,,United States Only Generic Domains``. Im übrigen stellt er - wir schreiben das Jahr 1994! - lakonisch fest: ,,It is extremely unlikely that any other TLDs will be created.``
Das Ringen um policies für den Umgang mit dem neuen Namensraum kann die technische Implementierung des name service nicht aufhalten: Bis September 1984 werden die ersten domain name servers in Betrieb genommen, einer davon beim NIC. Bis zum Sommer 1985 sollen alle Programme, die hostnames in IP-Adressen umsetzen, mit Namen im domain style umgehen können.
Im September 1985 gibt das Network Information Center seine bisherige Rolle auf und registriert fortan nicht mehr jeden am Netz teilnehmenden Rechner, sondern nur noch neue SLDs für die von ihm verwalteten TLDs. (Für das MILNET/DDN hält das NIC vorerst weiterhin eine vollständige Host-Tabelle vorrätig.) Neue domains werden seit dem 15. Januar 1985 registriert.
Im Kern ist der Domain Name Service eine verteilte Datenbank (vgl. für eine allgemeinverständliche Darstellung Barkow [1996]; für eine kompakte technische Bedienungsanleitung RFC 1033, Lottor [1987]). Die einzelnen Elemente sind über Tausende von name servers verteilt, die jeweils Informationen für einen Zweig des Netzes bereithalten. An der Wurzel des hierarchischen Baumes stehen die root servers, die Informationen über die top level domains enthalten. Diese Informationen bilden die root zone des DNS. Für jede TLD sind darin authoritative name servers benannt, die wiederum sämtliche second level domains ihrer TLD kennen müssen, also vor allem deren jeweilige lokale name servers.
Der DNS beruht auf verteilter Autorität: Jeder name server besitzt die Autorität für eine bestimmte Zone des Namensraums. Die Autorität für die Wurzel (,,.``) ist dabei in gewisser Weise die Zentralgewalt über den Namensraum, von der aus die Verantwortung für die einzelnen Äste delegiert wird - Delegation von Verantwortung ist ein Grundprinzip des DNS wie auch des Internet insgesamt.
Der Administrator von wzb.eu kann den Namensraum seiner domain, also seines Autoritätsbereiches, eigenständig verwalten. Er betreibt den lokal zuständigen name server artemis.wzb.eu und trägt dort die Rechnernamen wie duplox.wzb.eu mit ihren IP-Adressen ein. Es steht ihm auch frei, weitere domains auf der dritten Ebene einzurichten und deren Verwaltung zu delegieren. So könnte vielleicht die Projektgruppe ,,Kulturraum Internet`` eine eigene, selbstverwaltete third level domain erhalten, sollte dafür Bedarf sein.
Während die name servers für .de beim deutschen Network Information Center (DE-NIC) also für jeden wzb.eu-Rechner einfach auf den name server artemis.wzb.eu verweisen, kann jener autoritative Auskünfte über alle lokalen Rechner geben: Was artemis sagt, das gilt.
; <<>> DiG 2.2 <<>> @artemis.wzb.eu duplox.wzb.eu ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 1, Addit: 1 ;; QUESTIONS: ;; duplox.wzb.eu, type = A, class = IN ;; ANSWERS: duplox.wzb.eu. 172800 A 192.108.68.221 ;; AUTHORITY RECORDS: wzb.eu. 172800 NS artemis.wzb.eu. ;; ADDITIONAL RECORDS: artemis.wzb.eu. 172800 A 192.108.68.7 ;; Total query time: 191 msec ;; FROM: mr94 to SERVER: artemis.wzb.eu 192.108.68.7 ;; WHEN: Thu May 8 18:50:50 1997 ;; MSG SIZE sent: 37 rcvd: 103
Seine Informationen bewahrt er in mindestens einem resource record (RR) pro Rechner auf. Auf eine Anfrage gibt der name server typischerweise den host name, die IP-Adresse und die IP-Adressen der zuständigen autoritativen name servers zurück. Es ist üblich, aus Gründen der Performanz, aber auch der Ausfallsicherheit mehrere name servers vorzuhalten. Einer dieser server stellt dann als primary server die Referenzdaten für einen oder mehrere secondary servers zur Verfügung; diese Daten werden in regelmäßigen Abständen synchronisiert.
Für den Endnutzer übernimmt ein resolver die Arbeit des Abfragens. Der Bequemlichkeit halber ist das meist ein lokaler name server, der gleichzeitig als resolver agiert und oftmals seinerseits andere name servers innerhalb des gleichen lokalen Netzwerks befragt, die unter Umständen ihrerseits weitere lokale name servers zu Rate ziehen. Dieser rekursive Arbeitsmodus kann im Prinzip über mehrere, hierarchische Stufen hinweg betrieben werden, um zum Beispiel eine zentrale Zwischenspeicherung (caching) solcher Abfrageresultate zu realisieren.
Nach außen hin regiert dagegen ein iterativer Modus: Der lokale name server, in seiner Rolle als resolver, kontaktiert zunächst einen der root servers an der Wurzel des Namensraums, wenn er eine IP-Adresse ermitteln soll. Weiß dieser nicht Bescheid, gibt er die Adresse eines weiteren, zuständigen name servers auf der zweiten Ebene des Namensraums zurück, der unter Umständen auf einen name server der dritten Ebene verweist, und so fort. Auf diese Weise kommt der lokale resolver irgendwann in Kontakt mit seinem tatsächlich zuständigen name server-Kollegen.
Allerdings nur dann, wenn er die gesuchte Adresse nicht ohnehin schon im lokalen Zwischenspeicher (cache) hat, weil sie gerade erst abgefragt wurde. Denn um die Performanz zu verbessern und unnötige Abfragen quer durch die halbe Welt zu vermeiden, speichert jeder resolver die Resultate der letzten Abfragen. Jeder DNS-Eintrag hat daher einen time-to-live-Wert (TTL). Nach Ablauf dieser Zeit werden die Einträge aus dem lokalen cache gelöscht. artemis.wzb.eu benutzte im November 1996 einen Wert von 604.800 Sekunden, also sieben Tagen.
Das Design der verteilten Datenbank des DNS ist prinzipiell beliebig erweiterbar. So lassen sich neben der resolver-Funktion für die Netznamen auch Informationen zu anderen Netzdiensten im DNS vorhalten. Die Erweiterbarkeit des DNS-Konzepts spielt eine wichtige Rolle in den Planspielen, mit denen derzeit an der Zukunft dieses essentiellen Internet-Dienstes gearbeitet wird.
Zu den wichtigsten Funktionen im DNS-Alltag gehört die Organisation des Mailverkehrs mittels MX-Einträgen. MX steht für Mail Exchanger und bezeichnet die Rechner, an die email für die domain zugestellt werden kann. Neben den Postrechnern vor Ort gibt es häufig weitere, oft sogar netztopologisch weit entfernte Ersatzmaschinen in anderen domains, die im Notfall den elektronischen Postverkehr übernehmen.
; <<>> DiG 2.2 <<>> fu-berlin.de mx ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; Ques: 1, Ans: 5, Auth: 5, Addit: 9 ;; QUESTIONS: ;; fu-berlin.de, type = MX, class = IN ;; ANSWERS: fu-berlin.de. 86400 MX 30 methan.chemie.fu-berlin.de. fu-berlin.de. 86400 MX 100 mail.cs.tu-berlin.de. fu-berlin.de. 86400 MX 150 arbi.Informatik.Uni-Oldenburg.de. fu-berlin.de. 86400 MX 10 ki1.chemie.fu-berlin.de. fu-berlin.de. 86400 MX 20 leibniz.math.fu-berlin.de. ;; AUTHORITY RECORDS: fu-berlin.de. 86400 NS ns1.fu-berlin.de. fu-berlin.de. 86400 NS ns2.fu-berlin.de. fu-berlin.de. 86400 NS ns3.fu-berlin.de. fu-berlin.de. 86400 NS arbi.Informatik.Uni-Oldenburg.de. fu-berlin.de. 86400 NS deneb.dfn.de. ;; ADDITIONAL RECORDS: methan.chemie.fu-berlin.de. 259200 A 160.45.22.81 mail.cs.tu-berlin.de. 25685 A 130.149.17.13 arbi.Informatik.Uni-Oldenburg.de. 66483 A 134.106.1.7 ki1.chemie.fu-berlin.de. 259200 A 160.45.24.21 leibniz.math.fu-berlin.de. 86400 A 160.45.40.10 ns1.fu-berlin.de. 86400 A 160.45.8.8 ns2.fu-berlin.de. 86400 A 160.45.10.12 ns3.fu-berlin.de. 86400 A 130.133.1.57 deneb.dfn.de. 39240 A 192.76.176.9 ;; Total query time: 87 msec ;; FROM: mr94 to SERVER: default -- 127.0.0.1 ;; WHEN: Wed May 7 15:57:43 1997 ;; MSG SIZE sent: 30 rcvd: 427
Unterhalb der meisten TLDs hat sich ein flacher Namensraum herausgebildet: Organisationen registrieren ihre domains direkt unterhalb der TLD; so ist zum Beispiel auch wzb.eu direkt unterhalb von .de registriert. In einigen der zweibuchstabigen ISO-3166-TLDs ist es gelungen, generische SLDs mit zum Teil eigenen Registraturen einzurichten. So hat .uk (siehe http://www.nic.uk/) die subdomains co.uk (commercial zone), org.uk (non-commercial organisations), ac.uk (academic zone), gov.uk (governmental zone), police.uk (police zone), sch.uk (schools), mod.uk (Ministry of Defense), nhs.uk (National Health Service), net.uk (internet networks) und neuerdings ltd.uk (company names registered under the Companies Act with Company's House) sowie pcl.uk (public limited companies). .uk entspricht, als eine nur historisch zu erklärende Ausnahme, nicht dem zweibuchstabigen ISO-3166-Code für das Vereinigte Königreich ,,gb``.
In den USA ist die Nutzung der landeseigenen ISO-3166-domain .us weitgehend fehlgeschlagen oder zumindest deutlich hinter der Nachfrage nach den generischen (häufig auch als ,,international`` bezeichneten) TLDs zurückgeblieben. Die US Domain Registry, betrieben vom Information Sciences Institute (ISI) der University of Southern California, hat ein differenziertes Namensschema entwickelt. Der Namensraum unterhalb .us basiert auf der politischen Geographie der USA und verwendet die Staatenkürzel des US Postal Service. Daneben gibt es eine Reihe von speziellen SLDs wie fed.us oder state.us. Die dritte Ebene bilden die lokalen Ortsnamen.
Firmen wie Microsoft hätten demnach ihre .us-domain als Microsoft.Redmond.WA.US zu registrieren. Das hat Microsoft zwar auch getan, für die Alltagsnutzung zieht die Firma jedoch die leichter zu merkende domain microsoft.com vor. In der .us-TLD waren, Ausweis des Mißerfolgs, im Januar 1997 nur 15.086 domains aktiv, während es allein in .com 507.513 domains gab. Sogar .de, die TLD des im Vergleich zu den USA kleinen und nach Internet-Maßstäben rückständigen Deutschlands, kam auf immerhin 28.071 domains - nahezu eine Verdoppelung gegenüber dem Juli 1996 (vgl. die Internet Domain Survey der Network Wizards auf http://www.nw.com/; die Zahlen sind Netto-Zahlen, registrierte, aber nicht erreichbare domains wurden nicht mitgezählt; eine Tabelle ist im Anhang B enthalten).