Registrar-Sperre oder Schichtenverteidigung: Was wann hilft

Stellen Sie sich vor, Sie wachen auf und stellen fest, dass Ihr Domain-Registrar über Nacht jede Domain Ihres Unternehmens gesperrt hat: Produktion, Staging und die Domain mit Ihren MX-Records. Kein Deployment ist schiefgegangen, kein Server abgestürzt. Irgendjemand aus einem Trust-and-Safety-Team (oder, wahrscheinlicher, eine automatisierte Missbrauchs-Pipeline) hat einen Schalter umgelegt, und Ihre gesamte Internetpräsenz ist weg. Das ist kein Hirngespinst: Es passiert regelmäßig genug, dass in Sysadmin-Foren ständig Horrorgeschichten auftauchen, in denen Registrare Konten wegen ungeprüfter Missbrauchsmeldungen, mehrdeutiger Tweets oder eines einzigen markierten Bildes unter Millionen Nutzer-Uploads deaktiviert haben.

Ich verbringe seit Jahren Zeit mit Incident Response für Infrastruktur-Teams, und das Muster ist immer dasselbe. Ingenieure bauen aufwendige Redundanz für Compute auf (Multi-AZ, Multi-Region, Failover-Runbooks) und lassen dann das eine Asset ungeschützt, das sich nicht neu deployen lässt: den Domainnamen selbst. Der liegt in einem einzigen Konto, geschützt durch ein Passwort und vielleicht einen SMS-Code. Dieser Artikel vergleicht zwei Philosophien für den Umgang mit diesem Risiko: den klassischen Ansatz der Registrar-Sperre (einen soliden Registrar wählen, das Konto absichern und ihm vertrauen) und den Ansatz der Schichtenverteidigung (davon ausgehen, dass der Registrar einen im Stich lässt, und die Architektur darauf auslegen). Die Pointe: Sie brauchen beides, aber der zweite Ansatz ist derjenige, der Sie um 3 Uhr nachts tatsächlich rettet.

Warum Ihr Registrar eine andere Art von Single Point of Failure ist

Die meisten Single Points of Failure in Ihrem Stack liegen in Ihrer Kontrolle. Eine Datenbank-Primary, ein NAT-Gateway, ein Message Broker: Sie können sie replizieren, und den Failover-Plan haben Sie selbst geschrieben. Ihr Registrar ist aus drei Gründen anders. Erstens ist er eine Abhängigkeit der Control-Plane, die Sie nicht replizieren können. Sie können nicht zwei Registrare für dieselbe Domain betreiben, die Registry hat genau einen zuständigen Sponsor. Zweitens verlaufen Registrar-Ausfälle langsam. Ein Domain-Transfer dauert unter normalen Umständen fünf bis sieben Tage, und wenn der aktuelle Registrar Ihr Konto gesperrt hat, bekommen Sie womöglich nicht einmal den Auth-Code, um überhaupt zu starten. Drittens ist der Fehler auf eine seltsame Weise feindselig: Es ist kein Angreifer, sondern der Anbieter selbst, der aufgrund einer Missbrauchsmeldung gegen Sie vorgeht, die Sie nie zu sehen bekamen.

Der Explosionsradius ist außerdem schlimmer, als die meisten annehmen. Wenn ein Registrar eine Domain suspendiert, zeigt er die NS-Records typischerweise auf eine Takedown-Seite oder beantwortet einfach keine Anfragen mehr. Das killt natürlich Ihre Website. Aber es killt auch Ihre E-Mails (MX-Records liegen im DNS), Ihr SSO, falls Callbacks auf Ihre Domain verweisen, Ihre API-Clients, Ihre Status-Seite, falls sie auf derselben Domain liegt, und, mein persönlicher Favorit, die E-Mail-Adresse, an die die Wiederherstellungsanweisungen gehen sollen. Wenn die Registrar-Kontoadresse admin@ihredomain.de lautet und ihredomain.de gesperrt ist, versuchen Sie nun, sich gegenüber dem Support von einer Adresse auszuweisen, der dieser nicht mehr vertraut. Ich habe genau diese Schleife schon einen ganzen Incident-Tag lang fressen sehen.

Und die wirtschaftlichen Anreize arbeiten gegen Sie. Wenn ein Registrar von Private Equity übernommen wird, wie es bei mehreren großen bereits passiert ist, folgt das Vorgehen einem vorhersehbaren Muster: Human Support wird gestrichen, Missbrauchsfälle werden automatisiert, die Preise steigen. Automatisierte Missbrauchssysteme optimieren auf ihr Risiko, nicht auf Ihres. Eine Domain zu sperren, die sich später als unschuldig herausstellt, kostet den Anbieter nichts. Eine Domain online zu lassen, die sich später als schuldig herausstellt, kostet ihn Ärger mit der Registry und schlechte Presse. Raten Sie mal, in welche Richtung die Automatisierung im Zweifel irrt.

Ansatz eins: Registrar-Sperre. Den Single Point of Failure härten

Die Sperr-Philosophie lautet: Akzeptieren Sie, dass der Registrar ein Single Point of Failure ist, und machen Sie diesen Punkt so stark wie möglich. Das ist die Strategie, die die meisten Unternehmen tatsächlich fahren, ob sie es ausformuliert haben oder nicht. Richtig umgesetzt sieht sie so aus:

• Wählen Sie den Registrar nach Support-Qualität, nicht nach Preis. Die drei Dollar im Jahr, die Sie pro Domain sparen, sind nichts im Vergleich zu einem einzigen Tag Ausfall. Sie wollen Telefon-Support, bei großen Portfolios einen benannten Account Manager und ein Unternehmen, das Sie im Ernstfall in Ihrer eigenen Jurisdiktion verklagen könnten.
• Aktivieren Sie den Registrar-Lock (clientTransferProhibited) für jede Domain und den Registry-Lock für die kritischen. Der Registry-Lock verlangt eine Verifikation außerhalb des Kanals, meist einen Telefonanruf mit Passphrase, bevor Nameserver oder Transfers geändert werden. Das ist lästig, und genau darum geht es.
• Nutzen Sie Hardware-Schlüssel oder TOTP als Zwei-Faktor-Authentifizierung, niemals SMS. Die Kriegsgeschichten über Support-Mitarbeiter, die nach einer überzeugenden Chat-Story die 2FA entfernt haben, sind zahllos. Einige Registrare bieten inzwischen Richtlinien wie „keine Kontoänderungen ohne Hardware-Schlüssel“ an. Nehmen Sie sie.
• Verwenden Sie eine eigene, rollenbasierte E-Mail-Adresse für das Registrar-Konto, die NICHT auf einer bei diesem Registrar registrierten Domain liegt. domains-admin@example.org, registriert irgendwo ganz anders.
• Beschränken Sie den Zugriff. Zwei oder drei namentlich bekannte Personen, Zugangsdaten im Firmen-Vault, kein geteiltes Login in einer Tabelle.
• Dokumentieren Sie alles: Kontonummer, PINs, Eskalationspfade im Support, die genauen Ausweisdokumente, mit denen das Konto verifiziert ist. Legen Sie das in Ihr Incident-Runbook.

Die Sperre hat echte Stärken. Sie verhindert die häufigste Registrar-Katastrophe, und die ist nicht die Beschlagnahme, sondern die Übernahme. Social-Engineering-Transfers und Kontoübernahmen haben seit Jahren wertvolle Domains gestohlen, und Registry-Lock plus Hardware-2FA stoppt fast alles davon. Außerdem ist sie günstig und erfordert keinen laufenden Engineering-Aufwand.

Aber die unbequeme Wahrheit lautet: Die Sperre schützt Sie vor Angreifern, nicht vor dem Registrar selbst. Jede der oben genannten Kontrollen wird vom Registrar betrieben. Wenn dessen Missbrauchs-Automatisierung Ihr Konto deaktiviert, sperrt der Registrar-Lock nun Sie aus, Ihre Support-PIN liegt in einem System, das Sie nicht erreichen, und der Mensch, der das alles übersteuern könnte, existiert vielleicht nicht mehr, weil der Support im letzten Quartal „optimiert“ wurde. Praktiker berichten von Wiederherstellungszeiten von über sechs Stunden selbst in eindeutigen Fehlalarm-Fällen und von mehrtägigen Odysseen, wenn die Sperre ein Wochenende umfasst. Die Sperre ist notwendig. Sie ist aber nicht ausreichend.

Ansatz zwei: Schichtenverteidigung. Davon ausgehen, dass der Registrar Sie im Stich lässt

Die Schichten-Philosophie geht von einer düstereren Prämisse aus: Eines Tages wird Ihr Registrar Ihre Domains aus Bosheit, durch Automatisierung oder aus Versehen vom Netz nehmen, und Sie müssen wieder online sein, bevor Sie in deren Support-Warteschlange vorrücken. Das ist dieselbe Denkweise wie beim defensiven Engineering gegen katastrophale Ausfälle: Sie verhindern die Katastrophe nicht, Sie machen sie überlebbar.

Die zentrale Technik besteht darin, Schichten zu trennen, die üblicherweise zusammengebündelt sind. Die meisten kleinen Unternehmen kaufen die Domain, nutzen das DNS des Registrars, hosten beim Hosting-Arm des Registrars und wickeln auch die E-Mails dort ab. Das sind vier Single Points of Failure, die in einem Konto übereinandergestapelt sind. Entkoppeln Sie sie:

• Registrierung: bei Registrar A, ausgewählt nach Stabilität und Support.
• Autoritatives DNS: bei einem unabhängigen DNS-Provider B (oder zwei Providern in einer Dual-Primary-Konfiguration), als Code verwaltet.
• Hosting: dort, wo es für die Workload sinnvoll ist, unabhängig von beiden anderen.
• E-Mail: ein eigener Anbieter, wobei die Wiederherstellungsadressen für A und B auf einer weiteren Domain liegen.
• Ersatzdomain: eine vorab bereitgestellte Ausweichdomain bei einem anderen Registrar, mit ausgestellten TLS-Zertifikaten und einer minimalen Version Ihrer wichtigsten Dienste, die bereits auf ihr antworten.

Die Ersatzdomain verdient besondere Betonung, weil sie kaum jemand einrichtet, und sie ist der Hebel mit der größten Wirkung. Wenn Ihre Hauptdomains gesperrt sind, bedeuten DNS-TTLs und Resolver-Caches, dass Sie nicht einfach „auf das Backup umschalten“ können. Das Backup muss schon vorher existiert, sich eingeschwungen und aufgelöst werden können. Eine Ausweichdomain wie example-status.net, anderswo registriert, mit Ihrer Status-Seite, Ihrer Incident-Kommunikation und einem Notfall-MX-Record, verwandelt einen firmengefährdenden Ausfall in einen peinlichen Dienstag.

DNS als Code: Die Schicht, die alle auslassen

Hier ist ein Fehler, den ich in echten Incidents zweimal gesehen habe: Das Team bekommt seine Domain nach einer Registrar-Sperre zurück, schaltet alles wieder ein, und das DNS ist falsch. Grund: Die „Single Source of Truth“ für die Zone war die Web-Oberfläche des Registrars, die während des Incidents nicht erreichbar war und ohnehin von niemandem mehr exakt im Kopf gehalten wurde. Eine 200-Record-Zonendatei während eines Ausfalls aus dem Gedächtnis neu aufzubauen, ist eine besondere Form von Elend. Wie wir schon an anderer Stelle geschrieben haben, bringen DNS-Fehlkonfigurationen Produktionssysteme auch im Normalbetrieb immer wieder zum Absturz. Während eines Registrar-Incidents ist das katastrophal.

Die Lösung ist unspektakulär: Verwalten Sie Ihre DNS-Zone als Code, in der Versionskontrolle, ausgerollt durch CI. Werkzeuge wie dnscontrol oder die DNS-Provider von Terraform erlauben es, die Zone deklarativ zu beschreiben und auf mehrere Provider auszurollen. Dann übersteht Ihr DNS-Zustand den Verlust der Control-Plane jedes einzelnen Providers, und „auf DNS-Provider B umschalten“ ist eine Zeilenänderung und ein Deployment statt einer heroischen Copy-Paste-Session.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

Autoritatives DNS mit zwei Providern wird unterschätzt. Die meisten Resolver probieren bereitwillig alle gelisteten Nameserver durch. Fällt also ein Provider aus (und die großen DNS-Provider hatten schon Ausfälle), funktioniert die Auflösung weiter. Der Haken liegt darin, beide Provider synchron zu halten, und genau das liefert DNS als Code praktisch kostenlos. Ohne das ist DNS mit zwei Providern eine Drift-Maschine und womöglich schlechter als ein einzelner Provider.

Ein Vorbehalt zu TTLs: Teams drehen die TTLs gern auf 86400 „für die Performance“ und stellen dann im Incident fest, dass ein Viertel des Internets ihre alten Nameserver-Records einen ganzen Tag lang cached. Bei nameserver-nahen Records und allem, was Sie im Notfall ändern müssten, halten Sie die TTLs bei 300 bis 900 Sekunden. Die zusätzliche Query-Last ist im Vergleich zur gewonnenen Beweglichkeit trivial.

Direkter Vergleich: Wann welcher Ansatz gewinnt

Sprechen wir den Zielkonflikt offen an, denn die beiden Strategien optimieren auf unterschiedliche Bedrohungen und unterschiedliche Organisationen.

• Bedrohungsmodell: Die Sperre gewinnt gegen Übernahmen und Social Engineering, also die statistisch häufigen Katastrophen. Die Schichtenverteidigung gewinnt gegen Ausfälle auf Registrar-Seite: Missbrauchs-Automatisierung, Kontobeschlagnahme, Insolvenz oder Zusammenbruch des Supports.
• Kosten: Die Sperre kostet fast nichts: Gebühren für den Registry-Lock, ein Hardware-Schlüssel, Disziplin. Die Schichtenverteidigung kostet die Rechnung eines zweiten Providers, eine Ersatzdomain, CI-Infrastruktur und laufende Aufmerksamkeit, damit keine Drift entsteht.
• Wiederherstellungszeit: Bei einer Beschlagnahme sind reine Sperr-Teams dem Support-Warteschlange ausgeliefert (Stunden bis Tage, laut jeder Kriegsgeschichte, die ich gehört habe). Schicht-Teams mit einer warmen Ersatzdomain sind in Minuten bis Stunden wieder online.
• Betriebsaufwand: Die Sperre ist einmal eingerichtet und läuft dann. Die Schichtenverteidigung verrottet, wenn man sie nicht pflegt. Eine ungetestete Ausweichdomain mit abgelaufenem Zertifikat ist Security-Theater.
• Passung zur Organisation: Ein fünfköpfiges Startup mit einem SaaS-Produkt sollte die volle Sperre plus die zwei günstigsten Schichtenmaßnahmen umsetzen: DNS als Code bei einem externen Provider und eine Wiederherstellungs-E-Mail außerhalb der Domain. Ein Unternehmen, dessen Umsatz mit der Domain stirbt, braucht den vollständigen Schichten-Stack.

Die Sperre schützt Ihre Domains vor Angreifern. Die Schichtenverteidigung schützt Ihr Geschäft vor Ihrem Registrar. Sie sind beidem ausgesetzt, also brauchen Sie beides.

Das Wiederherstellungs-Runbook, das niemand schreibt, bis es zu spät ist

Welche Haltung Sie auch wählen, schreiben Sie das Beschlagnahme-Runbook jetzt. Die Incidents, die ich gut verlaufen sehen habe, hatten eines; die Desaster haben improvisiert. Ihres sollte der Reihe nach Folgendes abdecken: Umfang bestätigen (betrifft es eine Domain oder das ganze Konto? Prüfen Sie die Statuscodes im whois, etwa clientHold oder serverHold), ein Support-Ticket mit Ihren dokumentierten Kontokennungen eröffnen, die Ersatzdomain aktivieren und Ihre Status-Kommunikation aktualisieren, Kunden über Kanäle informieren, die nicht von der toten Domain abhängen, und parallel den Transfer-out anstoßen. Warten Sie nicht auf eine Auflösung, bevor Sie entscheiden, dass Sie gehen.

Üben Sie außerdem die langweiligen Teile. Können Sie sich mit dem Hardware-Schlüssel von einem sauberen Gerät aus beim Registrar anmelden, ohne den Passwort-Manager, der hinter dem SSO auf der gesperrten Domain liegt? Ist die Registry-Lock-Passphrase dort, wo der Bereitschaftsdienst sie findet? Teams testen ihr Datenbank-Failover vierteljährlich und die Registrar-Wiederherstellung nie. Da der Registrar-Ausfall genau das SSO mit reißt, über das Sie alles andere erreichen, ist diese Priorisierung verkehrt herum.

Meine Empfehlung

Sperren Sie vollständig ab. Das ist ein Nachmittag Arbeit und stoppt den wahrscheinlichsten Angriff. Setzen Sie dann genau drei Bausteine der Schichtenverteidigung um, in dieser Reihenfolge: Verlagern Sie das autoritative DNS weg vom Registrar und verwalten Sie es als Code. Legen Sie die Wiederherstellungs-E-Mail des Registrar-Kontos auf eine Domain bei einem anderen Registrar. Richten Sie eine warme Ausweichdomain mit Zertifikaten, Status-Seite und Notfall-MX ein. Diese drei decken die dominanten Ausfallmodi für einige hundert Euro im Jahr ab. Die volle Architektur mit zwei Registraren und zwei DNS-Providern sollten Organisationen vorbehalten bleiben, die beziffern können, was ein Tag totaler Domain-Verlust kostet. Wenn diese Zahl sechsstellig ist, wissen Sie bereits, was zu tun ist.

Und wenn Sie einen Registrar immer noch vor allem nach dem Preis aussuchen, hören Sie auf damit. Der Markt der Billig-Registrare konsolidiert sich unter Eigentümern, deren Anreiz darin besteht, menschliches Urteilsvermögen durch Automatisierung zu ersetzen, die Sie bei einem Fehlalarm bereitwillig sperrt und deren Ticket-Bearbeitung dann am Donnerstag erfolgt. Ihre Domain ist das eine Infrastrukturstück, das Sie nicht aus einem Container-Image neu ausrollen können. Behandeln Sie sie entsprechend.