Registry-Lock: Domain-Hijacking beim Registrar stoppen

Das Konto ist das Ziel, nicht der Nameserver

Die ICANN-Sicherheitskommission SSAC hat für ihren Bericht SAC040 eine Serie von Vorfällen zwischen Mai 2008 und April 2009 ausgewertet und nach einem gemeinsamen Muster gesucht (ICANN SSAC, SAC040, 19.08.2009). Das Ergebnis ist unbequem, weil es so wenig mit Technik zu tun hat. Der Bericht hält für einen Teil der untersuchten Registrare wörtlich fest: Alles, was ein Angreifer braucht, um die Kontrolle über das gesamte Domain-Portfolio einer Organisation zu erlangen, ist ein Benutzerkonto und ein Passwort. Und weiter: Angreifer müssen lediglich einen einzigen Ansprechpartner erraten, phishen oder per Social Engineering bearbeiten, um Kontrolle über ein Registrierungskonto zu erlangen (ICANN SSAC, SAC040).

Der Folgebericht SAC044 beschreibt, was danach passiert (ICANN SSAC, SAC044, 05.11.2010). Der Angreifer verändert die DNS-Konfiguration des Domainnamens, sodass die Namensauflösung Besucher auf eine Nachahmerseite, eine Phishing-Seite, eine defaced Seite oder auf Schadcode leitet. Ebenso kann er die DNS-Konfiguration ändern, um Mail- oder Webverkehr über eigene Hosts zu leiten und dort Zugangsdaten mitzuschneiden. Genau darin liegt der Unterschied zu einem gewöhnlichen Website-Einbruch: Wer die Delegation kontrolliert, braucht Ihren Server gar nicht.

• Nameserver und Zone: Die Domain löst auf fremde Adressen auf. Die Website ist technisch unversehrt und trotzdem nicht mehr die Website, die Besucher sehen.
• MX und Mailzustellung: Eingehende Mail landet beim Angreifer. Damit landen auch Passwort-Reset-Mails aller Dienste dort, die an Ihre Domain gebunden sind.
• Zertifikatsausstellung: Wer DNS kontrolliert, besteht die DNS-basierte Domain-Validierung und kann gültige Zertifikate auf Ihren Namen ausstellen lassen.
• Wiederherstellung: Die Rückholung läuft über Registrar und Registry - nicht über einen Restore aus Ihrem Backup.

EPP-Statuscodes: die Sperrmechanik unter dem DNS

Zwischen Registrar und Registry spricht ein eigenes Protokoll: das Extensible Provisioning Protocol, standardisiert als RFC 5730 und seit August 2009 als Internet-Standard STD 69 geführt (IETF, RFC 5730). Die Abbildung auf Domainnamen regelt RFC 5731 aus demselben Monat (IETF, RFC 5731). Die Rollenverteilung ist dabei fest verdrahtet: Der Registrar ist der Client, die Registry ist der Server. Diese Zweiteilung erklärt die gesamte Namenslogik der Statuscodes.

Statuswerte, die von einem Client hinzugefügt oder entfernt werden können, tragen das Präfix „client“. Die entsprechenden Statuswerte, die von einem Server hinzugefügt oder entfernt werden können, tragen das Präfix „server“.

— IETF, RFC 5731, Abschnitt 2.3 (Status Values), sinngemäß übersetzt

ICANN dokumentiert die 17 standardisierten EPP-Domain-Statuscodes zuzüglich der Gnadenfristen aus RFC 3915 in einer eigenen Übersicht und benennt die Hierarchie unmissverständlich: Client-Statuscodes werden von Registraren gesetzt, Server-Statuscodes von Registries - und die Server-Codes haben Vorrang vor den Client-Codes (ICANN, EPP Status Codes: What Do They Mean, and Why Should I Know?). Genau dieser Vorrang ist der ganze Punkt des Registry-Locks.

Ein Detail aus RFC 5731 lohnt sich zu merken, weil es beim Lesen von Statusabfragen hilft: Der Status ok darf mit keinem anderen Status kombiniert werden (IETF, RFC 5731). Eine Domain, die ok meldet, trägt also keinerlei Sperre. In der modernen RDAP-Auskunft erscheint dieser Wert als active - dazu später mehr.

Registrar-Sperre: kostenlos, sofort - und genau deshalb begrenzt

clientTransferProhibited ist der Status, den die meisten Registrare bei der Registrierung automatisch setzen. ICANN beschreibt seine Wirkung nüchtern: Er weist die Registry an, Anfragen zur Übertragung der Domain an einen anderen Registrar abzulehnen (ICANN, EPP Status Codes). Das ist sinnvoll und sollte gesetzt sein. Es ist nur eben nicht das, wofür viele es halten.

Der Grund steht in der ICANN Transfer Policy, dem verbindlichen Regelwerk für Registrarwechsel bei generischen Top-Level-Domains (ICANN, Transfer Policy, aktualisiert am 21.02.2024, verpflichtend umzusetzen bis 21.08.2025). Abschnitt I.A.5.1 verpflichtet den Registrar, den Status ClientTransferProhibited innerhalb von fünf Kalendertagen nach der ersten Anfrage des Inhabers zu entfernen, sofern er keine Selbstbedienungsfunktion dafür anbietet (ICANN, Transfer Policy). Abschnitt I.A.5.2 verlangt dasselbe für die Herausgabe des AuthInfo-Codes.

Entscheidend ist aber Abschnitt I.A.5.3. Er verbietet Registraren ausdrücklich, für das Entfernen von ClientTransferProhibited oder die Herausgabe des AuthInfo-Codes einen Mechanismus zu verwenden, der restriktiver ist als die Mechanismen, mit denen der Inhaber irgendeinen Aspekt seiner Kontakt- oder Nameserver-Daten ändert (ICANN, Transfer Policy, Abschnitt I.A.5.3).

Das ist kein Argument gegen die Registrar-Sperre. Sie kostet nichts, ist in Minuten gesetzt und fängt einen realen Angriffsweg ab. SAC044 empfiehlt ausdrücklich, sowohl clientTransferProhibited als auch clientUpdateProhibited zu setzen, und weist auf einen unterschätzten Nebeneffekt hin: Viele Registrare versenden Benachrichtigungen, wenn Client-Statuscodes verändert werden. Diese Benachrichtigungen seien außerordentlich wichtig, weil sie Inhaber vor unautorisiertem Kontozugriff vorwarnen können (ICANN SSAC, SAC044). Eine Sperre, deren Aufhebung eine Mail auslöst, ist auch dann nützlich, wenn sie den Angreifer nicht aufhält - sie macht ihn sichtbar.

Registry-Lock: die Sperre, die Ihr eigenes Konto nicht aufheben kann

Die Server-Statuscodes liegen eine Ebene tiefer. Sie werden von der Registry gesetzt, nicht vom Registrar, und Ihr Kundenkonto hat auf sie keinen Zugriff. ICANN beschreibt das Angebot so: Manche Registry-Betreiber bieten einen Registry-Lock-Dienst an, der es Inhabern über ihre Registrare erlaubt, diesen Status als zusätzlichen Schutz gegen unautorisierte Änderungen zu setzen. Das Entfernen dieses Status könne länger dauern als bei clientUpdateProhibited, weil der Registrar die Anfrage an die Registry weiterreichen und deren Aufhebung abwarten müsse (ICANN, EPP Status Codes).

SAC044 beschreibt den Ablauf präziser: Registrare reichen die Sperranträge für serverDeleteProhibited, serverUpdateProhibited und serverTransferProhibited auf Wunsch des Inhabers ein. Die Registry prüft vor dem Setzen, dass der antragstellende Registrar auch der eingetragene Registrar ist. Sind die Sperren aktiv, nutzt die Registry ein besonders abgesichertes Verifikations- und Authentifizierungsverfahren, um sicherzustellen, dass Änderungsanfragen tatsächlich vom Inhaber autorisiert wurden (ICANN SSAC, SAC044). Das ist der Punkt, an dem die Verifikation den Kanal verlässt, den ein Angreifer kontrolliert.

Der Preis dafür ist Reibung, und zwar in beide Richtungen. Eine Nameserver-Migration dauert danach Tage statt Minuten, weil jede Änderung durch das Verifikationsverfahren muss. Wer ACME-Zertifikate über die DNS-01-Prüfung ausstellt, sollte prüfen, ob die dafür nötigen TXT-Einträge in einer delegierten Zone liegen, die von der Sperre nicht berührt wird - sonst blockiert der Lock die eigene Automatisierung. Diese Reibung ist beabsichtigt: Sie ist genau das, was den Angreifer aufhält. Sie muss nur geplant sein.

Was die Praxis zeigt: eine RDAP-Stichprobe

Die Theorie ist eindeutig. Interessanter ist, was tatsächlich gesetzt ist. Für diesen Beitrag haben wir am 15.07.2026 die Domain-Status von 63 .com- und .net-Domains großer, überwiegend im DAX gelisteter deutscher Unternehmen direkt über die offiziellen RDAP-Dienste der zuständigen Registries abgefragt - dazu sieben .de-Domains derselben Unternehmensgruppe (Eigene RDAP-Erhebung, 15.07.2026). Das Ergebnis lässt sich in vier Zahlen zusammenfassen.

1. 90,5 % der 63 Domains (57) tragen clientTransferProhibited - die Registrar-Sperre gegen Transfers ist praktisch Standard (Eigene RDAP-Erhebung, 15.07.2026).
2. 33,3 % (21) tragen mindestens einen server*-Status, haben also einen Registry-Lock aktiv (Eigene RDAP-Erhebung, 15.07.2026).
3. 9,5 % (6) tragen clientUpdateProhibited - die Sperre, die eine Nameserver-Änderung im Konto blockieren würde (Eigene RDAP-Erhebung, 15.07.2026).
4. 3,2 % (2) melden ausschließlich active, tragen also überhaupt keine Sperre (Eigene RDAP-Erhebung, 15.07.2026).

Die aussagekräftige Zahl ist nicht die 33,3 %. Es ist der Abstand zwischen 90,5 % und 9,5 %. Die Transfersperre ist gesetzt, weil Registrare sie voreingestellt mitliefern - sie kostet den Inhaber keine Entscheidung. Die Update-Sperre, die den Nameserver-Eintrag schützt und damit exakt den Weg abschneidet, den die SSAC-Vorfallanalysen als Regelfall beschreiben, ist bei neun von zehn dieser Unternehmen nicht gesetzt. Sie erfordert nämlich eine Entscheidung: Sie macht den Alltag ein wenig unbequemer.

Die verbreitete Sperre schützt vor dem Szenario, das selten vorkommt. Die seltene Sperre schützt vor dem Szenario, das die Vorfallberichte beschreiben.

— Auswertung der eigenen RDAP-Erhebung vom 15.07.2026

Die zweite Beobachtung: 42 der 63 Domains, also 66,7 %, haben keinen Registry-Lock (Eigene RDAP-Erhebung, 15.07.2026). Die Verteilung ist dabei nicht zufällig - der Lock findet sich überwiegend bei den größten Konzernen der Stichprobe, während er im MDAX- und SDAX-Bereich weitgehend fehlt. Das deckt sich mit der Erfahrung aus Projekten: Registry-Lock ist selten eine Frage des Budgets und fast immer eine Frage dessen, ob jemand die Domain je als eigenständiges Asset inventarisiert hat (Projekterfahrung).

Registrar-Konto härten: getrennte Rolle, MFA, eigene Kontaktadresse

Wenn das Konto das Ziel ist, ist das Konto der Ort, an dem die Arbeit anfängt. SAC044 listet Maßnahmen, die 2010 formuliert wurden und deren Aktualität eher unangenehm ist (ICANN SSAC, SAC044). Die wichtigsten in der Reihenfolge ihrer Wirkung:

• Sensible Domains partitionieren: SAC044 empfiehlt, besonders wichtige Registrierungen in ein eigenes Konto zu legen, dessen Zugangsdaten bei ausgewähltem Personal liegen (ICANN SSAC, SAC044). Die Marketing-Domain und die Domain, an der die Gehaltsabrechnung hängt, gehören nicht in denselben Zugang.
• Mehrfaktor-Authentifizierung aktivieren, wo der Registrar sie anbietet - SAC040 beschreibt sie als das „etwas, das man hat“ zusätzlich zum Passwort und hält fest, dass sie einen Kontoeinbruch deutlich erschwert (ICANN SSAC, SAC040).
• Eigene Zugangsdaten je Konto und keine Wiederverwendung über Systemgrenzen hinweg (ICANN SSAC, SAC044).
• Personalwechsel als Auslöser behandeln: Ändern sich die autorisierten Kontakte, sollten neue Zugangsdaten erzeugt und alte entzogen werden (ICANN SSAC, SAC044).
• Benachrichtigungen einem Verantwortlichen zuordnen oder ein Ticket erzeugen lassen, damit keine Meldung ungelesen bleibt - SAC044 verlangt dafür sogar ein definiertes Reaktionsziel je Ereignistyp (ICANN SSAC, SAC044).
• Wiederherstellungsprozess definieren und auditieren, inklusive der Frage, wer im Ernstfall überhaupt befugt ist, hinterlegte Zugangsdaten zu ziehen (ICANN SSAC, SAC044).

SAC040 ergänzt einen strukturellen Gedanken, der über das einzelne Konto hinausgeht. Der Bericht vergleicht das übliche Zugriffsmodell mit einem Schranktresor: Ist er einmal offen, kann man darin tun, was man will. Dem stellt er das Modell eines Banktresors mit Schließfächern gegenüber, bei dem ein Eindringling nicht nur in den Raum, sondern zusätzlich an jedes einzelne Fach muss. Registrare werden ermutigt, ein solches Modell anzubieten - etwa als Wahlfunktion, die steuert, welche Kontakte Kontakt- und DNS-Daten ändern oder einen Transfer anstoßen dürfen (ICANN SSAC, SAC040). Genau diese Granularität leistet ein Registry-Lock, wenn der Registrar sie nicht anbietet: Er zieht die Berechtigung für die kritischsten Operationen aus dem Konto heraus.

Wer diese Fragen für externe Dienstleister systematisch beantworten muss, findet die passende Nachweislogik im Beitrag zur nachweisbaren Absicherung von Dienstleistern in der NIS2-Lieferkette - der Registrar ist aus Sicht der Richtlinie ein Dienstleister wie jeder andere.

Auth-Code-Hygiene und die Sperrfristen der Transfer Policy

Der AuthInfo-Code ist der Schlüssel zum Transfer. Die Transfer Policy nennt ihn weiterhin so, auch wenn der Abschlussbericht der Transfer-Policy-Überprüfung eine Umbenennung in „Transfer Authorization Code“ vorgeschlagen hat (ICANN, Transfer Policy). Praktisch ist er ein Passwort und sollte auch so behandelt werden.

• Erst bei Bedarf erzeugen. Ein Code, der seit drei Jahren im Kundenkonto steht, ist ein Passwort ohne Rotation.
• Nach jedem abgebrochenen Transfer neu erzeugen. Der herausgegebene Code ist ab dem Moment der Weitergabe kompromittiert - unabhängig davon, ob der Transfer stattfand.
• Nicht in Tickets, Wikis oder Mailarchiven ablegen. Genau dort suchen Angreifer nach einer Kontoübernahme zuerst.
• Bei .de gilt eine harte Frist: Der AuthInfo verfällt nach 30 Tagen automatisch und muss dann neu angefordert werden (DENIC, Providerwechsel).

Die Transfer Policy kennt zusätzlich mehrere Sperrfristen, die als Bremse wirken. Ein Transfer kann abgelehnt werden, wenn er innerhalb von 60 Tagen nach dem Erstellungsdatum der Domain beantragt wird, und ebenso innerhalb von 60 Tagen nach einem vorangegangenen Transfer (ICANN, Transfer Policy, Abschnitte 3.7.5 und 3.7.6). Nach einem Inhaberwechsel greift eine 60-tägige Transfersperre; setzt ein Registrar dafür clientTransferProhibited ein, muss er die Domain so sperren, dass der Inhaber die Sperre gerade nicht selbst entfernen kann (ICANN, Transfer Policy, Abschnitt II.C.2). Das ist bemerkenswert, weil es zeigt: Eine nicht vom Inhaber abschaltbare Client-Sperre ist technisch möglich - sie ist im Regelbetrieb nur nicht vorgesehen.

Diese Fristen helfen gegen den Transfer. Gegen die Nameserver-Änderung helfen sie nicht - die ist an keine Wartezeit gebunden und wirkt binnen Minuten. Wer den Unterschied zwischen einer Übernahme auf Registry-Ebene und einer Manipulation der Zone selbst verstehen will, findet die Abgrenzung im Beitrag zum Erkennen und Verhindern von DNS-Hijacking.

.de bei DENIC: eigene Regeln, eigener Registry-Lock

Für die wichtigste Domain vieler deutscher Unternehmen gilt vieles davon nicht - jedenfalls nicht in dieser Form. .de ist keine generische Top-Level-Domain, DENIC unterliegt nicht der ICANN Transfer Policy und betreibt ein eigenes Registrierungssystem. Herzstück ist das Realtime Registry Interface (RRI), nicht EPP (DENIC, Registrierungssystem für .de im Überblick). Entsprechend gibt es ein eigenes Statusvokabular: free, connect, failed, invalid und redemptionPeriod (DENIC, Domain-Status). clientTransferProhibited und Verwandte kommen darin nicht vor.

Das ist im öffentlichen RDAP unmittelbar sichtbar. Alle sieben in unserer Stichprobe geprüften .de-Domains lieferten als Status ausschließlich active - unabhängig davon, welche Schutzmaßnahmen tatsächlich hinterlegt sind (Eigene RDAP-Erhebung, 15.07.2026). Wer bei einer .de-Domain von außen prüfen will, ob eine Sperre aktiv ist, kann das nicht.

Einen Registry-Lock gibt es trotzdem, und er ist bemerkenswert konsequent gebaut. DENIC bietet den .de Registry Lock als kostenpflichtiges Produkt an, das Mitglieder ihren Domaininhabern vermitteln; er schützt Inhaberdaten, Nameserver und Providereinstellungen gegen unerwünschte Manipulation - sowohl durch Angriffe von außen als auch durch versehentliche Fehlkonfiguration (DENIC, .de Registry Lock).

Ein Detail unterstreicht, wie ernst DENIC das Verfahren nimmt: Änderungsaufträge für gesperrte Domains werden nicht über die reguläre Schnittstelle eingereicht, sondern per E-Mail beziehungsweise im Key-Value-Format direkt an DENIC gesandt und dort manuell bearbeitet (DENIC, .de Registry Lock). Der Sperrzustand selbst ist über eine Domain-INFO-Abfrage als RegistryLock: true erkennbar - allerdings über die Provider-Schnittstelle, nicht im öffentlichen RDAP (DENIC, .de Registry Lock).

Zur Einordnung der Größenordnung: Zum 30.06.2026 waren 17.998.588 .de-Domains registriert (DENIC, .de-Domainstatistik). DNSSEC-signiert waren davon 437.728 - rund 2,4 % (DENIC, DNSSEC-Statistik für .de, Stand 30.06.2026). Diese Quote sagt viel über die Verbreitung von Domain-Härtung insgesamt: Die Schutzschichten existieren seit Jahren und sind dokumentiert, sie werden nur kaum genutzt. Warum die Signatur allein nicht genügt und was ihre Validierung überwachen muss, ist ein eigenes Thema.

RDAP-Status als Frühindikator

Die Auskunft über Registrierungsdaten hat 2025 den Anbieter gewechselt - genauer: das Protokoll. ICANN hat zum 28. Januar 2025 RDAP zur maßgeblichen Quelle für Registrierungsinformationen generischer Top-Level-Domains erklärt und WHOIS abgekündigt (ICANN, ICANN Update: Launching RDAP; Sunsetting WHOIS, 27.01.2025). Registries und Registrare müssen RDAP nach dem gTLD-RDAP-Profil bereitstellen, WHOIS seit diesem Datum jedoch nicht mehr - ausgenommen .com, .name und .post (ICANN, Registration Data Access Protocol). Der Umfang ist beachtlich: Für Dezember 2024 schätzt ICANN das Abfragevolumen über alle RDAP-Server hinweg auf über 10 Milliarden Anfragen pro Monat, bei über 40 bekannten Client- und über 15 bekannten Server-Implementierungen (ICANN, Registration Data Access Protocol).

Technisch steht RDAP auf zwei Dokumenten, beide vom Juni 2021 und beide Teil von STD 95: RFC 9082 definiert das Abfrageformat, RFC 9083 die JSON-Antwortstruktur (IETF, RFC 9082 und RFC 9083). Die Übersetzung zwischen den Welten regelt RFC 8056: Er bildet die EPP-Status auf die RDAP-Status ab und schließt dabei bestehende Lücken im Register (IETF, RFC 8056, Januar 2017). Praktisch heißt das: Aus serverUpdateProhibited wird server update prohibited, aus ok wird active. Wer nach der CamelCase-Schreibweise sucht, findet in einer RDAP-Antwort nichts.

{
  "objectClassName": "domain",
  "ldhName": "EXAMPLE.COM",
  "status": [
    "client transfer prohibited",
    "server delete prohibited",
    "server transfer prohibited",
    "server update prohibited"
  ],
  "nameservers": [
    { "objectClassName": "nameserver", "ldhName": "NS1.EXAMPLE.NET" },
    { "objectClassName": "nameserver", "ldhName": "NS2.EXAMPLE.NET" }
  ],
  "events": [
    { "eventAction": "expiration",  "eventDate": "2028-12-07T17:04:26Z" },
    { "eventAction": "last changed", "eventDate": "2025-01-31T20:19:44Z" }
  ],
  "secureDNS": { "delegationSigned": true }
}

Diese Antwort enthält vier Größen, die sich für eine Überwachung eignen, weil sie sich selten und aus benennbaren Gründen ändern:

• status: Verschwindet server update prohibited aus dem Array, wurde der Registry-Lock aufgehoben. Das ist entweder Ihr eigener Change - oder ein Vorfall.
• nameservers: Der eigentliche Frühindikator. Ein neuer Nameserver-Satz ist die Signatur der Übernahme, lange bevor die Website anders aussieht.
• events: expiration schützt vor dem stillen Ablauf, last changed und transfer datieren jede Veränderung am Registry-Objekt.
• secureDNS: Fällt delegationSigned auf false, wurde die DNSSEC-Kette gekappt - ein typischer Vorbereitungsschritt, um eine Umleitung unauffällig zu halten.

Grenzen ehrlich benennen

Registry-Lock ist eine wirksame Maßnahme, aber kein Allheilmittel. Vier Einschränkungen gehören in jede Entscheidungsvorlage:

1. Nicht jede Registry und nicht jeder Registrar bietet ihn an. ICANN beschreibt Registry-Lock ausdrücklich als Angebot „mancher“ Registry-Betreiber, nicht als Pflicht (ICANN, EPP Status Codes). Ob Ihre Kombination aus TLD und Registrar ihn unterstützt, ist eine Einzelfallfrage.
2. Er schützt das Registry-Objekt, nicht Ihre Zone. Bleiben die Nameserver-Einträge bei der Registry korrekt, während das Konto Ihres DNS-Hosters übernommen wird, ändert sich der Zoneninhalt trotzdem. Registry-Lock greift dort nicht - das ist ein anderer Angriff mit einer anderen Gegenmaßnahme.
3. Er verlängert keine Domain. Der Ablauf bleibt ein eigenständiges Risiko, das an Zahlungswegen und Erinnerungen hängt und nicht am Statuscode. Warum daran regelmäßig Unternehmen scheitern, beschreibt der Beitrag zum Verhindern des Domain-Ablaufs.
4. Die Erkennung hat Latenz. RDAP-Antworten tragen ein eigenes Feld für den Stand der Datenbank; zwischen der Änderung und ihrer Sichtbarkeit liegen typischerweise Minuten bis Stunden, nicht Sekunden. Ein Frühindikator ist kein Echtzeitschutz.

Und eine Einordnung, die zur Ehrlichkeit gehört: Registry-Lock verhindert keine Schwachstelle in Ihrer Anwendung, keine kompromittierte Abhängigkeit und keinen unsicheren Server. Er adressiert genau eine Angriffsklasse. Wer die Lage über die Domain hinaus systematisch bewerten will, arbeitet mit den öffentlichen Schwachstellen-Feeds EUVD und CVE und einem regelmäßigen Security-Scan der eigenen Angriffsfläche.

Domain-Status zu einer überwachten Größe machen

Die Domain ist in fast jedem Unternehmen das Asset mit dem schlechtesten Verhältnis von Bedeutung zu Aufmerksamkeit. Sie trägt die Website, die Mail und die Vertrauensbeziehung zu jedem Kunden - und sie wird typischerweise in einem Konto verwaltet, dessen Zugangsdaten niemand mehr genau zuordnen kann. Die Schutzschicht darunter ist seit über fünfzehn Jahren dokumentiert: EPP-Statuscodes seit RFC 5730 aus dem Jahr 2009, die Empfehlung zum Registry-Lock seit SAC044 aus dem Jahr 2010. Neu ist daran nichts. Nur die Umsetzung fehlt bei zwei Dritteln der von uns geprüften Domains (Eigene RDAP-Erhebung, 15.07.2026).

Die Reihenfolge ist überschaubar: Zuerst das Konto härten - getrennte Rolle, Mehrfaktor-Authentifizierung, eine Kontaktadresse außerhalb der eigenen Domain. Dann die kostenlosen Client-Sperren setzen, clientTransferProhibited und clientUpdateProhibited, und deren Benachrichtigungen einem Verantwortlichen zuweisen. Dann für die zwei bis drei Domains, deren Ausfall den Betrieb stoppt, den Registry-Lock beim Registrar beantragen. Und schließlich das, was die ersten drei Schritte erst überprüfbar macht: den Status regelmäßig lesen.

Genau dort setzt das DNS- und Domain-Monitoring von XICTRAQ an. Es überwacht die Nameserver-Einträge, den Domain-Status und den Ablauftermin Ihrer Domains, vergleicht jeden Abruf mit dem zuletzt bekannten Stand und schlägt bei nicht autorisierten Änderungen Alarm - über die Benachrichtigungskanäle, die Ihr Team ohnehin nutzt. Der Schutz vor der Übernahme bleibt beim Registrar und bei der Registry. Die Frage, ob er noch aktiv ist, lässt sich überwachen.

Der Einstieg braucht keine große Initiative. Tragen Sie die Domains ein, deren Ausfall wehtut, prüfen Sie einmalig deren Statuscodes gegen die Tabelle weiter oben, und lassen Sie den Rest laufen. Ergänzend lohnt der Blick auf die Überwachung von Marken- und Schreibvarianten sowie auf die Erreichbarkeitsüberwachung, die den Ausfall meldet, falls doch etwas an der Delegation kippt. Welche Module in welchem Umfang enthalten sind, zeigt die Preisübersicht; ein kostenloses Konto genügt, um die erste Domain aufzunehmen.