Zusammenfassung

  • Client X kann Domain und untergeordnetes Hostobjekt verwalten, während eine Domain von Client Y denselben Host als autoritativen Nameserver nutzt.
  • Die Umbenennung auf vermeintlich freie Namen oder nicht autoritative Resolver verschiebt Ausfall- und Übernahmerisiken; RFC 9874 verbietet diese beobachteten Praktiken.
  • Ein clientübergreifender Löschbeleg sollte Berechtigung, Abhängigkeitsumfang, DNS-Zustand, Benachrichtigung, Redemption, Restore und asynchronen Abschluss getrennt nachweisen.

domain1.example soll verschwinden. Sein untergeordneter Host ns1.domain1.example gehört zu Client X. Doch domain2.example, gesponsert von Client Y, verwendet genau diesen Host. X kann Ys Domain weder ändern noch muss X die Verbindung sehen dürfen. Der Registry-Server kennt beide Seiten.

Damit wird aus einem Aufräumbefehl eine Zuständigkeitsfrage. Der Server darf Erfolg nicht als Beweis für Tatsachen behandeln, die erst danach entstehen: fortbestehende DNS-Kontrolle, zugestellte Hinweise, verfügbare Wiederherstellung und vollständig abgearbeitete Hintergrundprozesse.

Was die Löschwarnungen bewahren

RFC 5731 rät davon ab, eine Domain mit zugeordneten untergeordneten Hosts zu löschen. RFC 5732 rät davon ab, ein Hostobjekt zu löschen, solange andere Objekte darauf verweisen. Hinter diesen Formulierungen stehen drei unterschiedliche Konsistenzen.

DNS-Konsistenz verhindert, dass der Name des Hosts oder die abhängigen Delegationen unauflösbar werden. Client-Server-Konsistenz verhindert, dass der Server Beziehungen still entfernt, während der Client sie weiterhin als registriert betrachtet. Relationale Konsistenz schützt interne Verknüpfungen der Registry-Datenbank.

Bei zwei Clients kommt die Verteilung der Autorität hinzu. Y darf die betroffene Domain ändern. X möchte das tragende Objekt beenden. Der Registry-Server entscheidet, ob diese widersprüchlichen Rechte blockiert, umgebogen oder in einen rückholbaren Übergang überführt werden.

Ein Opfer-Host bleibt jemandes Verantwortung

Durch Umbenennung kann der Host außerhalb der zu löschenden Domain weiterbestehen. Der sogenannte sacrificial host ist jedoch kein neutraler Ablageort.

Ein externer, vermeintlich nicht existierender Elternname kann später registriert werden. Ein Angreifer könnte den Host anlegen und Anfragen abhängiger Domains kontrollieren. RFC 9874 erklärt diese beobachtete Praxis zum MUST NOT.

Glue auf die Adresse eines öffentlichen rekursiven Dienstes zu setzen, schafft keine Autorität. SERVFAIL und aggressive Wiederholungen können folgen. Auch diese Praxis darf nicht verwendet werden.

Zulässig ist ein vom Client gepflegter autoritativer Opfer-Host. Dafür muss der Client die Eltern-Domain behalten, schützen und autoritatives DNS auf den eingetragenen Adressen betreiben. Das verhindert eine fremde Übernahme, erzeugt aber eine dauerhafte Sorgfaltspflicht. Ablauf, Betreiberwechsel oder ein verlorener Lock können das alte Risiko Jahre später zurückbringen.

Redemption macht einen kontrollierbaren Zwischenraum

Die zweite Architektur erlaubt eine ausdrückliche Löschung samt Beziehungen zu Domains anderer Clients. Der Server kann dem anfordernden Client Wirkungsdetails zeigen, bewusste Freigabe verlangen und Betroffene etwa über EPP Change Poll informieren.

Mit RFC 3915 können Domain, untergeordnete Hosts und Beziehungen während der Redemption-Periode in pendingDelete bleiben. Im DNS kann die Abschaltung sichtbar werden, während die Struktur noch wiederherstellbar ist. Bei Versehen, Missbrauch oder unerwarteter Wirkung kann Restore den Verbund zurückbringen. Erst am Ende folgt der endgültige Purge.

Die Zahl der Beziehungen ist nicht begrenzt. Deaktivieren, Reaktivieren und Bereinigen können deshalb in asynchrone Teiltransaktionen zerlegt werden. Die Annahme des Befehls und der Abschluss des Objektgraphen sind verschiedene Zeitpunkte.

Der Beleg folgt der Abhängigkeit

Zuerst hält er authentifizierten Client, Transaktion, Zielobjekt, Zeitpunkt, Serverrichtlinie und Berechtigungsgrund für clientübergreifende Wirkung fest. Dann friert er die Abhängigkeitsansicht ein: Erhebungsmethode, Zeitpunkt, Hostobjekte, Anzahl betroffener Domains und Clients sowie Sichtbarkeitsgrenzen.

Der DNS-Teil zeigt autoritative Namen und Adressen vor und nach der Aktion, erwarteten und beobachteten Zonenzustand, DNSSEC- und DS-Bedingungen und die gewählte RFC-9874-Praxis. Warnungen, angezeigte Details, menschliche Freigabe und Entscheidungsgrund bilden den nächsten Block.

Für Betroffene werden Queue, Zustellung und Bestätigung der Mitteilung erfasst, ohne Registrantendaten offenzulegen. Redemption-Frist, Restore-Berechtigung, erhaltene Beziehungen und Wiederaufbautest belegen die Umkehrbarkeit. Task-IDs, Teilfehler, Wiederholungen, endgültiger Purge und abschließende DNS-Beobachtung schließen den asynchronen Teil.

Dieser Beleg ist Daniel Kades Betriebsvorschlag, keine neue EPP-Erweiterung und keine Forderung des RFC. Datenschutz kann Namen durch Zählwerte oder Referenzen ersetzen; er darf die Prüfung selbst nicht verschwinden lassen.

DNSSEC übernimmt die Qualität seiner Eingangsdaten

DNSSEC und mehrere Nameserver mindern Risiken, beseitigen aber keine schlechte Verwahrung. RFC 9874 nennt den Fall, dass ein Angreifer einen Server kontrolliert und eine fehlerhafte automatische DS-Pflege inkonsistente CDS/CDNSKEY-Antworten nicht über alle Server prüft. So kann fremdes Material in den DS-Zustand gelangen; CSYNC kann die legitimen Server weiter verdrängen.

Der Beleg muss daher zeigen, ob DS-Automation aktiv war, welche Server befragt wurden, ob Antworten übereinstimmten und wer die Änderung autorisierte. „DNSSEC aktiv“ ist kein Ergebnisnachweis.

Erfolg hat mehrere Schichten

RFC 9874 empfiehlt einen gepflegten autoritativen Opfer-Host, eine ausdrückliche Löschung mit Details, Benachrichtigung und Restore oder eine geeignete Special-Use-Domain. Bequeme Varianten, deren Last bei Dritten landet, werden verworfen.

Löschen bleibt erlaubt. Unzulänglich ist nur die Zusammenfassung in einem Status. Angenommen, Abhängigkeiten gezählt, Betroffene benachrichtigt, Wiederherstellung offen und Purge beendet sind fünf Aussagen. Wenn jede ihren Beleg erhält, wird die Änderung regierbar. Wenn ein Response-Code sie alle vertreten soll, bleibt die wichtigste Wirkung unsichtbar.

Quellen