Zusammenfassung

  • RFC 10026 behandelt clientUpdateProhibited und serverUpdateProhibited als Kontrollen für bestimmte Akteure und Befehlswege, nicht als Nachweis, dass jeder Weg zu den DS-Daten eingefroren ist.
  • Bei Schlüssel- und Algorithmuswechseln kann authentisierte, geprüfte DS-Wartung die DNSSEC-Kontinuität sichern. Sperrstatus, Kind-Signal, Entscheidung und Veröffentlichung bleiben getrennte Belege.
  • Ein „gesperrt“-Symbol autorisiert keine Änderung und beweist auch keinen Stillstand. Belastbar wird die Aussage erst durch ein akteursbezogenes Entscheidungsprotokoll, Benachrichtigungen und einen unabhängigen Wiederherstellungsweg.

Das grüne Schloss in einem Kundenportal wirkt wie eine vollständige Sicherheitsauskunft. In einer Untersuchung belegt es jedoch zunächst nur den Darstellungszustand einer Oberfläche zu einem bestimmten Zeitpunkt. Es sagt weder, welcher Status auf dem EPP-Server gespeichert war, noch welcher Akteur später auf welchem Weg handelte.

RFC 10026 wurde im Juli 2026 als Best Current Practice 246 veröffentlicht. Das Dokument gibt operative Empfehlungen für die automatisierte Pflege von DNSSEC Delegation Signer Records; der RFC Editor führt Steve Sheng und Peter Thomassen als Autoren. Sein Rat entwertet Sperren nicht. Er verlangt vielmehr, einem Statusnamen keine Macht zuzuschreiben, die sein Akteursmodell nicht enthält.

Das Präfix benennt die Seite der Kontrolle

RFC 5731 ordnet EPP-Domainstatus einer Autoritätsbeziehung zu. Ein mit client beginnender Status wird vom sponsernden Client, gewöhnlich dem Registrar, gesetzt oder entfernt. Ein server-Status steht unter Kontrolle des Servers, gewöhnlich der Registry. clientUpdateProhibited und serverUpdateProhibited verlangen beide, Aktualisierungsanfragen für das Objekt zurückzuweisen – ausgenommen die Anfrage, den Status selbst zu entfernen.

Die sprachliche Symmetrie endet bei den Befugnissen. Ein Client darf einen serverseitigen Status nicht verändern. Der Server kann dagegen einen clientseitigen Status im Rahmen seiner lokalen Richtlinie ändern oder übersteuern. Der Ausdruck „Update verboten“ ist deshalb ohne Absender und Adressat unvollständig.

Eine clientseitige Aktualisierungssperre schützt vor allem den gewöhnlichen Update-Befehl des sponsernden Registrars als EPP-Client. Der Registrar kann seinen eigenen Status entfernen. Die Registry verliert durch eine Client-Markierung nicht ihre technische Handlungsfähigkeit. Die Sperre kann Fehlbedienung im Kundenportal, Missbrauch eines Kundenkontos oder fehlerhafte Automatisierung eindämmen, ohne Registrar und Registry als privilegierte Akteure technisch auszuschließen.

Eine serverseitige Aktualisierungssperre bindet den Registrar stärker: Seine Update-Anfrage muss zurückgewiesen werden. Dennoch erklärt der Status nicht, der Serverbetreiber habe seine eigene Fähigkeit zu einer lokal autorisierten Zustandsänderung gelöscht. Über deren Rechtmäßigkeit entscheiden Richtlinie, Autorisierung und Ausführungsnachweis, nicht das Wort auf dem Badge.

Der erste brauchbare Beleg lautet daher nicht bloß „Sperre vorhanden“. Er nennt Setzer und Zeitpunkt, die zurückgewiesene Befehlsklasse sowie die Akteure und Wege, die weiterhin handeln können.

DNSSEC macht ewigen Stillstand zum Verfügbarkeitsrisiko

Manche Registrierungsdaten lassen sich einmal konfigurieren, sperren und lange unverändert lassen. DNSSEC enthält dagegen Vertrauenszustand, der sich bewegen muss, um sicher zu bleiben. Schlüssel werden gerollt, Algorithmen außer Betrieb genommen, DNS-Betreiber gewechselt. Der DS-Satz im Parent muss dem Kind folgen, ohne den Validierungspfad zu verlieren.

Eine universelle Starre kann eine Sicherheitskontrolle in einen Ablaufmechanismus verwandeln. Hat das Kind einen neuen Schlüssel vorbereitet, der Parent hält aber wegen einer als absolut verstandenen Standardsperre am alten DS fest, kann nach Außerbetriebnahme des alten Schlüssels nur noch ein Verweis auf nicht mehr verwendetes Vertrauensmaterial übrig bleiben. Der alte Wert ist unversehrt, seine Schutzfunktion jedoch zerstört.

RFC 7344 erlaubt dem Kind, mit CDS oder CDNSKEY eine parentseitige DS-Wartung anzufordern. RFC 9615 ergänzt ein authentisiertes Bootstrapping für Delegationen ohne bestehenden DS-Pfad. Diese Signale sind keine anonymen Wünsche und keine selbstvollstreckenden Befehle. Sie liefern Protokollevidenz, die authentisiert, auf Konsistenz geprüft und auf ihre Sicherheitswirkung untersucht werden muss.

RFC 10026 empfiehlt deshalb, automatisierte DS-Wartung nicht allein wegen einer Registrar-Sperre wie clientUpdateProhibited auszusetzen. Führt die Registry die Automatisierung selbst aus, darf auch eine Registry-Sperre wie serverUpdateProhibited nicht alleiniger Aussetzungsgrund sein. Das gilt für die erstmalige DS-Einrichtung ebenso wie für spätere Rollovers.

Die Aussage lautet nicht „Sperren ignorieren“. Ein gewöhnlicher EPP-Status darf einen separaten authentisierten Wartungsweg nicht blockieren, den sein eigenes Akteursmodell gar nicht verbietet. Ein proprietäres Out-of-Band-Lock kann einen größeren Bereich besitzen, mehrere Freigaben oder eine besondere Zeremonie verlangen. Dann müssen Reichweite, Notfallausnahmen und Übersteuerungsrechte dieses Produkts einzeln dokumentiert sein.

Ein offener Wartungsweg ist noch keine Freigabe

Dass ein Weg verfügbar bleibt, bedeutet nicht, dass jeder eintreffende CDS- oder CDNSKEY-Satz akzeptiert wird. RFC 10026 stellt Annahmeprüfungen vor jede Parent-Änderung.

Der Parent-Agent muss eine eindeutige Absicht erkennen. Wenn CDS und CDNSKEY vorhanden sind, müssen sie dieselben Schlüssel bezeichnen. Der relevante Zustand muss über alle autoritativen Nameserver der Delegation plausibel konsistent sein. Danach wird der vorgeschlagene DS-Satz vorausberechnet und geprüft, ob mindestens ein gültiger DNSSEC-Pfad bestehen bleibt. Scheitert die Eindeutigkeit oder die fortgesetzte Validierung, wird das Update abgebrochen.

Damit werden fünf Aussagen getrennt: Die Sperre hat einen definierten Bereich; das Kind hat einen Wunsch veröffentlicht; der Wunsch ist authentisch und konsistent; der vorgeschlagene Parent-Zustand bleibt validierbar; der Parent hat das angenommene Ergebnis tatsächlich veröffentlicht.

Keine dieser Aussagen leiht sich ihren Nachweis von einer anderen. Eine Sperre authentisiert kein CDS. Ein authentisches CDS beweist keine Übereinstimmung aller autoritativen Server. Übereinstimmung belegt keine fortgesetzte Validierung. Eine bestandene Prüfung belegt keine Veröffentlichung. Und eine Veröffentlichung bedeutet nicht, dass jeder Resolver den vorherigen DS bereits aus seinem Cache entfernt hat.

Auch zwei nahe Fragen bleiben auseinander: Die Prüfung aller autoritativen Server fragt, ob der Kind-Dienst einen kohärenten Wunsch ausdrückt. Die Sperranalyse fragt, welchen administrativen Akteur und welchen Befehl ein Registrierungsstatus einschränkt. Die Belegketten ergänzen sich, ersetzen einander aber nicht.

Die Sperre des Registrars schützt nicht vor dem Registrar

Der unbequemste Teil der RFC-Begründung ist zugleich der ehrlichste. Eine Client-Updatesperre eignet sich nicht als ausreichender Schutz gegen einen illegitim handelnden Registrar oder eine kompromittierte Registry. Der Registrar kann den eigenen Status entfernen; die Registry kontrolliert den Server. Wer einen dieser privilegierten Akteure beherrscht, wird nicht dadurch aufgehalten, dass kurz zuvor ein Schlosssymbol sichtbar war.

Die Sperre bleibt innerhalb ihres Bedrohungsmodells wertvoll. Sie weist gewöhnliche Updates zurück und kann Fehler, Kontoübernahmen auf Kundenseite und unerwünschte Softwareaktionen begrenzen. Falsch wird nur die Ausweitung zu einer Garantie, dass keine privilegierte Organisation handeln könne.

Bei einem Vorfall ist der Screenshot Darstellungsbeleg, der serverseitige Readback Kontrollzustand, und erst die Kombination aus ausführendem Akteur, Autorisierung, Annahmeprüfungen und Parent-Differenz beschreibt den Änderungsweg. Der Gegensatz zwischen sichtbarer Sperre und neuem DS beweist für sich weder Angriff noch rechtmäßige Wartung.

Ein stärkeres Registry-Lock kann die Lage materiell verändern, etwa durch separate Berechtigungsnachweise, Zwei-Personen-Freigabe, Telefonprüfung oder Verzögerung. Entscheidend sind dann die wirklichen Freigabe-, Überschreibungs- und Notfallregeln. Update-, Transfer- und Löschsperren sowie proprietäre Registry-Lock-Dienste dürfen nicht wegen ähnlicher Namen gleichgesetzt werden.

Auch eine korrekte Änderung braucht Zeugen

Im Verhältnis zwischen Registrant, Registrar und Registry kann registryseitige Automatisierung DS-Daten rechtmäßig ändern, ohne dass der Registrar einen gewöhnlichen Update-Befehl gesendet hat. Das stärkt die Kontinuität, erzeugt aber ein Sichtbarkeitsproblem: Der Registrar hat nichts angefordert, während der Registrant weiterhin die Sperre sieht.

RFC 10026 trennt deshalb Befugnis und Benachrichtigung. Automatisiert eine Registry die DS-Wartung, sollte sie den Registrar über die EPP-Change-Poll-Erweiterung aus RFC 8590 oder einen vergleichbaren Kanal informieren. Wesentliche Updates und Deaktivierungen gehören an die relevanten Kontakte. Registrant oder benannte Partei sollten die aktive DS-Konfiguration im Portal prüfen können.

Der Parent-Agent sollte außerdem ein strukturiertes Entscheidungsprotokoll führen: Zeitpunkt, auslösende CDS/CDNSKEY-Daten, Benachrichtigungskanal, befragte autoritative Nameserver, Prüfergebnisse, Entscheidung sowie angewendeter DS-Satz oder Abbruchgrund.

Dieses Journal verwandelt den Satz „die gesperrte Domain änderte sich korrekt“ in eine überprüfbare Abfolge. Die Sperre blieb auf ihrem vorgesehenen Weg wirksam; ein separates authentisiertes Signal erreichte einen anderen Weg; Sicherheitsprüfungen bestanden; der zuständige Parent-Akteur veröffentlichte; der Registrar wurde benachrichtigt; der öffentliche Zustand änderte sich entsprechend.

Fehlt ein Glied, wird die Schlussfolgerung enger. Eine fehlende Nachricht belegt zunächst ein Reporting-Problem, nicht automatisch einen unautorisierten DS. Ein geänderter DS belegt Parent-Veröffentlichung, nicht Authentizität des Wunsches. Ein Portalsymbol belegt Benutzeroberfläche, nicht Serverentscheidung.

Wiederherstellung darf nicht denselben verlorenen Schlüssel verlangen

Automatisierung kann nicht die einzige Tür sein. Das Kind kann den Signaturschlüssel verlieren, mit dem ein Rollover authentisiert würde. Ein Anbieter in einem Mehrbetreiber-Setup kann die Zusammenarbeit verweigern. Ein DNS-Betreiber kann CDS/CDNSKEY überhaupt nicht unterstützen.

RFC 10026 verlangt für solche Fälle einen anderen DS-Wartungskanal bei Registry und Registrar. Er darf manuell sein, muss aber Kontrolle wiederherstellen, wenn In-Band-Evidenz nicht mehr erzeugt werden kann. Ein Protokoll, das den aktuellen Schlüssel zur Bestätigung des Übergangs nutzt, kann diesen Nachweis nach Verlust desselben Schlüssels nicht durch Wiederholung herbeizaubern.

Auch die manuelle Wiederherstellung braucht einen Beleg: organisatorische Vertretung, Out-of-Band-Prüfungen, gewünschter DS-Zustand, etwaige Automatisierungspause, Wiederaufnahmebedingung und abschließender Parent-Readback. Sonst wird „manuelle Ausnahme“ nur ein weiterer unbestimmter Machtbegriff.

Shengs Autorschaft belegt Beitrag, nicht Betriebsgewalt

Der RFC Editor führt Steve Sheng und Peter Thomassen als Autoren von RFC 10026. Shengs Profil im IETF Datatracker nennt außerdem RFC 7485 und RFC 7710. Das offizielle ICANN75-Archiv bezeichnete ihn 2022 als Senior Director, Policy Development Support; seine aktuelle öffentliche Biografie berichtet, dass er 2024 fünfzehn Jahre technikpolitischer Forschung bei ICANN abschloss und an der Carnegie Mellon University in Engineering and Public Policy promoviert wurde.

Diese Fakten verorten einen dokumentierten Beitrag an der Schnittstelle von Protokollen und Institutionen. Sie zeigen nicht, dass Sheng eine Registry, einen Registrar, eine Parent-Zone oder eine Implementierung kontrolliert. Ein IETF-Konsensdokument ist kein persönlicher Befehl; Autorschaft beweist keine flächendeckende Umsetzung.

Die Grenze der Autorschaft ähnelt der Sperrgrenze. Ein Name ordnet einen Beitrag zu, ohne Betriebsbefugnis zu übertragen. Ein Status ordnet eine Einschränkung zu, ohne alle Akteure des Systems zu binden. Eine präzise Personenbeschreibung wahrt beides.

Entscheidend ist ein akteursbezogener Entscheidungsbeleg

Eine rekonstruierbare DS-Änderung beginnt mit öffentlichem und serverseitigem Sperrstatus, Setzer und Zeit. Sie ergänzt ausführenden Akteur und Weg, CDS/CDNSKEY-Material, Authentisierung, Konsistenz aller Autoritativen, Projektion fortgesetzter Validierung, lokale Annahmerichtlinie und Entscheidung.

Darauf folgen Veröffentlichungszeit, endgültiger Parent-DS, relevante TTL, Nachrichten an Registrar und Registrant, resolverseitige Kontrolle und unabhängiger Wiederherstellungskanal. Geheimnisse und unnötige personenbezogene Daten gehören nicht hinein; die zur Erklärung von Befugnis und Ergebnis nötigen Belege schon.

Das ist Primat des laufenden Systems, angewandt auf ein beruhigendes Symbol. Die gemeinsame Mindestspezifikation lautet: Eine gewöhnliche Registrierungsperre darf authentisierte DNSSEC-Kontinuität nicht versehentlich zerstören, und Automatisierung darf Wiederherstellung nicht beseitigen. Lokale Betreiber dürfen stärkere Sperren, zusätzliche Prüfungen und andere Melderegeln wählen, müssen aber deren jeweiligen Wirkungsweg benennen.

Die dauerhafte Regel ist enger und nützlicher als „gesperrt heißt sicher“: Eine Sperre ist nur innerhalb ihrer dokumentierten Akteurs- und Befehlsgrenze ein Beleg. Jenseits dieser Grenze braucht jede Sicherheitsbehauptung einen eigenen Nachweis.

Quellen