Zusammenfassung

  • RFC 6761 schuf im Februar 2013 das IANA-Register für Special-Use Domain Names. Wer einen neuen Namen aufnehmen lassen will, muss in einer Spezifikation sieben Fragen beantworten – vom Verhalten der Menschen bis zu dem der Domainregistrare.
  • Zu den ersten Einträgen gehörten ältere Reservierungen und Reverse-Zonen für private Adressen. Die Behandlung ist unterschiedlich: localhost soll auf Loopback zurückführen, invalid eine negative Antwort erzeugen und private Reverse-Zonen können innerhalb des eigenen Netzes beantwortet werden.
  • RFC 8244 hielt 2017 fest, dass IETF und ICANN kein formelles Verfahren zur Abstimmung solcher Zuweisungen hatten und der Begriff „technische Nutzung“ ungeklärt war. Ein Registereintrag belegt die Festlegung, nicht die Antwort eines eingesetzten Resolvers.

Ein Stempel ist kein DNS-Server

Ein Entwickler gibt einem Testprogramm einen Hostnamen. Die Anwendung reicht ihn vielleicht an eine Bibliothek weiter, diese an einen rekursiven Resolver und jener an einen autoritativen Server. Ein Registrar entscheidet an anderer Stelle, ob jemand den Namen kaufen darf. Dieselbe Zeichenfolge durchläuft damit mehrere Stellen mit unterschiedlichen Aufgaben. Ein gedrucktes „besonders“ im IANA-Register stellt ihre Entscheidungen nicht auf Gleichlauf.

RFC 2606 reservierte 1999 Namen für Tests, Beispiele, erwartete Fehler und den lokalen Host. Das schützte davor, dass ein erfundener Name in einer Anleitung später mit einer echten Domain kollidiert. RFC 6761 stellte 2013 die Anschlussfrage: Wer erkennt die Reservierung beim tatsächlichen Aufruf, wo endet die Suche, und welche Antwort ist richtig? Zwischen einer nicht verkäuflichen Domain und einem funktionierenden Resolver liegen mehrere Implementierungen.

Das neue IANA-Register startete mit den vorhandenen reservierten Namen und Reverse-Mapping-Zonen privater Adressen. Zu jedem Namen steht ein Verweis auf das maßgebliche Dokument. Die Tabelle ist ein Index zu Regeln, keine zentrale Maschine, durch die jede Namensanfrage läuft. Wer einen Fehler beheben will, muss den Weg der Anfrage verfolgen, statt nur die Tabelle zu öffnen.

Sieben Fragen an verschiedene Adressen

Eine neue Sonderbehandlung verlangt nach RFC 6761 eine IETF Standards Action oder eine Genehmigung durch die IESG. Das Dokument muss die betroffenen Namen bestimmen und sieben Gruppen behandeln: Menschen, Anwendungssoftware, Auflösungs-APIs und Bibliotheken, Caching-DNS-Server, autoritative DNS-Server, DNS-Betreiber sowie Registries und Registrare. Für jede Gruppe fragt der RFC, ob und wie sie den Namen anders behandeln soll.

Die Fragen ergeben keine sieben identischen Befehle. Bei privaten Reverse-Zonen wie 10.in-addr.arpa sollen Anwendungen und Namensauflösungs-APIs die Anfrage gewöhnlich an den konfigurierten Cache-Resolver geben. Dieser soll standardmäßig selbst antworten und die Frage nicht zu externen autoritativen Servern tragen. Für private Netze mit einem eigenen autoritativen Server kann er eine Einstellmöglichkeit anbieten. Ein Paket, das die Anwendung verlässt, belegt hier noch keinen Fehler. Der entscheidende Abzweig liegt beim Cache.

Bei localhost liegt er näher am Client: Adressanfragen sollen Loopback-Adressen liefern, ohne ins öffentliche DNS zu wandern. Bei invalid ist eine unmittelbare negative Antwort vorgesehen. Beide Namen sind reserviert, doch Antwort und Verantwortlicher unterscheiden sich. Ein Test gegen einen öffentlichen Resolver sieht nicht, ob eine lokale Bibliothek schon vorher geantwortet hat. Ein Blick auf den Registereintrag sieht keine der beiden Laufzeitentscheidungen.

Die heutige IANA-Liste umfasst unter anderem localhost, invalid, local, onion, home.arpa und private Reverse-Zonen. Jeder Eintrag hat seinen eigenen Verweis. Manche Namen bleiben im DNS und brauchen besondere Behandlung in einem Resolver; andere bekommen ihre Bedeutung im lokalen Netz oder in einem Anwendungskontext. RFC 6761 verlangte weder ausschließlich Top-Level-Namen noch einen einheitlichen Weg am DNS vorbei. „Special Use“ ist eine Registerkategorie, keine einzelne technische Funktion.

Der Name reist, seine Umgebung bleibt zurück

Ein interner Name wird in eine Nachricht kopiert. Der Empfänger probiert ihn in einem anderen Netz. Die Bytes sind gleich, der lokale Kontext ist es nicht. Der Name führt an ein anderes Ziel oder ins Leere. RFC 8244 untersuchte solche Brüche zwischen der global wirkenden Schreibweise und der lokalen Bedeutung. Gerade weil Namen leicht zu teilen sind, muss ihre Auflösung präzise beschrieben werden.

Im Oktober 2017 veröffentlichte RFC 8244 eine Bestandsaufnahme der Probleme. IETF und ICANN standen in Verbindung, hatten aber kein formelles Verfahren, um Special-Use-Zuweisungen abzustimmen. Was als „technische Nutzung“ gelten sollte, war nicht eindeutig abgesteckt. Beide Organisationen spielten eine Rolle im Namensraum; keine konnte einem Außenstehenden verbieten, eine Zeichenfolge vorab zu benutzen.

Das Papier nennt auch alltäglichere Risiken. Ein lokaler Name kann aus seinem Netz gelangen. Eine informelle Verwendung kann einer späteren formellen Zuweisung begegnen. Ein Entwickler kann das Verfahren nicht kennen oder mit einer Ablehnung rechnen. Welche Ursache für ein bestimmtes Produkt zutrifft, lässt sich erst mit damaliger Konfiguration und Abfrageprotokollen klären. Ein IANA-Eintrag liefert die amtliche Bezeichnung, keinen Mitschnitt des Betriebs.

Der trockene Witz: Für Sondernamen gab es nun eine ordentliche Schublade, nur waren sieben verschiedene Werkstätten für den Inhalt verantwortlich. RFC 6761 ließ die Aufgaben vor dem Eintrag aufschreiben. RFC 8244 zeigte, dass schon die Koordination über neue Schubladen ungeklärt war.