Summary

  • RFC 2606 erschien im Juni 1999 als Best Current Practice. Es reservierte .test, .example, .invalid und .localhost für unterschiedliche Zwecke und dokumentierte die IANA-Reservierung von example.com, example.net und example.org.
  • Ein intern erfundener Name kann später weltweit vergeben werden. Beispielcode kann die Testumgebung verlassen. Reservierte Namen geben der technischen Fiktion einen beständigen Ort, bevor sie mit realen Adressen kollidiert.

Mancher Text in einer technischen Anleitung hält sich hartnäckiger als die Anleitung selbst. Ein Autor schreibt eine ausgedachte Adresse hin, um einen Befehl zu erklären. Ein Leser übernimmt die Zeile, ein Kollege übernimmt die Konfiguration, und bald reist die Adresse mit einem Programm. Die Bemerkung „nur ein Beispiel“ reist gewöhnlich nicht mit. Dem DNS ist ohnehin gleichgültig, ob ein Name ursprünglich auf einem Whiteboard stand.

D. Eastlake und A. Panitz beschrieben das Problem im RFC 2606 vom Juni 1999, veröffentlicht als BCP 32. Sie schilderten etwa eine Einrichtung, die zum Testen ihres DNS-Codes einen damals unbenutzten Top-Level-Namen lokal einrichtet. Derselbe Name könnte später im globalen DNS auftauchen. Die lokalen Testdaten würden dann für die Benutzer dieser Einrichtung die echten Daten überlagern. Oder experimentelle Software gelangt aus dem abgeschlossenen Netz hinaus und fragt einen Namen ab, den ihr Entwickler für reine Kulisse hielt.

Das Dokument stellte vier Namensschilder bereit. .test wurde für Tests von DNS-bezogenem Code empfohlen. .example diente Beispielen und Dokumentation. .invalid sollte sofort als ungültiger Name erkennbar sein. .localhost bewahrte eine traditionelle lokale Verwendung, die in Host-Implementierungen mit der Loopback-Adresse verbunden war. Es ging nicht um vier Schreibweisen für denselben Zweck. Jede Schublade erhielt ihren eigenen Inhalt.

Dazu kamen drei Namen auf der zweiten Ebene: example.com, example.net und example.org. RFC 2606 hielt fest, dass IANA sie als Beispiele reserviert hatte. Sie eignen sich für Anleitungen, in denen eine Adresse unter einem gewöhnlichen Top-Level-Namen stehen soll. Ein Formular mit example.com sieht wie ein normales Formularbeispiel aus, ohne auf die Domain einer fremden Organisation zu zeigen. Für eine nicht existierende Website ist das eine erstaunlich ordentliche Meldeadresse.

Der Unterschied zwischen den beiden Ebenen ist wichtig. Bei laden.example trägt bereits der Top-Level-Teil das Schild „Beispiel“. Bei example.com bleibt .com ein gewöhnlicher Namensraum; ein bestimmter Name darunter ist ausgespart. Das RFC kombinierte diese Möglichkeiten, weil ein DNS-Test und eine anschauliche Webanleitung nicht immer dieselbe Form brauchen. Auch die Fiktion hat Formatvorgaben.

Im Abschnitt über Sicherheit wird die Begründung scharf. Testprogramme können im operativen DNS landen. Adressen aus einer angeblich rein erläuternden Passage können in freigegebene Software geraten. Ein erfundener Name kann später einen wirklichen Inhaber haben und Konflikte bis hin zu Ansprüchen an diesem Namen auslösen. RFC 2606 zählte damit Risiken auf, keine Statistik bereits eingetretener Vorfälle. Der Vorschlag war unspektakulär und gerade deshalb wirksam: wenige Namen festlegen, Zwecke benennen, reservieren. Das Bühnenbild bekam einen Eintrag im Kataster.

Die heutige IANA-Hilfe zu Beispieldomains beschreibt die fortdauernde Verwaltung: Dokumente dürfen die Namen ohne vorherige Abstimmung verwenden; Registrierung und Übertragung sind ausgeschlossen. IANA stellt dort Informationsseiten bereit, rät aber davon ab, den laufenden HTTP-Dienst zur Voraussetzung einer Anwendung zu machen. Die reservierte Adresse ist das Arbeitsmittel. Die Informationsseite hängt als Schild daran.