Summary

  • Berkeleys technischer Bericht von 1984 beschrieb BIND als Namensdienst für verteilte Unix-Umgebungen. Er beanspruchte weder die Erfindung von DNS noch den ersten DNS-Server.
  • 1987 dokumentierten Betriebshandbücher BIND als Teil der 4.3BSD-Distribution. Zwei Jahre später beschrieb ein Internet-Leitfaden den Dienst als in 4.3BSD integriert und als Ersatz für die Namenssuche über /etc/hosts.
  • Die Veränderung war praktischer Art: Die Spezifikationen legten gemeinsames Verhalten fest; Softwareverteilung und lokal gepflegte Zonen ermöglichten Administratoren, Namen im eigenen Netz bereitzustellen.

Eine Spezifikation allein beantwortete keine Anfrage

Ein Namenssystem kann auf dem Papier elegant sein und trotzdem den Alltag nicht verändern. Jemand muss den Server installieren, Daten eintragen, sie aktuell halten und lokale Programme an den passenden Resolver verweisen. Berkeleys Beitrag zum entstehenden DNS bestand darin, diesen Betrieb in die Unix-Umgebung einzupassen.

1984 veröffentlichten Douglas Terry, Mark Painter, David Riggle und Songnian Zhou einen technischen Bericht über den Berkeley Internet Name Domain Server. Die Zusammenfassung beschreibt ein gemeinsames Verfahren, Ressourcen in verteilten Unix-Systemen zu benennen und Informationen zu speichern und abzurufen. Der hierarchische Namensraum ist in Domains aufgeteilt, die administrative Einheiten widerspiegeln. Das ist ein Software- und Betriebsmodell, kein Anspruch auf die Erfindung von DNS.

Paul Mockapetris hatte mit Jeeves bereits einen früheren Server für USC-ISI und SRI-NIC geschrieben; die spätere ISC-Chronik trennt diesen von Berkeleys Projekt.

Die praktische Frage von BIND lautete, wie ein Unix-Rechner an einem Namenssystem teilnehmen konnte, dessen Daten auf mehrere Verwaltungsbereiche verteilt waren. Die Antwort verband Server, lokale Dateien und den vorhandenen Namensauflösungspfad des Hosts. Der Administrator einer Domain pflegte die Einträge für seinen Teil des Baums; Resolver fragten zuständige Server ab und speicherten Antworten zwischen. „Verteilt“ bedeutete, dass Daten und Verantwortung verteilt waren, nicht dass jeder Benutzer die Standorte aller Rechner kennen musste.

Das laufende Netz veränderte die Spezifikation

Die Reihenfolge ist entscheidend. Die frühen DNS-Beschreibungen erschienen 1983 in RFC 882 und RFC 883. Im Januar 1986 hielt RFC 973 von Paul Mockapetris bereits Änderungen, Betriebshinweise, beobachtete Probleme und Lücken des damals laufenden Systems fest. Weit verbreitete Änderungen sollten als Teil der Spezifikation gelten. Erfahrungen aus Implementierung und Betrieb flossen also zurück in den Protokolltext.

Die überarbeiteten Dokumente RFC 1034 und RFC 1035 erschienen im November 1987. Sie beschrieben Konzepte und Implementierungsdetails von DNS. Gemeinsame Regeln für Namen, Ressourceneinträge, Abfragen, Caches und Delegationen waren für die Interoperabilität nötig. Die RFCs waren jedoch keine Software, die ein Administrator installieren konnte. Dafür brauchte es ein Programm und eine Betriebsanleitung.

Der Berkeley-Bericht von 1984 positioniert BIND als Dienst für verteilte Unix-Ressourcen. Die BIND-Chronik des ISC nennt das ursprüngliche Team und berichtet, dass die Computer Systems Research Group die Software bis Version 4.8.3 pflegte. Diese rückblickende Darstellung belegt eine Entwicklungslinie, aber keine Zahl installierter Systeme je Version.

Mit BSD ausgeliefert und für Administratoren greifbar

Ein zeitgenössischer Hinweis steht in RFC 1033, dem im November 1987 veröffentlichten Betriebsleitfaden für Domains. Ein Anhang trägt ausdrücklich die Überschrift „BIND ... distributed with 4.3 BSD UNIX“. Er erläutert BIND-spezifische Start- und Cachedateien, darunter named.boot, und zeigt Zonendaten. Er behauptet nicht, dass jede BSD-Installation einen Nameserver betrieb. Er zeigt, dass Administratoren BIND mit einer vertrauten Unix-Distribution erhalten und Hinweise zur Konfiguration finden konnten.

Diese Paketierung senkte die Hürde für einen Versuch. Ein Administrator musste keinen DNS-Server schreiben, bevor er eine Domain einrichten konnte. Eine Startdatei konnte den Server initialisieren, Zonendaten laden und lokale Anfragen beantworten; für Namen außerhalb der eigenen Zuständigkeit fragte er andere Server. Die Daten mussten weiterhin stimmen, Delegationen mit der übergeordneten Domain übereinstimmen und Änderungen sauber gepflegt werden. BIND lieferte ein laufendes Werkzeug, aber keine Garantie für korrekte Einträge.

Die konkreteste zeitgenössische Beschreibung folgte zwei Jahre später. In RFC 1118 schrieb Ed Krol, BIND sei in 4.3BSD integriert und werde zum Nachschlagen und Speichern von Hostnamen, Adressen, Mailservern und weiteren Informationen verwendet. Damit habe es die Namenssuche über /etc/hosts ersetzt. Sein Beispiel der University of Illinois at Urbana-Champaign zeigt den Größenunterschied: In der von SRI verteilten Hosttabelle standen nur wenige Rechner; die meisten Namen der Universitätsdomain lagen in lokalen BIND-Tabellen. Andere Hosts mit BIND oder einem beliebigen DNS-Resolver konnten sie dennoch abfragen.

Das war keine Wahl zwischen einer zentralen Datenbank und fehlender Koordination. SRI verteilte weiterhin eine Hosttabelle; DNS gab Institutionen zusätzlich die Möglichkeit, einen größeren Namensraum lokal zu pflegen und über gemeinsame Abfrageregeln bereitzustellen. RFC 1118 erwähnt auch Mail-Routing-Informationen für interne Hosts, die nicht direkt über IP erreichbar waren, darunter Rechner mit UUCP-Anschluss. Der Servicename konnte bestehen bleiben, wenn sich der physische oder netztechnische Standort eines Hosts änderte.

Was lokal wurde und was gemeinsam blieb

Die Betriebsgrenze war konkreter, als das Wort „verteilt“ oft vermuten lässt. Berkeley und spätere Maintainer verteilten Software. Protokolldokumente beschrieben gemeinsames Verhalten. Die Administratoren jeder Domain kontrollierten die Einträge ihres Bereichs. Resolver und Server bearbeiteten Anfragen. Keine dieser Ebenen ersetzte die anderen. Eine veraltete Zone konnte konsistente, aber falsche Antworten geben; widersprüchliche Delegationen konnten Namen unerreichbar machen, obwohl BIND lief.

Heng Lus spätere Betonung laufenden Codes ist hier eine Analysefrage, keine Aussage über die Absicht der BIND-Autoren: Was bekam ein Administrator tatsächlich, und was tat er damit? Die Quellen zeigen eine Folge vom Entwurfsbericht über ein durch Betriebserfahrung angepasstes System bis zu Software in 4.3BSD und lokal gepflegten Namen. Die Veröffentlichung war wichtig, füllte aber weder die Zone einer Universität noch beantwortete sie Anfragen ihrer Nutzer.

Auch die Belege haben Grenzen. RFC 1033 dokumentiert die Verteilung mit 4.3BSD; RFC 1118 beschreibt die Integration und ein Universitätsbeispiel. Daraus folgen weder eine universelle Installation noch eine einzige Ursache für die Verbreitung von DNS oder das Ende sämtlicher Hostdateien. Die belastbare historische Aussage ist enger: BIND half dabei, DNS zu einem Unix-Dienst zu machen, den Administratoren selbst betreiben konnten. So konnte jede Domain ihren Bereich pflegen und zugleich mit dem übrigen Namensbaum interoperabel bleiben.

Quellen