Zusammenfassung

  • RFC 2219 bündelte die DNS-Namen, die Menschen und Programme bereits zur Suche nach Diensten ausprobierten. Ein beständiger Dienstname sollte so einen Serverumzug überdauern können.
  • Das Dokument benannte zugleich, was der Name nicht beweist: weder eine Adresse noch einen lauschenden Prozess, den erwarteten Port, die Annahme eines Clients oder ein vollständiges Diensteverzeichnis.

Der Name klang nach Zusage, die DNS-Antwort gab sie nicht

Wer www.example.org in den Browser eingibt, glaubt leicht, damit das Ziel zu kennen. Doch DNS kann ganz ohne Adresse antworten. Die Adresse kann zu einem Rechner ohne HTTP-Server führen; ein laufender Prozess kann einen anderen Port verwenden; und selbst ein erreichbarer Server darf eine konkrete Anfrage ablehnen. RFC 2219 machte diese Lücke im Oktober 1997 ausdrücklich sichtbar und versuchte, die Namen zu ordnen, die Nutzer längst zu erraten gelernt hatten.

Die Konvention hatte einen unmittelbaren Nutzen. Ohne Rechnernamen konnte man www, ftp oder mail ausprobieren. Ein Programm konnte dieselbe Vermutung anstellen. Für den Betreiber war wichtiger, dass der Dienstname stabil blieb, während sich Host oder Adresse änderten. Besucher mussten bei einem Umzug keinen neuen Namen lernen. RFC 2219 beschrieb die Indirektion als Möglichkeit, Dienste transparent zwischen Rechnern zu verschieben, und als Hinweis darauf, dass eine Organisation einen bestimmten Dienst anbieten könnte.

Das Dokument war eine Best Current Practice, weder ein neuer DNS-Ressourcentyp noch ein universelles Diensteregister. Die Autoren schrieben, die Namenskonventionen seien damals nahezu überall übernommen worden. Das ist ihre zeitgenössische Einschätzung, keine hier unabhängig erhobene Verbreitungszahl. Ihre Liste sammelte übliche Bezeichnungen wie www, ftp, gopher, ldap, mail, news, ntp, pop und whois. Für nicht aufgeführte Protokolle sollte deren Spezifikation einen Namen vorschlagen. Vereinheitlicht wurde das Vokabular, nicht ein Vorgang, der die tatsächliche Funktion hinter dem Wort überprüft.

Die Einschränkung war zentral, nicht beiläufig. Ein DNS-Eintrag namens www registriert keinen Webdienst. Er muss nicht zu einer IP-Adresse auflösen. Kein Host muss HTTP annehmen, und kein lauschender Prozess muss Port 80 verwenden. Selbst wenn all das zutrifft, muss der Server beliebige Clients nicht akzeptieren. RFC 2219 bezeichnete Aliase als nützliche „Hinweise“ und verlangte, sie auch so zu behandeln. Ein Eintrag in der DNS-Zone einer Organisation und das Verhalten ihres Dienstes sind unterschiedliche Belege.

Der Hinweis liegt außerdem später in der Suchkette, als der vertraute Name vermuten lässt. Zuerst muss jemand die Domain der Organisation kennen. RFC 2219 löst nicht, wie ein Programm diese Domain aus dem Namen einer Institution, ihrem Standort oder Geschäftsfeld ableiten soll. Auch Dienste mit zusätzlichen Parametern werden nicht abgedeckt. Als Beispiel nennt der Text LDAP: Für einen sinnvollen Dialog benötigt ein Client eine Suchbasis im Verzeichnisbaum. Ein Alias erleichtert den Weg zu einer bekannten Domain, macht DNS aber nicht zu einem allgemeinen Verzeichnis.

Der umziehende Name brachte Wartungsentscheidungen mit

RFC 2219 zeigt zwei Möglichkeiten, einen Dienstnamen zu veröffentlichen. Ein CNAME kann ph.example.org zum Alias für den kanonischen Rechnernamen machen. Beim Umzug müssen dessen Adressen dann nicht mehrfach gepflegt werden. Nach DNS-Regeln darf der Name mit dem CNAME jedoch keine weiteren Daten wie einen MX-Eintrag tragen. Alternativ lassen sich eine oder mehrere A-Adressen direkt unter dem Dienstnamen veröffentlichen. Die Adressen sind damit sichtbar, müssen aber mit den tatsächlichen Hosts abgeglichen werden. Das Dokument empfiehlt keine Form für alle: Entscheidend seien die Anforderungen der jeweiligen Site.

Die Bequemlichkeit erzeugt Betriebsaufwand. Ein Alias muss auf ein aktuelles Ziel zeigen und entfernt werden, wenn der Zielhost verschwindet. Ein veralteter Zeiger ist keine Zustandsprüfung. Bei direkten A-Einträgen muss jede Änderung der Maschinen auch die Adressmenge des Dienstnamens aktualisieren. Mehrere Adressen können Spiegelstandorte abbilden. DNS kann ihre Reihenfolge ändern; Clients können eigene Heuristiken einsetzen. Das beweist weder Erreichbarkeit noch Gleichheit der Systeme. RFC 2219 hält diese Anordnung nur dann für passend, wenn die Spiegel exakte Kopien sind.

Auch die Sicherheitswarnung folgt dieser Grenze. Eine DNS-Antwort lässt sich fälschen, um einen Dienst unerreichbar zu machen oder Nutzer zu einem Server umzuleiten, der den legitimen imitiert. Die Namenskonvention authentifiziert das Ziel nicht. Ein vertraut klingender Name ersetzt weder die Prüfung des Endpunkts noch den Schutz sensibler Kommunikation.

RFC 2219 räumte zudem ein, dass vertraute Aliase keine vollständige langfristige Lösung für die Suche nach einem bestimmten Dienst waren. Es verwies auf die Arbeit an Server Location Resource Records, damals RFC 2052. Die Reihenfolge ist wichtig: Der SRV-Vorschlag entstand vor RFC 2219; dieses nannte ihn als eigenständigen Ansatz für das größere Suchproblem. RFC 2782 löste RFC 2052 später ab und beschrieb Einträge mit Dienst, Protokoll, Priorität, Gewicht, Port und Ziel. Ob ein Client sie nutzt, muss dennoch die passende Anwendungsspezifikation vorgeben. Der spätere Standard machte www nicht rückwirkend zu einem Nachweis über die Registrierung eines Dienstes.

Der Beitrag von RFC 2219 war enger und belastbarer: Ein verständlicher Name kann eine Betreiberabsicht leichter auffindbar und einen Host leichter austauschbar machen. Das Dokument beanspruchte keine Autorität über die Tatsachen am anderen Ende. Der Zonenbetreiber veröffentlicht einen Hinweis; der Hostbetreiber kontrolliert den lauschenden Prozess; der Client muss weiterhin eine Verbindung aufbauen und die Antwort bewerten. Der symbolische Eingang lässt sich verschieben. Ob dort jemand antwortet, bleibt eine Betriebsfrage.

Quellen: RFC 2219; RFC-Editor-Eintrag zu RFC 2219; IETF Datatracker: BCP 17; RFC 1912; RFC 1034; RFC 1035; RFC 2052; RFC 2782; RFC 1123.