Zusammenfassung

  • RFC 3405 verlangte ein registriertes URI-Schema oder einen registrierten URN-Namensraum, eine stabile Spezifikation und anerkannte Autorität, bevor NAPTR in uri.arpa. oder urn.arpa. erscheinen durfte. Gültige DNS-Syntax schuf kein Recht.
  • Gemeinsame Zonen sollten extrem lange TTLs tragen. Veränderliche Regeln gehörten hinter einen stabilen Ersthinweis in eine delegierte Zone mit kürzerer Lebensdauer.

Eine lange TTL gilt oft als Betriebsproblem. RFC 3405 machte sie zum Architekturmaterial. Wenn ein globaler Eintrag jahrelang in Caches bleibt, sollte er nicht die beweglichste Politik enthalten, sondern dauerhaft auf deren zuständige Autorität verweisen.

Das im Oktober 2002 als BCP 65 veröffentlichte Dokument beendete die DDDS-Reihe. RFC 3401 stellte das System vor, RFC 3402 den Algorithmus, RFC 3403 NAPTR in DNS, RFC 3404 URI-/URN-Dienste und RFC 3405 die Zuweisung unter uri.arpa. und urn.arpa..

Der fünfte Teil war kein Verwaltungsanhang. Er entschied, wer den ersten Schritt im weltweiten DNS-Raum schreiben durfte, wie dieses Recht belegt wurde und welche Schicht schnell wechseln konnte. Registrierung beeinflusste Ausführung.

Ein URI-Schema lieferte den ersten Schlüssel unter uri.arpa.. Bei URNs extrahierte die dortige urn-Regel den Namespace Identifier und übergab an urn.arpa.. Ein kleiner Eintrag am Anfang konnte eine ganze Kennungsfamilie umlenken.

NAPTR durfte die Autorität, die es behauptete, nicht selbst erschaffen. Schema und NID brauchten vorher Registrierung und stabile Spezifikation. Der Auflösungshinweis folgte der Legitimität des Kennungsraums und verlieh sie nicht rückwirkend.

So ließ sich weder NID-Prüfung über urn.arpa. umgehen noch ein DNS-basiertes URI an jemand anderen als den Inhaber des eingebetteten Namens delegieren. Ein syntaktisch korrekter Ausdruck konnte weiterhin Autorität entführen.

Prüfer betrachteten technische Solidität, Konsistenz mit der Spezifikation und DNS-Eigentumsgrenzen. Bei extern gepflegten Spezifikationen benötigten spätere Ergänzungen oder Änderungen zusätzlich die Zustimmung des Eigentümers oder Betreuers. Fachprüfung und Erlaubnis waren zwei Belege.

Bei einem NID galt die Kontrolle für alle NAPTR, selbst wenn eine Regel nur einen Teilraum betraf. Enger Musterumfang beseitigte die Namensraumautorität nicht.

Die Vorlage verlangte Key, Authority und Records. Key wählte den globalen Platz, Authority den Berechtigten und Records die ausführbare Delegation. Das war eine Herkunftskette, nicht bloß Zonendatei.

Das ursprüngliche Verfahren nutzte offene Listen und zwei Wochen für Einwände. Einwände durften nur die Zone oder DNS betreffen; die Eignung des bereits gebilligten Schemas gehörte ins vorherige Forum. Jede Schicht besaß ihr Entscheidungsgremium.

IANA betrieb Zonen und Listen, schrieb aber nicht jede Regel. Kennungsautoritäten lieferten Recht und Spezifikation, Gutachter prüften gemeinsame Auswirkungen, IANA veröffentlichte und Delegierte pflegten den beweglichen Teil.

Entscheidend war die Zeit. Zur Lastsenkung konnten gemeinsame Einträge TTLs von Jahren haben. Häufig zu ändernde Politik durfte nicht direkt auf dieser Cachefläche liegen.

Die Lösung hieß zeitliche Delegation. Ein stabiles NAPTR in der gemeinsamen Zone zeigte auf eine Zone mit kurzer TTL. Oben standen weltweite Stabilität und geringe Last, unten Betriebsbeweglichkeit. Ein Weg hatte zwei Uhren.

Ein Cache konnte den ersten Zeiger behalten und nachgelagerte Regeln neu laden. Eine Änderung unten widerrief keinen alten Zeiger; eine Änderung oben verbreitete sich langsam. Prüfung muss Schicht, TTL und Autorität jeder Version festhalten.

Nicht jedes Schema brauchte eine dynamische Zone. Eine HTTP-URI enthält bereits den Host, den eine stabile Regel extrahiert. Flexible Namensräume profitieren von gesonderter Delegation. Der Ort des nächsten Schlüssels beschreibt die Kontrollgeometrie.

Die urn-Regel zeigte verschachtelte Governance: URN trat als URI-Schema in uri.arpa. ein, gab den NID frei und wechselte für die namenseigene Entscheidung zu urn.arpa.. Der gemeinsame Eingang vereinheitlichte keine lokalen Regeln.

Zwei bestätigte technische Errata ändern ausführbaren Inhalt. 2687 und 2688 ersetzen \2 durch \1, weil beide Beispiele nur eine Fanggruppe haben. Die gedruckten Ausdrücke sind ungültig und dürfen nicht in Produktion kopiert werden.

Auch die Zulassung alterte. RFC 3405 verlangte den „IETF tree“ aus RFC 2717; später verschwanden Schemanamenbäume. Ein Erratum durfte die Norm nicht ändern und wurde abgewiesen.

RFC 8958 aktualisierte 2020 korrekt: Baumvorgabe weg, permanente Registrierung nach BCP 35, heute RFC 7595, erforderlich. Das Tor änderte sich, die Reihenfolge blieb: autorisierter Kennungsraum zuerst, gemeinsamer Hinweis danach.

Das heutige IANA-Register unterscheidet permanent, vorläufig und historisch; ein Eintrag allein genügt URI.ARPA nicht. URN Namespaces folgt RFC 8141. Namensregistrierung und Zonenpublikation sind getrennte Ereignisse.

IANAs heutige .arpa-Seite nennt uri.arpa unter RFC 3405/8958 und urn.arpa unter RFC 3405. Das beweist den Infrastrukturzweck, nicht universelle NAPTR-Nutzung oder Resolvererfolg.

Gemeinsame Zonen bündelten DoS- und Spoofing-Risiken. DNSSEC konnte DNS-Daten authentisieren, aber nicht die Zustimmung des Betreuers, die Arbeit der Delegierten oder die endgültige Ressource.

Ein vollständiger Beleg enthält Schema/NID-Status, Spezifikation, Autorität, Zustimmung, Antrag, Prüfung, IANA-Annahme, Eintrag, DNSSEC, lange TTL, delegierten Schlüssel, untere Autorität und TTL, Änderung, Cachebeobachtung, gewählte Regel und Ergebnis.

Lu Hengs minimale Anfangsspezifikation erklärt beide Geschwindigkeiten: nur die kleinste dauerhafte Übergabe global normieren und spätere Entscheidungen dahinter lokalisieren. Vorrang laufenden Codes heißt, Live-DNS zu prüfen, Errata anzuwenden, nur die untere Zone zu ändern, TTLs zu vergleichen und Autorität dem registrierten Betreuer statt dem NAPTR-Schreiber folgen zu lassen.

RFC 3405 machte Stabilität zur Ortswahl. Der Ersthinweis änderte sich langsam, weil er nicht die aktuelle Regel spielte. Anpassung blieb möglich, weil Wandel lokal, zurechenbar und mit eigener Uhr versehen war.

Quellen