Zusammenfassung

  • RFC 1183 führte den RP-Eintrag als Vorschlag ein: Ein DNS-Name sollte einen Ansprechpartner für Störungen nennen können, der weder der Zonenverwalter noch der POSTMASTER des Geräts war.
  • RP enthielt eine Mailbox und einen Verweis auf mögliche TXT-Erläuterungen. Der Eintrag belegte eine veröffentlichte Kontaktadresse, keine zugestellte Meldung und keine Reparatur.

Das Gateway streikt. Die DNS-Zone antwortet weiter, und ihr SOA-Eintrag nennt einen Verantwortlichen. Wer dort hinschreibt, kann trotzdem beim falschen Schreibtisch landen. Der Zonenverwalter pflegt die Namensdatenbank; ein Defekt am Gateway gehört womöglich einer anderen Mannschaft. POSTMASTER hilft bei Mailproblemen und setzt voraus, dass die Maschine überhaupt Mail empfängt. Diese unangenehme Trennung beschrieb RFC 1183 im Oktober 1990.

Die Autoren schlugen den Resource Record „Responsible Person“, kurz RP, mit Typcode 17 vor. Ein Beispiel überschritt ausdrücklich eine Organisationsgrenze: Ein Gateway unter ISI.EDU könnte auf eine Hotline bei BBN.COM verweisen. Damit wechselte weder die Zone ihren Besitzer noch bekam die Hotline Schreibrechte im DNS. Der Datensatz sagte lediglich, welcher Kontakt bei einer Störung vermutlich nützlicher war als der formelle Verwalter des Namens.

Im Störungsfall hätte der Suchende zuerst den RP-Eintrag des betroffenen Namens gelesen. Dessen erstes Datenfeld nannte die Mailbox in der DNS-Schreibweise des SOA-Kontakts. Das zweite verwies auf einen TXT-Namen mit lesbaren Hinweisen; dafür konnte eine weitere DNS-Frage nötig sein. Mehrere Geräte durften dieselbe Beschreibung teilen. Eine zentrale Änderung half dann allen Geräten — oder verbreitete denselben falschen Hinweis an alle.

Der einzelne Punkt „.“ hatte eine praktische Bedeutung: Hier gab es keine Mailbox oder keine ergänzende TXT-Auskunft. Der Leser wusste, dass an dieser Stelle keine Adresse verborgen war. Mehrere RP-Einträge am selben Namen waren zulässig und sollten dieselbe TTL haben. Das Beispiel TRANTOR.UMD.EDU nannte vier Kontakte. Der Eintrag verteilte damit Hinweise an mehrere Menschen, legte aber keine Rangfolge fest, welcher von ihnen zuerst handeln musste.

RP konnte an jedem Knoten der DNS-Hierarchie stehen. Der Betreiber konnte den konkreten gestörten Namen abfragen, statt nur den Zonenverwalter am oberen Ende des Baums zu finden. Das machte eine andere Frage sichtbar: Wer pflegte einen Kontakt, der zwar in der Zone veröffentlicht wurde, aber zu einer fremden Organisation führte? Der RFC gab dem Zonenbetreiber das Feld zum Veröffentlichen; den Bereitschaftsdienst musste er mit dem tatsächlichen Reparaturteam abstimmen.

An TRANTOR.UMD.EDU zeigte die RFC, wie weit eine Maschine von einem einzigen zuständigen Postfach entfernt sein konnte. Vier RP-Adressen waren eine Karte möglicher Helfer. Ob eine davon den Ausfall tatsächlich bearbeitete, entschied sich erst nach der Meldung, außerhalb des DNS.

Quelle: RFC 1183, New DNS RR Definitions, Abschnitte 2 bis 2.2; RFC-Editor-Eintrag.