Zusammenfassung

  • RFC 8552 legte im März 2019 fest, wie ein unterstrichener DNS-Zweig Einträge für die übergeordnete Domain aufnehmen kann. Der dem DNS-Stamm nächstgelegene unterstrichene Name hat globale Reichweite.
  • Das IANA-Register koordiniert die Kombination aus DNS-Eintragstyp und diesem globalen Namen. Es verhindert eine zweite, widersprechende Vergabe derselben Kombination; die tieferen Namen definiert das jeweilige Protokoll.
  • RFC 8553 passte ältere Spezifikationen an das Register an und ließ vorhandene Software und Betriebsverfahren bestehen. Ein Registereintrag belegt eine Vergabe, nicht den Inhalt einer konkreten DNS-Zone.

Der Typ allein war zu grob

DNS kennt Eintragstypen und Namen. Die grundlegenden Regeln weisen den einzelnen Teilen eines Domainnamens keine allgemeingültige Bedeutung zu; sie verbieten auch nicht, einen bestimmten Eintragstyp an einem bestimmten Ort einzusetzen. Diese Freiheit war nützlich. Ein Protokoll musste nicht für jede neue Eigenschaft der Domain einen neuen Typ erfinden. Es konnte einen vorhandenen Typ nutzen und seinen Ort im Namensbaum präzisieren.

Gerade TXT machte die Spannung sichtbar. Zwei Anwendungen können TXT-Daten über dieselbe Domain veröffentlichen und doch ganz verschiedene Anweisungen meinen. Wer alles unmittelbar unter der Domain ablegt, zwingt den Leser zur nachträglichen Sortierung. RFC 8552 beschreibt stattdessen einen Zweig darunter: Der Eintrag steht etwa unter _name.example.org, während example.org die Domain bleibt, auf die sich die Information bezieht. Die Anfrage nach dem Zweig trifft die Daten, die das Protokoll an dieser Stelle erwartet.

Der Unterstrich markiert eine Grenze zur gewöhnlichen Hostbenennung. _name soll hier nicht wie ein weiterer Rechner namens name aussehen. Das Zeichen ändert kein DNS-Paket und schafft keinen neuen Eintragstyp. Es weist dem alten Typ eine engere Adresse zu. Das klingt klein, solange nur ein Autor eine solche Adresse benutzt. Im offenen Namensraum muss jedoch jeder weitere Autor wissen, welche Adresse schon vergeben ist.

Ein älteres Beispiel ist RFC 2782 aus dem Februar 2000. Für SRV-Einträge verwendet es die Form _Service._Proto.Name, unter anderem um Dienst- und Protokollnamen von gewöhnlichen Hostnamen zu trennen. Später griff DNS-Based Service Discovery diese Konvention auf. Die Frage, welchen Server ein SRV-Client auswählt, gehört zu diesem älteren Verfahren. Die Neuerung von 2019 betraf die Vergabe der gemeinsamen Namen, bevor verschiedene Verfahren dieselbe Stelle für unterschiedliche Zwecke beanspruchen.

Welcher Name ist global?

In einem Zweig können mehrere Namen mit Unterstrich stehen. Entscheidend ist derjenige, der dem DNS-Stamm am nächsten liegt. RFC 8552 nennt ihn global. Die weiteren Namen darunter gehören in den Geltungsbereich des Protokolls, dem dieser globale Zweig zugeordnet wurde. Die Richtung ist wichtig: Wer nur den ersten Unterstrich liest, den ein Mensch von links sieht, kann die Zuständigkeit verwechseln.

Das Register „Underscored and Globally Scoped DNS Node Names“ führt Eintragstyp, globalen Namen und Referenz. Sein Schlüssel besteht aus zwei Teilen: RR Type und _NODE NAME. Derselbe Typ kann unter verschiedenen globalen Namen dienen. Derselbe globale Name kann bei verschiedenen Typen erscheinen. Kritisch wird die zweite Zuweisung derselben Paarung. Dann könnte ein Client am richtigen DNS-Ort die falsche Bedeutung erwarten.

Die Vergabe läuft über Expert Review. Nach RFC 8552 prüft die Begutachtung, ob die Paarung eindeutig und verständlich beschrieben ist. Sie ist kein allgemeiner TÜV für die Qualität des Protokolls. Eine sauber vergebene Adresse sagt nichts darüber, ob die Anwendung klug konstruiert wurde, ob ein Domainbetreiber die passenden Daten veröffentlicht hat oder ob ein Client sie richtig verarbeitet. Die Grenze dieser Prüfung ist Teil ihrer Stärke: Sie soll Kollisionen verhindern, nicht die gesamte Anwendung kontrollieren.

Man kann drei Ebenen deshalb nicht zusammenziehen. Das IANA-Register nennt die reservierte Kombination und ihre Spezifikation. Die Spezifikation erklärt, was unter dem Zweig stehen darf und wie tiefere Namen zu lesen sind. Die autoritative DNS-Antwort einer konkreten Domain zeigt, welche Einträge dort tatsächlich liegen. Ein leerer Zweig wird durch seinen Registereintrag nicht gefüllt.

Die alte Konvention musste nachgetragen werden

Das Register kam nach der Praxis. Mehrere frühere Dokumente verwendeten Namen mit Unterstrich, lange bevor es eine gemeinsame Liste gab. RFC 8553, zusammen mit RFC 8552 im März 2019 veröffentlicht, aktualisierte diese Dokumente. Auch die Vorlagen für SRV- und URI-Einträge wurden auf das einheitliche Register ausgerichtet.

Der Eingriff zielte auf Spezifikationen, nicht auf eine nächtliche Umbenennung des Netzes. RFC 8553 hält fest, dass bestehende Software und Betriebsabläufe erhalten bleiben. Die Daten auf dem Draht sahen am nächsten Morgen nicht anders aus, weil eine IANA-Tabelle ergänzt wurde. Neu war der Weg, auf dem künftige global benannte Zweige beansprucht und ältere Verweise verstanden werden sollten.

Das ist die eigentliche historische Spannung: Ein nützliches Zeichen schuf lokale Ordnung, aber lokale Ordnung skaliert nicht automatisch über unabhängige Autoren hinweg. Jeder kann seinen Unterzweig sauber spezifizieren und dennoch denselben globalen Platz belegen wie ein anderer. Die Antwort war keine zentrale Inhaltskontrolle aller DNS-Daten. Sie war ein Register an genau der Grenze, an der zwei Protokolle sonst miteinander kollidieren.

Die offiziellen Dokumente belegen Regel, Registerschlüssel und die Überarbeitung älterer Texte. Für die Behauptung, ein bestimmter Dienst habe diese Struktur tatsächlich eingesetzt, fehlen eine datierte autoritative Zonenaufnahme und die konkrete Clientabfrage. Erst dort treffen Vergabe und laufender Betrieb aufeinander.