Zusammenfassung

  • Client X kann Domain und Host der gewünschten Löschung verwalten, während eine Domain von Client Y diesen Host weiterhin als Nameserver nutzt.
  • Umbenennung, pendingDelete, Nachricht, Restore, Purge und DNS-Erholung sind getrennte Ereignisse; eine Erfolgsmeldung belegt sie nicht gemeinsam.

Ein EPP-Löschbefehl wirkt lokal: Der Sponsor verlangt die Entfernung seines Objekts, der Server prüft Regeln und antwortet. RFC 9874 beschreibt die Ausnahme als Kernproblem. X sponsert eine Domain und deren untergeordneten Host, Y hat denselben Host mit einer anderen Domain verknüpft. X kann die eigene Beziehung entfernen, aber Ys Objekt nicht ändern.

RFC 5731 rät schon davon ab, eine Domain mit verbundenen untergeordneten Hosts zu löschen. RFC 5732 schützt Hosts, von denen andere Objekte abhängen. So wird aus einer sauberen Objektoperation nicht unbemerkt ein DNS-Ausfall. Offen bleibt, wie X rechtmäßig aussteigen kann, ohne Ys Infrastruktur ewig zu tragen.

Eine beobachtete Praxis benennt den Host aus der zu löschenden Domain heraus um. Die Verknüpfung bleibt, doch Kontrolle kann wandern. Ist die neue Elterndomain registrierbar oder wechselt ihren Inhaber, könnte ein Dritter den Host anlegen und Anfragen der abhängigen Domains empfangen. Die Umbenennung beseitigt die Angriffsfläche nicht, sondern übergibt sie womöglich einem künftigen Fremden. RFC 9874 verbietet einen externen Namen, dessen Nichtexistenz bloß vermutet wird.

Ein bekannter rekursiver Resolver ist ebenfalls kein Ersatz für den autoritativen Dienst einer Delegation. AS112-Namen sind kein allgemeiner Opferdienst; Zweckentfremdung kann lokale Übernahme und fremde Betriebslast erzeugen.

Als BCP 244 begrenzt RFC 9874 sichere Wege auf drei Gruppen. Der Client kann einen eigenen autoritativen Opferhost pflegen, dessen Elternregistrierung, Adressen und Dienst bestehen bleiben. Der Server kann Hosts samt Beziehungen ausdrücklich löschen und Details, Benachrichtigung sowie Restore anbieten. Oder es entsteht eine Special-Use-Domain, wofür sacrificial.invalid empfohlen wird. Die beiden letzten Wege werden nicht als heutige Praxis behauptet.

Im reversiblen Modell bleiben Domain, untergeordnete Hosts und Fremdbeziehungen während pendingDelete erhalten. Öffentliches DNS kann bereits ausfallen und den Schaden anzeigen; vor dem endgültigen Purge erlaubt RFC 3915 noch die Wiederherstellung. Antrag, reversibler Zustand, Reaktionsfrist und unwiderrufliche Entfernung brauchen eigene Zeitpunkte.

Auch Benachrichtigung ist nicht Reparatur. Der Server kann dem Löschenden betroffene Objekte zeigen und andere Sponsoren über Change Poll aus RFC 8590 informieren. Eine Nachricht beweist weder Abruf noch Kontakt zum Registranten, korrigierte Delegation oder wiederhergestellten Dienst.

Unbegrenzt viele Verknüpfungen können asynchrone Lose für Deaktivierung, Restore oder Purge erfordern. Das löst Last, nicht Berechtigung. Ein beendeter Auftrag belegt keine Gleichzeitigkeit oder Resolver-Konvergenz.

Heng Lus Realitätsebenen trennen erklärte Absicht, gespeicherte Beziehungen, angenommene Transition, autoritative Zone, Resolver-Beobachtung und Nutzerergebnis. Die minimale Anfangsspezifikation verbindet einen schmalen Vertrag mit lokalen Entscheidungen über Freigabe und Restore. Der Vorrang von laufendem Code verlangt wiederholbare Spuren statt Vertrauen in einen grünen Status.

DNSSEC senkt einzelne Risiken, ersetzt aber keinen Nachweis. Automatisierung, die CDS/CDNSKEY eines einzigen kompromittierten Nameservers akzeptiert, kann aus einer Abweichung einen tieferen Kontrollwechsel machen.

SAC125 und der IETF-115-Vortrag Risky BIZness liefern Kontext zu Nameserver-Risiken. Sie belegen keine aktuelle Schwäche eines genannten Betreibers. RFC 9874 ist eine Entwurfsantwort auf eine Risikoklasse, kein Vorfallbericht.

Quellen