Zusammenfassung

  • RFC 1480 unterschied einen delegierten Zweig, die direkte A-Registrierung eines IP-Rechners und die direkte MX-Registrierung eines Nicht-IP-Rechners. Aus der Existenz eines .US-Namens ging der zugrunde liegende Verwaltungs- und Transportweg nicht hervor.
  • Delegation übertrug Kontrolle an einen benannten Verwalter und band sie an Gleichbehandlung, fachgerechten Betrieb, richtige Daten, redundante Server, Dienst an der Gemeinschaft und einen abgestimmten Übergang. Ein Eintrag in der Datenbank der Oberzone tat dies nicht.

Gleiche Punkte, unterschiedliche Zuständigkeit

Die im Juni 1993 veröffentlichte RFC 1480 ordnete .US nach Bundesstaaten, Orten und Funktionszweigen wie K12, LIB, FED oder GEN. Die Struktur sollte eindeutige Namen und handhabbare Verwaltung ermöglichen.

Das Anmeldeverfahren trennte jedoch Delegation von direkter Registrierung. Bei der direkten Variante blieben die Daten im Hauptbestand; sie betraf entweder einen IP-Rechner oder einen Nicht-IP-Rechner. Bei der Delegation betrieb eine andere Organisation den Zweig auf eigenen Nameservern.

Der Resolver zeigte in allen Fällen einen Namen. Er zeigte nicht automatisch, wer Änderungen vornehmen durfte, welcher Rechner tatsächlich IP sprach und wer den Dienst aufrechterhalten musste.

Ein A-Eintrag schnitt keine Zone aus

Für einen direkt registrierten IP-Host wurde ein A-Eintrag angelegt. Nach RFC 1035 enthält er eine 32-Bit-Internetadresse. Diese Aussage reicht bis zur Adresse, nicht bis zum Recht, darunter weitere Namen zu veröffentlichen.

RFC 1034 beschreibt die Delegation als gesonderte Zustimmung der passenden Elternzone zur Übertragung von Kontrolle. NS nennt einen Rechner, von dem Autorität für die am Owner beginnende Zone erwartet wird. A und NS bezeugen verschiedene Oberflächen.

Das lässt sich an einer Korrektur prüfen. Einen direkten Eintrag ändert der Verwalter des übergeordneten Bestands. In einer delegierten Zone handelt der benannte lokale Verwalter. Eine erfolgreiche Auflösung enthält nicht die gesamte Genehmigungskette.

Eine MX-Adresse verdeckte den Nicht-IP-Weg

Viele Antragsteller befanden sich in der UUCP-Welt. Ihr Rechner konnte einen oder mehrere Sprünge von einem Internet-Host entfernt sein und dennoch einen DNS-Namen erhalten. MX verwies auf den IP-fähigen Weiterleiter, sodass Absender eine normale Internet-Mailadresse benutzen konnten.

RFC 1035 beschreibt den Mail Exchanger als einen Host, der für den Owner handeln will; RFC 974 regelt seine Auswahl. Das machte den benannten Rechner nicht zu einem IP-Endpunkt.

Hinter MX musste der Weiterleiter zustimmen, eine technische Übergabe einrichten und eine lokale Regel zum UUCP-Ziel pflegen. Bei Zwischensystemen brauchte jedes seinen nächsten Schritt. Die .US-Verwaltung konnte den Eintrag veröffentlichen, aber nicht die Zustimmung fremder Betreiber ersetzen.

Darum sind MX-Antwort, fortbestehende Einwilligung, Verbindungsversuch, Warteschlange und Empfang getrennte Belege. Die gemeinsame Adressform nahm dem Nutzer Komplexität ab; sie beseitigte sie nicht.

Delegation war ein überprüfbarer Auftrag

Zweige wie K12.TX.US, Orte und Bibliotheksräume sollten verteilt werden, weil eine zentrale Stelle nicht alle Namen dauerhaft bearbeiten konnte. RFC 1480 bezeichnete die zuständige Person oder Organisation als trustee und stellte Verantwortung über Eigentumsansprüche.

Der Verwalter sollte Anträge gleich behandeln, keine Kunden eines verbundenen Netzanbieters bevorzugen und kein bestimmtes Produkt, Protokoll oder Mailsystem verlangen. Wesentlich Betroffene sollten seine Eignung anerkennen. Die Oberstelle ließ Streitparteien nach Möglichkeit selbst Einigkeit herstellen und behielt Eingriffe bei erheblicher Pflichtverletzung vor.

Der Auftrag hatte technische Messpunkte: zeitnahe Antworten, korrekte und robuste Daten, ein erreichbarer Primär- und Sekundärserver sowie Prüfbarkeit durch die Oberstelle. Räumliche Trennung sollte gemeinsame lokale Ausfälle vermeiden.

Zwei NS-Namen beweisen weder unabhängige Standorte noch unparteiische Verwaltung. Laufende Autorität und erfüllte Treuepflicht bleiben verschiedene Feststellungen.

Ein Verwalterwechsel brauchte beidseitige Spuren

Für die Übertragung des trusteeship verlangte RFC 1480 Nachrichten der alten und der neuen Organisation. Die Oberstelle sollte gegenseitige Zustimmung und das Verständnis der Pflichten beim Nachfolger erkennen können. Stellungnahmen betroffener Parteien waren ebenfalls hilfreich.

Der Zonenname konnte unverändert bleiben, während Institution, Server und Ansprechpartner wechselten. Der letzte NS-Satz allein sagt nicht, wann Einigung, Anerkennung, technische Umschaltung und stabiler Betrieb eintraten.

RFC 1591 fasste den Gedanken später allgemein: ccTLD-Verwaltung sei öffentlicher Dienst, der benannte Manager trustee für Land und globale Internetgemeinschaft. Das erklärt den Maßstab, bestätigt aber keinen einzelnen historischen Vorgang.

Die Gliederung war ein Plan ihrer Zeit

RFC 1480 ersetzte die nur sechs Monate ältere RFC 1386. Die schnelle Ablösung belegt überarbeitete Dokumentation, nicht die Umsetzung aller vorgesehenen Zweige.

Geografie und Funktionsnamen teilten die Arbeit in beherrschbare Portionen. Kürzeste Wunschnamen hatten geringere Priorität als ein dauerhaft betreibbares System. RFC 920 und die DNS-Grundlagen bildeten den Rahmen; RFC 1480 hielt eine konkrete US-Verwaltungsordnung von 1993 fest.

Der RFC-Editor-Eintrag führt das Dokument als Informational. Sicherheitsfragen wurden ausdrücklich nicht behandelt. Redundanz und verantwortliche Verwaltung sind deshalb keine Authentifizierungs- oder Sicherheitsgarantie.

Ein später verifiziertes Erratum ergänzt einen fehlenden Alternativstrich in der BNF. Es berichtigt die Grammatik, nicht den Delegationsstatus realer Zonen.

Ein Name braucht einen Herkunftsnachweis

Ein belastbares Inventar trennt Owner-Name, RR-Typ, veröffentlichende Zone, Delegationsschnitt, Manager, Server und Beobachtungszeit. Für Mail kommen Weiterleiterzustimmung, UUCP-Regeln, Versuch, Queue und Empfang hinzu. Für Herrschaft über die Zone kommen Auswahl und Übertragung hinzu.

DNS machte verschiedene Systeme unter einer Oberfläche benutzbar. Historische Genauigkeit verlangt, hinter dieser Oberfläche die getrennten Verantwortungen wieder sichtbar zu machen.

Quellen