Wie DNS entstand: HOSTS.TXT und die Lehren des Papers von 1988

Einen Namen einzutippen und eine Adresse zurückzubekommen fühlt sich an wie eine Eigenschaft des Internets selbst. Tatsächlich ist es ein Dienst, den jemand entwerfen musste, und die Beteiligten haben ungewöhnlich offene Aufzeichnungen darüber hinterlassen, was funktionierte und was nicht. Dieser Artikel folgt dem System von der gemeinsamen Datei, die ihm voranging, bis zu dem Paper von 1988, in dem seine Entwickler ihre eigene Arbeit überprüften, und hebt die Lehren hervor, die für jeden gelten, der DNS betreibt.

Eine Datei für alle Hosts

Vor DNS lag die Zuordnung von Hostnamen zu Adressen in einer einzigen Textdatei namens HOSTS.TXT. Sie wurde zentral beim SRI Network Information Center (SRI-NIC) gepflegt und per Dateiübertragung an die Hosts verteilt. RFC 952, 1985 veröffentlicht, ist die offizielle Spezifikation des Formats dieser Datei und besagt, dass sie per FTP von SRI-NIC abgerufen werden konnte.

Mit dem Wachstum des Netzes geriet das Verfahren unter Druck. Schon im September 1981 stellte David Mills in RFC 799 fest, dass die kombinierten Tabellen von ARPANET und DCNET bereits über vierhundert Namen und Spitznamen enthielten, und er schlug vor, Namen in Namensdomänen aufzuteilen, mit einer Hierarchie als erklärtem Ziel. Die tieferen Gründe liefert das Paper von Mockapetris und Dunlap von 1988. Die Datei wuchs mit der Zahl der Hosts, die nun in Workstations statt in Timesharing-Systemen gezählt wurden, und die Gesamtkosten ihrer Verteilung wuchsen sehr viel schneller als linear; RFC 1034 setzt sie proportional zum Quadrat der Zahl der Hosts an. Und eine einzelne Kontrollinstanz passte nicht mehr dazu, wie Organisationen ihre eigenen Netze verwalteten.

Von Hostnamen zu Domains

RFC 819 (1982) von Zaw-Sing Su und Jon Postel beschrieb den Wandel bei der Namensgebung: Der einfache Hostteil einer E-Mail-Adresse sollte zu einer zusammengesetzten Domain werden, sodass aus Fred@ISIF Fred@F.ISI.ARPA wurde. Die Namen sollten einen Baum bilden, der der Verwaltungsstruktur folgt statt der Netztopologie. Im November 1983 veröffentlichte Paul Mockapetris die erste DNS-Spezifikation als RFC 882 (Konzepte) und RFC 883 (Implementierung). RFC 920 (1984) legte die ersten Top-Level-Kategorien GOV, EDU, COM, MIL und ORG fest und sah zweistellige Ländercodes vor. Die Spezifikation wurde im November 1987 überarbeitet und als RFC 1034 und RFC 1035 zusammengeführt, die bis heute die Basisdokumente des Protokolls sind.

Entwurfsentscheidungen, die man heute noch sieht

Die Autoren nennen ihre Ausgangsannahmen offen: DNS musste mindestens die Informationen tragen, die HOSTS.TXT trug, die verteilte Pflege der Datenbank ermöglichen, keine offensichtlichen Größenbeschränkungen auferlegen, in vielen Umgebungen funktionieren und eine erträgliche Leistung bieten. Mehrere Entscheidungen folgen daraus, und das Paper hält fest, warum jede getroffen wurde.

Was die Autoren überraschte

Der Abschnitt des Papers über Überraschungen ist für Betreiber am nützlichsten. Die Netzwerkleistung blieb weit hinter den Erwartungen zurück. Die TOPS-20-Root-Server konnten die meisten Abfragen in unter 100 Millisekunden verarbeiten, doch Clients sahen selbst beim nächstgelegenen Root-Server 500 Millisekunden bis 5 Sekunden, und Abfragen vom ARPANET an delegierte Domains dauerten zu Spitzenzeiten 3 bis 10 Sekunden, mit 30 bis 60 Sekunden als gelegentlichem Worst Case.

Negative Antworten waren die dritte der Überraschungen des Papers, und sie zu cachen ist der erste Ratschlag in seinen Schlussfolgerungen. Die Entwickler hatten erwartet, dass negative Antworten, sowohl „kein solcher Name“ als auch „keine solchen Daten“, selten sein würden. Frühe Messungen an Root-Servern ergaben, dass 20 bis 60 Prozent der Antworten negativ waren, viele davon von Programmen, die Hostnamen im alten Stil verwendeten, und von Mailsystemen, die prüften, ob eine Adresse gültig war. Selbst nach Korrekturen blieben negative Antworten zwischen 10 und 50 Prozent, typischerweise um 25 Prozent, weil Programme, die mehrere Namen aus einer Suchliste ausprobierten, einen steten Strom ungültiger Namen erzeugten. Ihre Schlussfolgerung lautete, dass jedes Namenssystem, das sich für die Leistung auf Caching stützt, womöglich auch negative Ergebnisse cachen muss. RFC 2308 (1998) ersetzte das optionale Schema in RFC 1034 und machte Negative Caching zu einem verpflichtenden Bestandteil cachender Resolver; deshalb scheitert ein falsch geschriebener Name aus dem Cache eines Resolvers weiterhin schnell. Siehe NXDOMAIN erklärt.

Ebenso offen waren die Autoren bei den menschlichen Faktoren. Die Beispiel-TTL-Werte der Dokumentation entsprachen einer Stunde und wurden überall kopiert, während der Text, der einige Tage empfahl, ignoriert wurde; ihre empfohlene TTL für Hostnamen war zwei Tage. Administratoren bevorzugten kurze TTLs, damit Änderungen schnell wirksam würden, selbst wenn Änderungen selten waren. Ein Administrator vertauschte TTL- und Datenwerte und verteilte fehlerhafte Daten mit einer TTL von mehreren Jahren. Und die frühe Politik, eine Domain an jede Organisation zu delegieren, die ein Formular mit redundanten Servern ausfüllte, war ein Fehler: Sie schrieben, sie hätten von Organisationen verlangen sollen, redundante Server mit echten Daten nachzuweisen, bevor delegiert wird, und hätten wahrscheinlich darauf bestehen sollen, dass die Server in verschiedenen Netzwerken stehen.

Wie groß es 1988 war

• Bis März 1988 waren mehr als 650 Domains delegiert worden: etwa 400 gewöhnliche organisatorische Namensräume und etwa 250 Netzwerkadressräume unter IN-ADDR.ARPA.
• Eine aktuelle Messung zählte etwa 5.500 Hostnamen in HOSTS.TXT gegenüber mehr als 20.000, die über DNS erreichbar waren.
• Der Namensraum hatte etwa 30 Top-Level-Domains, die meisten Hosts lagen unter sechs organisatorischen.
• Sieben redundante Root-Server stützten die Spitze des Baums, drei auf TOPS-20-Systemen und vier auf UNIX, die jeweils typischerweise etwa eine Abfrage pro Sekunde sahen.

Warum es noch wichtig ist

Drei Punkte des Papers sind aktueller operativer Rat. Eine TTL ist ein Kompromiss zwischen der Geschwindigkeit, mit der sich Änderungen ausbreiten, und der Entlastung und Ausfallsicherheit, die Caching bietet; siehe DNS-TTL erklärt. Negative Antworten werden ebenfalls gecacht, sodass ein Record, den Sie gerade angelegt haben, nach einem fehlgeschlagenen Lookup eine Weile unsichtbar bleiben kann. Und die Größenbeschränkung für Datagramme prägte das Protokoll jahrzehntelang, bis EDNS(0) und die Pflicht zur TCP-Unterstützung sie veränderten; Aufbau einer DNS-Nachricht behandelt diese Geschichte. Das eigene Urteil der Autoren lautete, dass der Bedarf an verteilter Funktionalität ihrer Überzeugung nach unabwendbar sei und dass dieser Bedarf zusammen mit der neuen Funktionalität und den Möglichkeiten für künftige Dienste DNS rechtfertige, wenngleich sie einräumten, dass es die gemeinschaftsweite Last bei Verwaltung, Kommunikation oder Support wahrscheinlich noch nicht verringert habe.

Quellen und weiterführende Literatur

• Paul V. Mockapetris and Kevin J. Dunlap, Development of the Domain Name System, Proceedings of SIGCOMM '88, Computer Communication Review 18(4), 1988, pp. 123-133
• RFC 799: Internet Name Domains (Mills, 1981)
• RFC 819: The Domain Naming Convention for Internet User Applications (Su and Postel, 1982)
• RFC 882: Domain Names - Concepts and Facilities (Mockapetris, 1983)
• RFC 883: Domain Names - Implementation and Specification (Mockapetris, 1983)
• RFC 920: Domain Requirements (Postel and Reynolds, 1984)
• RFC 952: DoD Internet Host Table Specification (Harrenstien, Stahl and Feinler, 1985)
• RFC 1034: Domain Names - Concepts and Facilities (Mockapetris, 1987)
• RFC 1035: Domain Names - Implementation and Specification (Mockapetris, 1987)
• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) (Andrews, 1998)
• Paul Albitz and Cricket Liu, DNS and BIND, 5th edition (O'Reilly, 2006)