Digity, LLCs Zwei-TLD-Transfersicht: Delegation, RDAP, Kontinuität

Zusammenfassung

• Digity, LLC ist die im öffentlichen Register ausgewiesene Sponsoring-Organisation für.caseund.radio, zwei TLDs, die über getrennte IANA-Prozesse an das Unternehmen übertragen wurden; der öffentliche Datensatz begründet eine abgegrenzte Registry-Verantwortung und nicht eine souveräne Kontrolle über das DNS.
• Aktuelle Root-Einträge zeigen unterschiedliche technische Kontakte und RDAP-Servicepfade für die beiden Namensräume. Das ist ein Hinweis auf getrennte öffentlich sichtbare Kontrollpfade, nicht auf eine vollständige private Architektur oder einen Zuverlässigkeitswert.
• Vereinbarungen, Zuweisungen, Erneuerungen, DNS-/DNSSEC-Observationsdaten, RDAP-Objekte, öffentliche Registrierungsoberflächen und Protokollstandards begründen reale Leistungsfähigkeit und Verantwortlichkeit, ohne eine langfristige Zuverlässigkeit oder Kundenergebnisse der Produktion zu nachzuweisen.
• Überwachung, Integration, Wartung, Portabilität und genehmigte Ausnahmebehandlung bleiben operative Kosten, selbst wenn Fachanbieter und Automatisierung Routineaufgaben übernehmen.

Bildhinweis:Das begleitende Creative-Commons-Foto zeigt eine generische Serververkabelung in einem Rechenzentrum der Wikimedia Foundation. Es zeigt nicht Digity, LLC, deren Personal oder Einrichtungen, die Registry-Backends von.caseoder.radio, CentralNic, CORE, Kunden, Vorfälle, private Architektur, gemessene Zuverlässigkeit oder Produktionsergebnisse.

Digity, LLC erscheint im aktuellen BTW-Verzeichnis als Unternehmensobjekt und in der IANA Root Zone Database als Sponsoring-Organisation für.caseund.radio.[1][2][3] Beide Top-Level-Domains wurden über dokumentierte Übertragungen zu Digity geführt und nicht über eine Erstdelegierung an das Unternehmen. IANA veröffentlichte einen Transferbericht für.caseim Mai 2023 und einen separaten Bericht für.radioim Februar 2026.[4][5] Diese Historie macht Digity zu einem relevanten Forschungsobjekt im Technologiebereich, weil eine operative Frage sichtbar wird: Wie kann eine verantwortliche Organisation verlässliche Registereinträge und kontinuierliche Dienste aufrechterhalten, wenn sie zwei Namensräume mit unterschiedlichen Historien, öffentlichen Servicelinien, Politik-Kontexten und technischen Kontakten übernimmt?

Die öffentliche Evidenz etabliert eine reale Kontrolloberfläche.

Dazu gehören Sponsoring-Organisationseinträge, autoritative DNS-Delegationen, IPv4- und IPv6-Glue, DNS Security Extensions-Material, WHOIS-Dienste, Registration Data Access Protocol-Endpunkte, Registry-Vereinbarungen, Zuweisungen, Erneuerungen, öffentliche Registrierungsoberflächen, Escrow-Verpflichtungen und Notfall-Kontinuitätsmechanismen.[2][3][6][7][8][9][10][11][12][13][14][15][16] Sie umfasst auch Standards, die definieren, wie RDAP-Anfragen und -Antworten funktionieren und wie validierende Resolver DNSSEC-Daten verarbeiten.[17][18][19] Die IANA-RDAP-Bootstrap-Datei stellt die Routing-Schicht bereit, die Clients sagt, wohin sie für jede

TLD Anfragen senden.[20]

Diese Datensätze zeigen keine private Architektur, Personalstruktur, Anbieterverträge, Topologie der Bereitstellung, Sicherheitskontrollen, Störfallhistorie, Registrierungsvolumen oder Kundenergebnisse von Digity. Der.case-IANA-Eintrag nennt CentralNic als technischen Kontakt und verweist auf eine CentralNic-RDAP-Basis, während der.radio-Eintrag CORE Association als technischen Kontakt nennt und aufrdap.nic.radiozeigt.[2][3] Das sind Unterschiede in Rollen und Endpunkten. Es ist kein vollständiges Backend-Design. Ein öffentlicher Service-Hostname bildet kein vollständiges Vertrags- oder Technikbild.

Die Analyse hält daher drei Ebenen getrennt:

• Modell- oder Systemfähigkeit:Ein Protokoll-Endpunkt kann eine definierte Abfrage beantworten, eine Delegierung kann Nameserver und DS-Daten veröffentlichen, ein Registry-Prozess kann eine autorisierte Änderung akzeptieren, und ein Escrow-Prozess kann einen definierten Datensatz bewahren.
• Produktzuverlässigkeit:Diese Funktionen müssen korrekt, erreichbar, sicher, beobachtbar und recoverabel sein trotz Wartung, Ausfall von Anbietern, Personalwechsel, fehlerhafter Eingaben und einem Betreiberwechsel.
• Kundenergebnis in der Produktion:Ein registrierter Registrar, Registrant, Sender, Anwendung oder Sicherheitsteam erreichte ein messbares Ergebnis, das nachweislich dem Service zugeordnet werden kann.

Der öffentliche Datensatz stützt eine begrenzte Fähigkeitsbewertung und benennt Zuverlässigkeitsfragen. Er stützt keine Aussage über ein Kundenergebnis in der Produktion. Eine erfolgreiche DNS- oder RDAP-Beobachtung zu einem Zeitpunkt ist kein Langzeit-Maßstab, und eine vertragliche Verpflichtung ist nicht der Beleg, dass ein Ziel in jedem Zeitraum erreicht wurde. Diese Unterscheidung ist zentral für die Bewertung einer Registry, ohne Tests, Kundenfälle, Ausfälle oder interne Designs zu erfinden.

Die Hauptfeststellung ist, dass sich bei Digity zwei voneinander getrennte TLDs in der Aufsicht konzentrieren und mehrere Ausführungspfade dennoch sichtbar unterscheidbar bleiben. Das kann nützliche Trennung schaffen, erzeugt aber auch Kosten für Aufsicht, Integration, Wartung und Ausnahmebehandlung. Die technische Kernfrage ist nicht, dass ein Backend-Modell besser sei als ein anderes. Entscheidend ist, ob Digity registrierte Daten, laufende Dienste, vertragliche Verantwortlichkeit und Wiederherstellungsbefugnis über beide Namensräume kohärent halten kann, auch wenn sich diese Elemente ändern.

Identität und zwei separat übertragenen Delegationen

Die Identität des Unternehmens ist relevant, weil die Änderungsbefugnis im Root-Zone-System an eine exakte Organisation gebunden ist und nicht an eine lose Marke. Das BTW-Verzeichnis liefert das aktuelle Unternehmensobjekt, auf das sich diese Untersuchung bezieht.[1] IANA nennt Digity, LLC als Sponsoring-Organisation für.caseund.radio, aber die beiden Datensätze zeigen verschiedene Adressen zu der Organisation sowie unterschiedliche technische Kontakte.[2][3] Diese Abweichung ist kein Fehler an sich. Sie ist ein Grund, Rechtsform, aktuelle Kontaktangaben und Änderungsbefugnis als operationalen Zustand zu behandeln, der abgeglichen werden muss.

Der IANA-Transferbericht für.casenennt Digity als vorgeschlagenen Betreiber und markiert Antragstellerabgleich, Kontaktbestätigungen, technische Konformität und weitere Verarbeitungsschritte als abgeschlossen.[4] Der entsprechende Bericht für.radiodokumentiert dieselben Prüfungskategorien für eine spätere Übertragung.[5] Diese Berichte zeigen, dass jede Anfrage ein definiertes Übergangstor passiert hat. Sie zeigen nicht, dass jede technische Komponente transferiert wurde, dass jeder Prozess unverändert blieb oder dass der spätere Betrieb ein bestimmtes Zuverlässigkeitsniveau erreichte.

Die zugrunde liegenden Zuweisungsdokumente ergänzen eine Vertragsebene. Die.case-Zuweisung dokumentiert die Übertragung von Rechten und Pflichten der Vereinbarung auf Digity, und die.radio-Zuweisung erfüllt dieselbe Funktion für diese TLD.[10][11] Eine Zuweisung ist relevant, weil sie die verantwortliche Partei unter der Registry-Vereinbarung identifiziert. Sie darf nicht als für Software, Infrastruktur, Personal, Datenmigration oder Anbieterverteilung gelesen werden. Vertragliche Verantwortlichkeit kann übertragen werden, während technische Umsetzung teilweise bei Spezialorganisationen verbleibt, in Phasen erfolgt oder für verschiedene Services unterschiedliche Wege folgt.

Die Erneuerungsdokumente zeigen, dass die Verpflichtungen über das initiale Zuweisungsereignis hinaus fortbestehen.[12][13] Erneuerung ist nicht nur eine Verlängerung eines Zeitstempels. Sie erhält eine fortlaufende Beziehung, in der Root-Zonendaten, Registrierungsdienste, Sicherheitsverpflichtungen, Daten-Escrow, Berichterstattung und Kontinuitätskontrollen konsistent bleiben müssen. Die aktuellen ICANN-Vertragsindizes liefern das öffentliche Inventar der Vereinbarungsunterlagen je TLD.[6][7]

Hier ist das Prinzip Registry als Registerhalter nützlich. Digity ist der aktuell eingetragene Registry-Betreiber für diese zwei Delegationen. Diese Rolle ist materiell, aber begrenzt. Digity besitzt nicht die DNS-Root, wird nicht souverän über alle Nutzungsfälle der Labels, und ersetzt nicht die Rollen von ICANN, IANA, Registraren, technischen Serviceanbietern, rekursiven Resolvern, Netzbetreibern, Gerichten und Politikbehörden. Die Legitimität des Betreibers im technischen System hängt von genauen Datensätzen, autorisierten Änderungen, standardskonformer Ausführung und Kontinuität ab.

Eine Übertragung erzeugt mindestens vier verbundene Inventare:

1. Authority-Inventar:die juristische Einheit, Vereinbarung, freigegebenen Kontakte, authentifizierte Konten und Personen, die Änderungen anfordern oder genehmigen dürfen.
2. Namespace-Inventar:das TLD-Label, die Root-Delegation, Glue, DS-Daten, WHOIS- und RDAP-Routing, reservierte Namen, Domain-Status und Registrar-Beziehungen.
3. Abhängigkeits-Inventar:die Anbieter, Berechtigungen, Zertifikate, Schlüssel, Netze, Überwachungsysteme, Datenspeicher, Escrow-Prozesse und Supportpfade, die den Betrieb des Namespace aufrechterhalten.
4. Evidenz-Inventar:die Datensätze, die einem Prüfer ermöglichen, nachzuvollziehen, warum ein Zustand als gültig gilt, wann er sich änderte, wer ihn genehmigte und wie das Ergebnis unabhängig verifiziert wurde.

Die öffentlichen Quellen zeigen Teile der ersten beiden Inventare und vertragliche Anforderungen rund um das Dritte und Vierte auf. Sie zeigen nicht Digitys private Inventare. Das ist eine Evidenzgrenze, kein Anlass, automatisch starke oder schwache Kontrollen anzunehmen.

Die beiden Übertragungen kamen zudem zu verschiedenen Zeiten und aus unterschiedlichen Vorgänger-Kontexten..casewar vor der Übertragung auf Digity an einen anderen operativen Anbieter delegiert;.radiowar zuvor der Europäischen Rundfunkunion zugeordnet gewesen, bevor die spätere Übertragung erfolgte.[2][3][4][5] Ein Übergangsplan kann diese Historien nicht als austauschbar behandeln. Pflichtbindungen, Registrarbeziehungen, öffentliche Erwartungen, Serviceanbieter, verbliebene Daten und Ausnahmewarteschlangen können differieren, auch wenn der Endzustand im Root-Zone-Intent ähnlich erscheint.

Die praktische Kontrolle ist ein Übergangsdatensatz je TLD. Er sollte benennen, welche Pflichten und Vermögenswerte übertragen wurden, was beim Anbieter blieb, was nach der Übertragung änderte und welche Belege den aktuellen Zustand stützen. Ein gemeinsamer Konzerninhaber kann die Form dieses Datensatzes standardisieren, aber nicht die Unterschiede ausgleichen, die relevant sind.

Betrieb von DNS, DNSSEC, WHOIS und RDAP-Kontrolloberfläche

Die IANA-Seiten listen für jede TLD vier autoritative Nameserver,a,b,cunddunter der entsprechendennic-Domain, mit IPv4- und IPv6-Glue.[2][3] Eine begrenzte Beobachtung fand diese vier erwarteten Namen für.caseund.radio, und DS-Datensätze waren bei der Erfassung für beide sichtbar. Diese Beobachtungen zeigen, dass die ausgewählten öffentlichen Pfade damals kohärente Delegierungsdaten zurücklieferten. Sie beweisen nicht globale Erreichbarkeit, Unabhängigkeit der Server, kontinuierliche Verfügbarkeit oder ein bestimmtes Reaktionszeitziel.

Ein Root-Zonenlisting ist ein autoritärer Datensatz der Delegierungsabsicht. Es ist keine physische Topologie. Vier Namen bedeuten nicht automatisch vier Maschinen, Standorte, Netze oder Fehlerdomänen. Anycast kann viele Service-Instanzen hinter einer Adresse bündeln, während mehrere Namen dennoch auf gemeinsame Kontrollsysteme angewiesen sein können. Es ist nicht sinnvoll, aus sichtbaren Namen, Adressen oder Kontakten auf eine private Architektur zu schließen.

Modellpriorität beim laufenden Betrieb bedeutet nicht, den Datensatz zu ignorieren. Es bedeutet, zu prüfen, ob der beobachtbare Dienst den Datensatz weiterhin ehrt. Ein sinnvolles Betriebsmodell vergleicht:

• den genehmigten Root-Zonen- und Registry-Datensatz;
• direkte autoritative Antworten;
• DNSSEC-Validierung über unabhängige Pfade;
• IPv4- und IPv6-Erreichbarkeit;
• Routen-Transparenz und Netzdiversität;
• Überwachung außerhalb der Provider-Steuerungsebene;
• Registrar-Transaktionsverhalten;
• RDAP-Auffindbarkeit und Antwortsemantik;
• Symptome auf Kundenseite, ohne automatisch diesen Ort als Fehlerursache festzulegen.

Jede Ebene beantwortet eine andere Frage. Eine korrekte Root-Zone-Seite kann nicht beweisen, dass jede autoritative Instanz erreichbar ist. Eine erfolgreiche rekursive Abfrage kann nicht beweisen, dass jeder Resolver denselben Zustand sieht. Eine gültige Signatur zu einem Zeitpunkt beweist nicht automatisch, dass der nächste Rollvorgang sicher ist. Ein erfolgreiches RDAP-HTTP-Response beweist nicht, dass jedes Objektfeld aktuell ist.

DNSSEC ergänzt einen Sicherheits-Metadaten-Lebenszyklus. RFC 4035 beschreibt, wie validierende Resolver DNS-Daten authentifizieren und wie Fehler zu unsicheren oder falschen Ergebnissen führen können.[19] Der übergeordnete DS-Datensatz, die DNSKEY-Sammlung des Kindes, Signaturen, Gültigkeitszeiträume, Algorithmen und Betriebsuhren müssen kohärent bleiben. Automatisierung kann Tags berechnen, Datensätze vergleichen, Ablaufdaten überwachen und eine falsche gewünschte Konfiguration schnell replizieren, wenn Autorität oder Inventar falsch ist.

Gute DNSSEC-Betriebsführung erfordert daher mehr als fähige Software. Sie benötigt Schlüsselverwaltung, explizite Rollen, eine geplante Sequenz, Überlappungsphasen, Beobachtung, Rollback-Grenzen und Wiederherstellungszugriff. Ein technisch gültiger DS-Wert kann dennoch für den vorgesehenen Schlüssel falsch sein. Eine korrekte Einreichung kann zu einem falschen Zeitpunkt erfolgen. Ein Monitoring kann einen Fehler sehen, obwohl der einzige autorisierte Responder nicht erreichbar ist.

WHOIS- und RDAP-Pfade zeigen eine verwandte, aber andere Kontrolloberfläche. IANA listetwhois.nic.caseund eine CentralNic-RDAP-Basis für.case, während.radiowhois.nic.radiound eine RDAP-Basis unternic.radionutzt.[2][3] IANAs Bootstrap-Daten routen RDAP-Clients zur jeweiligen Registry-Schnittstelle.[20] RFC 9082 definiert Abfragemuster und Fehlerpfade; RFC 9083 definiert JSON-Antwortstrukturen, Links, Hinweise, Status, Ereignisse, Entitäten und Fehlerverhalten.[17][18]

Bei der begrenzten Erfassungszeit ergab die Anfrage fürnic.caseein RDAP-Objekt mit dieser Kennung, und die Anfrage fürnic.radiodas entsprechende.radio-Objekt. Die Services lieferten unterschiedliche Antwortdetails und Statussätze, was bei separaten Objekten und möglicherweise getrennten Betriebswegen zu erwarten ist. Die Beobachtungen bestätigen, dass die beiden exakten Anfragen beantwortet wurden. Sie belegen keine Vollständigkeit, keine absolute Korrektheit jedes Feldes, keine dauerhafte Verfügbarkeit und kein gleiches Verhalten beider Services.

Strukturiertes RDAP ist ein Fähigkeitsgewinn gegenüber einer präsentationsorientierten Textausgabe, weil Clients Felder parsen und Links folgen können. Produktzuverlässigkeit hängt weiterhin von Bootstrap-Korrektheit, Endpunkt-Erreichbarkeit, TLS, Antwortsemantik, Aktualisierungszeitfenstern, Rate-Controls, Datenschutzbehandlung, Ereigniskonsistenz und brauchbaren Fehlern ab. Ein Kundenergebnis in der Produktion würde Belege eines benannten Nutzers oder Workflows mit Basislinie und Messfenster erfordern. Nichts davon liegt hier vor.

Registrierungsdaten sind nicht nur ein Verzeichnis. Sie sind ein operativer Datensatz, der von Registraren, Registranten, Sicherheitsteams, Rechteinhabern, Forschenden und automatisierten Systemen genutzt wird. Seine sinnvollen Eigenschaften sind:

• Eindeutigkeit:eine Abfrage löst auf das intendierte Objekt auf, nicht auf ein ambigües Duplikat.
• Genauigkeit:Felder spiegeln den autoritativen Zustand innerhalb eines kontrollierten Aktualisierungsintervalls wider.
• Herkunftsnachweis:ein Client kann den Dienst und die Autorität hinter einer Antwort identifizieren.
• Sicherheitsmetadaten:Status, Ereignisse, Hinweise und Links bleiben ohne verdeckten Datenverlust bestehen.
• Kontinuität:Auffindung und Antwort bleiben über Wartung und Übergänge verfügbar.
• Datenschutz:Offenlegungsgrenzen werden angewendet, ohne Bedeutung der Objekte zu verfälschen.

Die öffentlichen Protokolle legen fest, wie diese Eigenschaften dargestellt werden können. Sie beweisen nicht den privaten Prozess von Digity zur Aufrechterhaltung dieser Eigenschaften.

Backend-Heterogenität und Integrationsgrenzen

Die sichtbaren Datensätze von.caseund.radiopräsentieren keine einheitliche Providerkette..casenennt CentralNic als technischen Kontakt und nutzt eine CentralNic-RDAP-URL..radionennt CORE Association als technischen Kontakt und einen anderen RDAP-Pfad.[2][3] Die öffentliche Evidenz stützt daher eine enge Aussage: die zwei TLDs zeigen unterschiedliche technische Verantwortlichkeiten und Registrierungsdatenpfade. Sie stützt keine Behauptung über die vollständige Backend-Architektur, Vertragsreichweite, Exklusivität, Kapazität oder Störungsperformance.

Diese sichtbare Heterogenität ist relevant, weil Standardisierung und Trennung unterschiedliche Vorteile haben. Ein gemeinsamer Unternehmensinhaber kann eine einheitliche Rollenlogik, ein gemeinsames Freigabemodell, ein einheitliches Evidenzformat und eine gemeinsame Kontinuitätsrichtlinie nutzen. Unterschiedliche Servicepfade können eine Form gemeinsamer Fehleranfälligkeit reduzieren. Sie verpflichten den Eigentümer jedoch, Expertise, Zugriff, Überwachung und Eskalation über mehr als einen Betriebskontext hinweg aufrechtzuerhalten.

Integration beginnt auf Verantwortlichkeitsebene. Die Sponsoring-Organisation muss belegen können, wer pro TLD autorisiert ist, Änderungen anzufordern. Der technische Kontakt kann Arbeiten durchführen, ohne die endgültige Freigabe zu besitzen. Ein Anbieter kann einen Fehler erkennen, aber nicht die Erlaubnis haben, die Root-Zone zu ändern. Digity kann vertragliche Verantwortlichkeit tragen und dennoch Anbieterbelege benötigen, bevor eine Korrektur freigegeben wird. Diese Abgrenzungen sind nur dann stabil, wenn die Übergabepfade unter Druck funktionieren.

Integration setzt sich über Daten fort. Registrar-Transaktionen müssen den intendierten Registry-Zustand erzeugen. Dieser Zustand muss in WHOIS- und RDAP-Antworten, DNS-Veröffentlichung, Statuscodes, Billing- oder Berechtigungssteuerungen und Escrow-Abgaben, soweit relevant, reflektiert werden. Unterschiedliche Backends können dasselbe Protokoll umsetzen, aber in Tooling, Ereignis-Timing, Fehlerdetails, Credential-Management, Wartungsfenstern und Supporteskalationen variieren.

Die öffentliche Registrierungsoberfläche von.caseund die von.radioimplizieren zudem unterschiedliche Produktkontexte.[14][15] Die.radio-Seite beschreibt einen Namespace für die Radiogemeinschaft und enthält Eignungs- und Richtlinienaussagen. Die.case-Oberfläche stellt eigene registrierungsnahe Inhalte bereit. Öffentliches Marketing- oder Politik-Textfeld definiert intendierte Nutzung und kundenorientierte Steuerungen. Es beweist keine Durchsetzungskonsistenz, keine Fallzahlen, keine Registrierungs­erfolgsraten, keine Fehlerrückläufe oder Produktionszuverlässigkeit.

Ein Operator mit zwei verschiedenen Kontexten braucht ein Steuerungsmodell, das gemeinsame Anforderungen und lokale Unterschiede erhält. Ein praktikables Design könnte enthalten:

• ein unternehmensweites Register von Verantwortlichkeit und vertraglichen Pflichten;
• eine separate pro-TLD-Karte von Providerrollen, Kontakten, Berechtigungen, Endpunkten und Wartungsbeschränkungen;
• gemeinsame Evidenzanforderungen für risikokritische Änderungen;
• getrennte Staging- und Rollback-Entscheidungen, bei denen eine TLD isoliert werden kann;
• externe Überwachung, die nicht von Dashboards der einzelnen Backends abhängt;
• einen normalisierten Vorfalldatensatz, der weiterhin provider­spezifische Evidenz enthält;
• getestete Pfade für Datenexport, Credential-Wiederherstellung und Übergang des Betriebs.

Das Vorhandensein solcher Kontrollen kann aus öffentlichen Quellen nicht abgeleitet werden. Es sind Entscheidungstests, die aus der sichtbaren Systemform abgeleitet werden.

Portabilität ist der konkreteste Prüfpunkt für Lock-in. Anbieter-Einsatz ist kein Defekt. Spezialanbieter können Protokollunterstützung, operative Skalierung und ausgereiftes Tooling liefern. Lock-in-Risiko entsteht, wenn der verantwortliche Betreiber keine autoritativen Daten retten, Änderungszuständigkeiten an anderer Stelle etablieren, erforderliche Services reproduzieren oder einen Übergang unabhängig verifizieren kann.

Ein sinnvoller Portabilitätstest fragt, was exportierbar ist, in welchem Format, mit welcher Aktualität, unter welcher Befugnis und ob eine andere Betriebsumgebung es nutzen kann. Er umfasst Zonendaten, Domain- und Kontaktdatensätze, Status, Registrar-Zustand, DNSSEC-Material oder Übergabeverfahren, Politikhistorie, Escrow-Referenzen, Supportfälle, Überwachungs­erwartungen und Audit-Evidenz. Er fragt auch, welches Wissen nur im Personalgedächtnis oder in einem provider­spezifischen Interface liegt.

Die Transferhistorie macht diese Frage praktisch statt theoretisch..caseund.radiohaben bereits den Sponsoring-Wechsel durchgeführt.[4][5][10][11] Die Lehre ist nicht, dass erneut eine Übertragung geplant ist. Die Lehre ist, dass Namensräume voraussichtlich konkrete Unternehmens- und Technikarrangements überdauern. Kontinuität hängt davon ab, ob Datensatz und Betriebsfähigkeit über diese Änderung hinaus erhalten bleiben.

Vertrag, Escrow und Notfall-Kontinuitätsmechanismen

Die Registry-Vereinbarungen von.caseund.radioschaffen Pflichten für Registry-Services, Registrierungsdaten, Daten-Escrow, Interoperabilität, Kontinuität und Notfallübergang.[8][9] Die ICANN-Vertragsindizes und Erneuerungen dokumentieren den fortgesetzten vertraglichen Rahmen.[6][7][12][13] Diese Dokumente legen Verpflichtungen und Rückfallmechanismen fest. Sie beweisen weder einen aufgetretenen Vorfall noch dass jedes Servicelevel erreicht wurde.

Escrow adressiert eine schwierige Asymmetrie. Der tägliche Operator kann die aktuellsten Registry-Daten halten, aber ein Nachfolger oder Notfalloperator braucht diese Daten, wenn normaler Zugriff ausgefallen ist. Escrow ist nur dann nutzbar, wenn Sicherungsstände vollständig, zeitnah, korrekt formatiert, sicher übertragen und unter gültiger Befugnis wiederherstellbar sind. Eine Datei, die existiert, aber nicht entschlüsselbar, validierbar oder rekonstruierbar ist, ist kein operativer Wiederherstellungswert.

Das Emergency Back-End Registry Operator-Programm beschreibt einen abgegrenzten Mechanismus, der dazu dient, kritische Registry-Funktionen zu schützen, wenn ein Operator diese nicht bereitstellen kann.[16] Es ist eine zusätzliche Sicherheitsbarriere, kein Ersatz für routinehafte Kontinuität. Aktivierung erfordert klare Befugnis, nutzbare Daten, aktuelle Kontakte, Servicetransfer und Kommunikation. Es kann kritische Funktionen erhalten, nicht sofort alle Geschäftsprozesse.

Für Digity ergeben zwei übertragene TLDs eine Kontinuitätsfrage auf mehreren Ebenen:

1. Kann jede TLD unabhängig wiederhergestellt werden, wenn nur ein Servicepfad ausfällt?
2. Kann gemeinsame Unternehmensbefugnis noch handeln, wenn eine Provider-Identitätsstruktur nicht verfügbar ist?
3. Sind Escrow- und Exportverfahren mit der aktuellen Umsetzung je TLD kompatibel?
4. Können Root-Zone, DNSSEC, WHOIS, RDAP, Registrar- und Policy-Zustand nach einer Wiederherstellung abgeglichen werden?
5. Kann ein externer Beobachter feststellen, dass der wiederhergestellte Zustand autoritativ ist?

Die Vereinbarungen liefern einen Grund, diese Fragen zu stellen. Die Antworten liefern sie nicht.

Kontinuität hat eine zeitliche Dimension. Eine tägliche Sicherung kann für eine Datensatzklasse angemessen sein und für eine andere zu veraltet. DNS-Delegierung, Domain-Status, Registrar-Transaktionen, Missbrauchsfälle, Kontaktlisten und kryptografische Materialdaten ändern sich unterschiedlich schnell. Wiederherstellungsziele müssen die Folgen fehlender oder veralteter Zustände reflektieren, nicht mit einer generischen Kennzahl arbeiten.

Kontinuität hat auch eine Wissensdimension. Ein gültiges Backup kann keine Root-Zonenänderung authorisieren. Eine exportierte Datenbank erklärt nicht, warum eine Ausnahme gewährt wurde. Ein DNSSEC-Schlüssel ohne Rollen- und Lifecycle-Evidenz kann unbrauchbar oder unsicher sein. Eine Kontaktliste hilft nicht, wenn Identitäten und Authentifizierungswege veraltet sind. Dauerbetrieb braucht Daten, Autorität, Verfahren und getesteten Zugriff.

Das begleitende Foto zu diesem Artikel zeigt Wikimedia-Foundation-Server und dient nur als allgemeiner Kontext zu Serververkabelung und Wartung. Das Bild ist kein Beleg für Einrichtungen, Anbieter oder Sicherheit von Digity.

Vier wiederkehrende Betriebsaufwände

Die sichtbare Kontrolloberfläche erzeugt vier wiederkehrende Kosten, die selbst dann bestehen bleiben, wenn Routinearbeit automatisiert oder delegiert wird.

Überwachungskosten

Überwachungskosten verbinden eine technisch mögliche Aktion mit autorisierter Absicht. Sie umfassen Rollenprüfung, Änderungsfreigabe, unabhängige Verifikation, Zugriffskontrolle, Auslegung von Richtlinien, Vorfallsteuerung und Belegarchivierung. In einem Portfolio von zwei TLDs muss die Aufsicht verhindern, dass ein komfortabler Standardablauf falsche Annahmen auf beide Namensräume anwendet.

Die Kosten werden nicht nur in Personenstunden gemessen. Sie bedeuten, genug Expertise zu bewahren, um ein „grünes“ Dashboard zu hinterfragen, zu erkennen, dass ein syntaktisch gültiger Wert zur falschen TLD gehört, und eine Änderung zu stoppen, deren Befugnis unklar ist. Sie bedeuten externe Beobachtung und einen Wiederherstellungszugang, der auch dann funktioniert, wenn das normale Anbieterportal nicht verfügbar ist.

Integrationskosten

Integrationskosten entstehen zwischen Digity, IANA, ICANN, Registraren, technischen Kontakten, Backend-Services, Escrow, Überwachung, Rechtsprozessen und öffentlichen Nutzern. Standards reduzieren Formatzweideutigkeiten, aber nicht automatisch zeitliche Abstimmung von Credentials, Uhren, Wartungsfenstern, Eigentum oder Eskalation.

Die unterschiedlichen.case- und.radio-Kontakt- und RDAP-Pfade machen diese Kosten sichtbar.[2][3] Ein gemeinsamer Unternehmensstatusbericht kann Belege aus beiden Betriebskontexten verlangen. Eine Vorfallsklassifizierung muss Root-Delegierung, autoritärer DNS, DNSSEC, Registrar-Transaktion, RDAP, Richtlinien- und Netzwerkursachen trennen, bevor sie den korrekten Eigentümer erreicht.

Wartungskosten

Wartungskosten sichern die Leistungsfähigkeit. Sie decken Software- und Abhängigkeitsupdates, Zertifikatserneuerung, DNS- und DNSSEC-Lifecycle, Datenbankpflege, Monitoring-Änderungen, Backup-Validierung, Escrow-Abgaben, Zugriffsprüfungen, Kontaktaktualisierungen, Registrar-Kompatibilität, Richtlinienüberarbeitung und Wiederherstellungstests ab.

Infrequent ausgeführte Verfahren sind oft besonders teuer, weil sich Personal und Plattformen zwischen den Ausführungen ändern. Ein selten genutztes Konto kann verfallen. Eine Runbook-Beschreibung kann einen alten Dienststand beschreiben. Ein Wiederherstellungsschlüssel kann existieren, aber keinen nutzbaren Freigabepfad haben. Eine erfolgreiche geplante Aufgabe wurde möglicherweise nie über Wiederherstellung hinweg getestet.

Ausnahmebehandlungskosten

Ausnahmebehandlungskosten entstehen, wenn die erwartete Sequenz nicht funktioniert. Beispiele sind widersprüchliche Autoritätsdatensätze, partielle DNSSEC-Rollover, Reichweitenabweichungen zwischen Adressfamilien, ein RDAP-Objekt, das erreichbar, aber veraltet ist, ein Registrar-Vorgang mit unklarem Ergebnis, eine Datenschutzanforderung, die mit standardkonformer Antwort kollidiert, oder ein Anbieterstatus, der von der externen Beobachtung abweicht.

Diese Fälle benötigen Kontext und Zurückhaltung. Nicht jeder fehlgeschlagene Probewert ist ein Ausfall. Nicht jede erfolgreiche Antwort ist korrekt. Nicht jedes Nutzersymptom gehört der Registry. Das Gegenteil gilt ebenso. Der Operator muss Evidenz sichern, den Geltungsbereich eingrenzen, die Befugnis festlegen und so reagieren, dass ein begrenzter Fehler nicht aufgebläht wird.

Die vier Kosten verstärken sich gegenseitig. Schwache Wartung erzeugt Ausnahmen. Schlechte Integration macht Ausnahmen schwieriger zu lokalisieren. Schwache Aufsicht erlaubt eine fehlerhafte Änderungskette. Langsame Ausnahmebehandlung verlängert Auswirkungen und fördert widersprüchliche Aktionen. Ein Service kann pro Transaktion günstig sein und gleichwohl teuer zu betreiben bleiben, wenn er verantwortungsvoll geführt wird.

Register möglicher Ausfallmodi

Der öffentliche Datensatz stützt eine konkrete Ausfallanalyse, ohne dass irgendeines dieser Ereignisse bei Digity behauptet wird.

1. Drift der Sponsoring-Identität

Die juristische Entität, die ICANN-Vereinbarung, der IANA-Sponsor-Datensatz, das Verzeichnisobjekt und das authentifizierte Änderungskonto verweisen nicht mehr auf dieselbe Organisation. Eine technisch korrekte Anfrage kann dann fehlschlagen, weil die Befugnis unklar ist. Die Erkennung erfordert einen Abgleich über Datensätze; die Behebung erfordert einen verantwortlichen Eigentümer, dokumentierte Evidenz und eine kontrollierte Aktualisierungsabfolge.

2. Veralterung des administrativen Kontakts

Eine E-Mail-Adresse, Telefonnummer, Postanschrift oder eine benannte Rolle bleibt veröffentlicht, nachdem die Verantwortung gewechselt hat. Routinebetrieb kann weiterlaufen, während die Notfall-Befugnis schleichend verschlechtert. Gute Kontrolle prüft Erreichbarkeit und Berechtigung, nicht nur, ob ein Feld belegt ist.

3. Nichtübereinstimmung technischer Kontaktzuständigkeiten

Ein Anbieter oder Verband bleibt technischer Kontakt, obwohl der Umfang seiner Arbeit sich ändert, oder ein neuer Anbieter betreibt Services ohne korrekten Eskalationsnachweis. Digity kann einen Bericht erhalten, aber nicht in der Lage sein, ihn an die Partei mit Diagnoseschlüssel weiterzugeben. Abhilfe ist eine Verantwortlichkeitskarte je TLD mit aktuellen Verträgen und Systemen.

4. Fehlende Übergangsbestandteile bei der Übertragung

Eine Übertragung verschiebt vertragliche Verantwortung, lässt aber ein Credential, eine Monitoring-Regel, eine Policy-Ausnahme, Registrar-Abhängigkeit oder Support-Historie aus. Der Namespace kann funktionsfähig erscheinen, bis genau das fehlende Element benötigt wird. Eine unterschriebene Checkliste ist schwächer als eine geprüfte Übung mit den übertragenen Assets.

5. Inkonsistenz in der Root-Delegierung

Die in IANA intendierte Nameserver- oder Glue-Daten weichen von der beabsichtigten Konfiguration des Operators oder vom laufenden autoritativen Service ab. Ursache kann eine unvollständige Änderung, veraltetes Inventar oder eine unautorisierte Anfrage sein. Die Reaktion muss genehmigte Änderungsbelege, direkte autoritative Antworten und Root-Daten vergleichen, bevor eine weitere Aktualisierung erfolgt.

6. Divergenz zwischen IPv4 und IPv6

Eine Adressfamilie erreicht den autoritativen Service, während die andere ausfällt oder einem anderen Routing-Pfad folgt. Ein Monitoring, das nur eine Familie prüft, berichtet Erfolg. Der Operator benötigt unabhängige Dual-Stack-Beobachtung und ein Verfahren zur Unterscheidung zwischen Delegation, Routing, Filterung und Serverursache.

7. Korrigierte Namensserverkorrelation

Vier veröffentlichte Namen können von einer gemeinsamen Kontrollschicht, einem Software-Release, einer Routing-Policy, einem Credential oder einem vorgelagerten Netz abhängen. Der Root-Datensatz wirkt divers, während ein gemeinsamer Fehler mehrere Pfade betrifft. Öffentliche Daten können diese Topologie weder beweisen noch widerlegen; Resilienztests müssen reale Fehlerdomänen prüfen.

8. DNSSEC-Fehlausrichtung zwischen Eltern- und Kindzone

Die DS-Daten der Elternzone und der DNSKEY-Satz des Kindes bilden nicht mehr die vorgesehene Kette. Validierende Resolver können ein falsches Ergebnis liefern, während nicht-validierende Prüfungen normal aussehen. Prävention braucht gestaffelte Übergänge, Überlappung, unabhängige Validierung, Zeitdisziplin und explizite Rollback-Bedingungen.

9. Blindspot bei Signaturablauf

Zonensignaturen nähern sich dem Ablauf, ohne wirksame Alarme, oder der Alarm ist nur in einer fehlerhaften Kontrollschicht vorhanden. Der Service kann scheinbar gesund bleiben, bis gecachte Daten altern. Externe Validierung und Tests zur Alarmzuständigkeit reduzieren das Risiko.

10. Falsche-TLD-Automation

Ein Standard-Workflow oder Skript überträgt.case-Daten auf.radio, oder umgekehrt. Eine durchgängige Automatisierung wiederholt dann eine semantisch falsche Aktion. Je-TLD-bezogene Bezeichner, unveränderbare Review-Evidenz, begrenzte Credentials und unabhängige Nachänderungsprüfungen sind wertvoller als generische Erfolgsmeldungen.

11. Abdrift der RDAP-Bootstrap

IANA-Bootstrapdaten leiten Clients auf einen Service, der den intendierten Registry-Pfad nicht mehr repräsentiert, oder die Transition wird nur teilweise in Caches und Clients abgebildet.[20] Direkte Endpunktprüfungen können bestanden werden, während die Standard-basierte Entdeckung fehlschlägt. Sowohl Discovery als auch Verhalten müssen überwacht werden.

12. RDAP-Objektveraltung

Ein Endpunkt liefert HTTP-Erfolg und gültiges JSON, aber veraltete Status-, Ereignis-, Link- oder Entitätswerte werden ausgegeben. Verfügbarkeitsmonitoring übersieht dann einen semantischen Fehler. Erkennung braucht den Vergleich mit dem autoritativen Registry-Zustand und kontrollierte Erwartungen für Aktualisierungsintervalle.

13. Inkompatibilität im RDAP-Fehlermodell

Client und Server unterscheiden sich bei Abfrageformat, Statusbehandlung, Hinweisen, Weiterleitungen oder Fehlerantworten nach RFC 9082 und RFC 9083.[17][18] Erfolgsfälle laufen durch, während Untersuchungstools bei Ausnahmefällen scheitern. Vertragstests sollten auch fehlerhafte, fehlende, unautorisierte und ratelimitierte Szenarien testen, ohne schädlichen Traffic zu erzeugen.

14. WHOIS- und RDAP-Bedeutungsabweichung

Die Legacy-WHOIS-Antwort und das strukturierte RDAP-Objekt beschreiben dieselbe Domain unterschiedlich genug, um Nutzer irrezuführen. Die beiden Protokolle müssen nicht identisch dargestellt sein, aber materielle Status- und Autoritätswerte sollten nachvollziehbar bleiben. Datenschutzbehandlung kann differieren, ohne dass eine Ausgabe semantisch falsch wird.

15. Registrar-Transaktionsunklarheit

Ein Registrar bricht eine Zeitüberschreitung nach Create-, Update-, Renew-, Transfer- oder Delete-Operation ab und kann nicht feststellen, ob die Registry den Auftrag ausgeführt hat. Blindes Wiederholen kann Doppelarbeit oder Konflikte mit dem aktuellen Zustand verursachen. Idempotenz, Transaktionsnachweis und klarer Abgleichspfad sind erforderlich.

16. Lücke bei der öffentlichen Politikdurchsetzung

Die.radio-Öffentlichkeitsseite beschreibt Eignung und Kontrollpfade, aber ein operativer Fall folgt nicht dem beschriebenen Pfad oder hat nicht erreichte Ownership.[15] Das Vorhandensein von Policy-Text ist ein Fähigkeitsbeleg, kein Beleg konsistenter Durchsetzung. Eine Prüfung benötigt Falldaten, Zeitleisten und rechtskonforme Ausnahmebehandlung.

17. Nicht nutzbarer Escrow-Bestand

Ein Deposit ist vorhanden, aber unvollständig, veraltet, verschlüsselt unter nicht verfügbarer Autorität oder inkompatibel mit einer Wiederherstellungsumgebung. Eine Dateianzahl signalisiert Abschluss, während Kontinuität versagt. Validierung und Wiederherstellungsübungen müssen nutzbaren Zustand statt bloßer Aufgabenerfüllung testen.

18. Scheitern der Notfall-Transition-Befugnis

Es besteht ein schwerer Servicefall, aber die Parteien können nicht feststellen, wer eine Notfallmaßnahme aktivieren, Daten freigeben, Delegierung ändern oder Statuskommunikation veröffentlichen darf.[16] Technische Wiederherstellungskapazität bleibt dann hinter einer Befugnislücke zurück. Übungen sollten Freigabepfade und Identitätswege enthalten, nicht nur Datenbewegung.

19. Ausfall der Provider-Kontrollebene

Das öffentliche DNS beantwortet weiterhin über verteilte Instanzen, während Portal, Identitätssystem, Monitoring oder Change-API nicht verfügbar sind. Das ist ein Teilkontinuitätszustand, keine Vollständigkeit. Digity benötigt externe Beobachtung, Wiederherstellungszugriff und Regeln, wann die fehlende Änderungsfähigkeit selbst als Vorfall gilt.

20. Fehlzuordnung von Kundensymptomen

Eine Website, ein Mailsystem oder eine Anwendung fällt aus und die Registry wird angeführt, bevor Delegierung, Registrar-Status, autoritärer DNS, Resolver, Routing, Zertifikat, Hosting und Anwendung getrennt betrachtet wurden. Das Gegenbild ist ebenfalls möglich: Ein Registry-Problem wird als Application-Issue abgetan. Eine zeitgestempelte Evidenzstaffel hilft, beide Fehler zu vermeiden.

Diese Ausfallmodi sind keine Bewertungs-Rangliste für Digity. Sie sind ein Register, das aus den öffentlich sichtbaren Verantwortlichkeiten abgeleitet ist. Ihr Wert ist, vage Formulierungen zur Belastbarkeit in beobachtbare Entscheidungspunkte zu übersetzen.

Leitende Entscheidungstests und Evidenzgrenzen

Technische Leitungskräfte sollten Digitys Kontrolloberfläche mit Prüfanforderungen bewerten, die die Grenze zwischen Verantwortlichkeit und privater Implementierung erhalten.

Erstens sollte eine exakte Verantwortlichkeitskarte je TLD verlangt werden. Sie sollte vertragliche Verantwortlichkeit, Root-Zonenbefugnis, technische Ausführung, DNSSEC-Verwahrung, Registrar-Support, RDAP- und WHOIS-Betrieb, Escrow, Policyfälle, Vorfallkommunikation und unabhängige Verifikation trennen. Die öffentlichen Kontakte von.caseund.radiozeigen, warum ein einziger generischer Anbieterbegriff unzureichend ist.[2][3]

Zweitens sollte geprüft werden, wie Übergangsevidenz nutzbar bleibt, nachdem das Transitionsteam auseinandergegangen ist. Die IANA-Berichte zeigen, dass Antrags-, Kontakt- und Technikkonformitäts-Gates abgeschlossen wurden.[4][5] Eine aktuelle Betriebsprüfung sollte zeigen, welche Kontrollen diesen Zustand halten: Kontaktverifikation, Zugriffsprüfung, aktuelle Abhängigkeitskarten, getesteter Export und nachvollziehbare Änderungs-Historie.

Drittens sollte geprüft werden, wie geplanter Zustand mit laufendem Zustand verglichen wird. Die Antwort sollte Root-Einträge, direkte autoritative DNS, DNSSEC-Validierung, IPv4 und IPv6, RDAP-Discovery, Antwortsemantik und externe Beobachtung umfassen. Kein einzelnes Dashboard sollte allein zertifizieren dürfen.

Viertens sollte geprüft werden, wie Unterschiede zwischen den beiden Servicepfaden kontrolliert werden. Standardisierung sollte Evidenz, Freigabe, Schweregrade und Wiederherstellung abdecken. Provider-spezifische Verfahren sollten die Unterschiede erhalten, die für sicheren Betrieb nötig sind. Eine gemeinsame Vorlage ist nützlich; eine falsche Annahme identischer Backends nicht.

Fünftens sollten Kontinuitätsbelege statt Kontinuitätssprache verlangt werden. Nützlich sind validierter Escrow, Wiederherstellungsergebnisse, Wiederherstellungszugriff, Kontakt-Drills, DNSSEC-Recovery, Exporttests und ein Szenario, in dem eine TLD von der anderen isoliert wird. Der EBERO-Rahmen gibt einen äußeren Kontext vor, aber Routinewiederherstellung liegt beim Operator und seinen Anbietern.[16]

Sechstens sollten die Grundlagen jeder Zuverlässigkeitsaussage geprüft werden. Produktzuverlässigkeit braucht einen definierten Service, eine Metrik, ein Beobachtungsfenster, Sichtpunkte, Ausschlüsse und Fehlerbehandlung. Eine begrenzte Aufnahme korrekter DNS- und RDAP-Objekte ist ein Fähigkeitsnachweis zu diesem Zeitpunkt, keine Uptime-Quote.

Siebtens sollte die Basis jeder Kundenaussage geprüft werden. Ein Kundenergebnis in der Produktion braucht einen identifizierten Anwendungsfall, Baseline, Zeitfenster, Messmethode, Zuordnungslogik und Begrenzungen. Öffentliche Registrierungsseiten und TLD-Zweckbestimmungen liefern diese Elemente nicht.[14][15]

Achtens sollte geprüft werden, ob Portabilität unter realistischen Befugnisszenarien getestet wird. Export bei voller Systemverfügbarkeit ist hilfreich, aber unvollständig. Eine belastbare Übung geht davon aus, dass ein Anbieterkonto, eine Personalrolle oder eine Kontroll-Ebene ausgefallen ist, und prüft, ob Digity weiterhin Befugnis herstellen, nutzbaren Zustand wiederherstellen und einen Folgeweg verifizieren kann.

Neuntens sollte überprüft werden, wie Ausnahmen verhindern, dass sie automatisch zu Richtlinien werden. Eine einmalige manuelle Korrektur kann einen undokumentierten Zustand erzeugen, der später wie autoritativ wirkt. Ausnahmeprotokolle sollten Evidenz, Befugnis, Geltungsbereich, Ablauf und erforderliche Rückkehr in den Normalzustand erfassen.

Schließlich sollte klar benannt werden, was bewusst unbekannt bleibt. Der öffentliche Datensatz offenbart keine private Topologie, kein Personal, keine Verträge, kein Sicherheitsdesign, keine Reaktionszeiten bei Vorfällen und keine Kundenergebnisse. Eine belastbare Prüfung markiert diese Felder als unbekannt statt sie zu spekulieren. Damit wird die verbleibende Evidenz nutzbarer, weil Leser zwischen gesicherten Datensätzen und nicht durch den Operator belegten internen Fakten unterscheiden.

Fazit

Die technische Bedeutung von Digity, LLC liegt in der Funktion als verantwortlicher Registry-Operator für zwei separat übertragene Top-Level-Domains. Die aktuellen IANA-Datensätze, Transferberichte, Vereinbarungs-, Zuweisungs- und Erneuerungsunterlagen, öffentlichen Registrierungsoberflächen, Protokollstandards und begrenzten Beobachtungen begründen eine reale DNS-, DNSSEC-, WHOIS-, RDAP- und Kontinuitäts-Kontrolloberfläche.[2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20]

Die Evidenz zeigt Fähigkeit und Verantwortlichkeit. Sie offenbart keine private Architektur, beweist keine langfristige Produktzuverlässigkeit und stellt kein Kundenergebnis in der Produktion fest. Der sichtbare Unterschied zwischen den technischen Kontakten und RDAP-Pfaden von.caseund.radiosollte als Integrations- und Kontinuitätsfrage behandelt werden, nicht als Beleg für Schwächen oder Robustheit.

Überwachung hält autorisierte Absicht an Technikmaßnahmen gekoppelt. Integration bringt Organisationen, Protokolle und Evidenz in Einklang. Wartung erhält Schlüssel, Daten, Software, Kontakte und Wiederherstellungszugriff. Ausnahmebehandlung löst die Fälle, in denen visuell korrekte Schichten widersprüchlich werden. Escrow und Notfall-Transition liefern eine äußere Sicherheitsgrenze, nützlich nur, wenn Daten und Befugnis weiterhin nutzbar bleiben.

Die breitere Lehre ist, dass ein Namespace unter company- und Technikwechseln nur überlebt, wenn Datensätze genau bleiben, laufende Dienste diese Datensätze weiterhin bedienen und eine verantwortliche Organisation Registry-Verantwortung übertragen oder wiederherstellen kann, ohne eigene Zustände zu erfinden. Digitys zwei Transfer-Historien machen diesen Grundsatz konkret: Zuständigkeit kann wechseln, aber die operative Kontinuität des Namespace darf nicht zwischen Verträgen, Anbietern und Systemen verschwinden.

Quellen

[1] BTW-Verzeichnis, "Digity, LLC":https://btw.media/en/directory/digity-llc

[2] IANA Root Zone Database, ".CASE":https://www.iana.org/domains/root/db/case.html

[3] IANA Root Zone Database, ".RADIO":https://www.iana.org/domains/root/db/radio.html

[4] IANA, "Transfer Report for case":https://www.iana.org/reports/tld-transfer/20230531-case

[5] IANA, "Transfer Report for radio":https://www.iana.org/reports/tld-transfer/20260225-radio

[6] ICANN, ".case Registry Agreement":https://www.icann.org/en/registry-agreements/details/case

[7] ICANN, ".radio Registry Agreement":https://www.icann.org/en/registry-agreements/details/radio

[8] ICANN, ".case Registry Agreement text":https://itp.cdn.icann.org/en/files/registry-agreements/case/case-agmt-html-03sep15-en.htm

[9] ICANN, ".radio Registry Agreement text":https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-agmt-html-21jul16-en.htm

[10] ICANN, ".case Assignment":https://itp.cdn.icann.org/en/files/registry-agreements/case/case-assign-pdf-08-07-2022-en.pdf

[11] ICANN, ".radio Assignment":https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-assign-pdf-05-01-2026-en.pdf

[12] ICANN, ".case Renewal":https://itp.cdn.icann.org/en/files/registry-agreements/case/case-renewal-1-11-06-2025-en.pdf

[13] ICANN, ".radio Renewal":https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-renewal-1-22-05-2026-en.pdf

[14] Digity, ".case registration services":https://www.digity.case/case

[15] dotRadio, ".radio public registry surface":https://www.nic.radio/

[16] ICANN, "Emergency Back-End Registry Operator":https://www.icann.org/en/contracted-parties/registry-operators/resources/emergency-back-end-registry-operator

[17] IETF, RFC 9082, "Registration Data Access Protocol Query Format":https://www.rfc-editor.org/rfc/rfc9082.txt

[18] IETF, RFC 9083, "JSON Responses for the Registration Data Access Protocol":https://www.rfc-editor.org/rfc/rfc9083.txt

[19] IETF, RFC 4035, "Protocol Modifications for DNS Security Extensions":https://www.rfc-editor.org/rfc/rfc4035.txt

[20] IANA, "RDAP Bootstrap Service Registry for Domain Name Space":https://data.iana.org/rdap/dns.json

[21] CentralNic RDAP, "nic.case":https://rdap.centralnic.com/case/domain/nic.case

[22] dotRadio RDAP, "nic.radio":https://rdap.nic.radio/domain/nic.radio

[23] Wikimedia Commons, "Wikimedia Foundation Servers 2015-88":https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Servers_2015-88.jpg