DNS-Migration zu Cloudflare: die Checkliste, die drei Stunden lang Ausfälle vermeidet

Die DNS-Migration zu Cloudflare hat den Ruf, trivial zu sein: Importieren Sie die Zone, verweisen Sie auf die Nameserver und warten Sie, bis sie sich verbreitet. Die Teams, die drei Stunden lang gesperrt waren, folgten genau diesem Drehbuch. Das Problem ist, dass „trivial“ den perfekten Fall beschreibt und die Produktion selten perfekt ist.

Was der automatische Import nicht für Sie tut

Wenn Sie eine Domain zu Cloudflare hinzufügen, fragt die Plattform die autorisierenden Server des aktuellen Anbieters ab und versucht, alle Datensätze in der Zone zu importieren. Das Ergebnis ist eine Liste von Datensätzen, die vollständig erscheint – und dies fast immer auch ist. Im „Fast“ liegt das Risiko.

Datensätze vom Typ TLSA, die für DANE (DNS-benannte Entitätsauthentifizierung) verwendet werden, werden häufig nicht importiert. Dasselbe passiert mit einigen SRV-Datensätzen mit nicht standardmäßigen Konfigurationen, CAA-Datensätzen mit mehreren Flags oder ungewöhnlichen Werten und allen Datensätzen, die der vorherige Anbieter über eine nicht standardmäßige Antwort bereitstellt. Der Cloudflare-Import ist ein Ausgangspunkt, keine Garantie für Loyalität.

Das richtige Protokoll lautet: Exportieren Sie nach dem Import die aktuelle Anbieterzone im BIND-Format (die meisten Anbieter bieten dies an) und vergleichen Sie die beiden Datensätze manuell. Tools wie diff anhand der exportierten Zonendatei zeigen, was beim Import übersehen wurde. Dieser Schritt dauert zwanzig Minuten und verhindert, dass nach der Übergabe der Nameserver festgestellt wird, dass die Validierung des E-Mail-Zertifikats aufgrund eines fehlenden TLSA-Eintrags gestoppt wurde.

Cloudflare-Proxy und Nicht-HTTP-Dienste

Cloudflare arbeitet für jeden A- oder AAAA-Eintrag in zwei Modi: Proxy (der Datenverkehr läuft über das Netzwerk von Cloudflare, die echte IP bleibt verborgen) und Nur-DNS (reine Auflösung, ohne Vermittlung). Importierte MX-Einträge sind standardmäßig nur DNS-Einträge, was korrekt ist, da SMTP nicht über den Cloudflare-Proxy läuft.

Das Problem tritt bei A-Datensätzen auf, die auf E-Mail-Server oder einen anderen Dienst als HTTP/HTTPS verweisen. Ein A-Eintrag namens mail.exemplo.com, der auf den SMTP-Server verweist, kann während der Konfiguration versehentlich als Proxy verwendet werden, insbesondere wenn jemand die Datensätze überprüft und den Batch-Proxy aktiviert. Das Ergebnis ist, dass der E-Mail-Server nun Cloudflare-IPs anstelle der echten IP-Adressen offenlegt und externe SMTP-Verbindungen einen Proxy erreichen, der nicht weiß, was er mit ihnen machen soll. Der Fehler tritt nicht unmittelbar auf – einige E-Mail-Clients versuchen es erneut, die Zeitüberschreitung dauert einige Minuten und das Problem tritt zeitweise auf, bevor es wieder auftritt.

Das Gleiche passiert mit Datenbanken, die über DNS bereitgestellt werden. Ein A-Eintrag, der zu einem MySQL- oder PostgreSQL-Server hinter dem Proxy aufgelöst wird, gibt die Cloudflare-IP zurück. Die Anwendung versucht, eine Verbindung zu Port 3306 oder 5432 herzustellen, der Proxy lehnt dies ab (diese Ports werden standardmäßig nicht unterstützt) und die Verbindung schlägt mit einer Zeitüberschreitung fehl. Der Dienst scheint ausgefallen zu sein, aber das DNS „funktioniert“ – es zeigt nur auf die falsche Stelle.

Bevor Sie Nameserver umdrehen, überprüfen Sie jeden A- und AAAA-Eintrag und bestätigen Sie den richtigen Modus. Die Regel ist einfach: Wenn der Dienst an dieser Adresse nicht ausschließlich in HTTP/HTTPS auf den Ports 80 und 443 antwortet, muss der Modus „Nur DNS“ sein.

TTL und Ausbreitungsfenster

Die Weitergabe von Nameservern erfolgt nicht augenblicklich, und die TTL der Datensätze im aktuellen Anbieter bestimmt, wie lange es dauert, bis Resolver auf der ganzen Welt den alten Cache verwerfen. Wenn Ihre Datensätze eine TTL von 86400 Sekunden (24 Stunden) haben – der Standard für viele Anbieter – und Sie die Nameserver jetzt einschalten, werden einige der Resolver die alten Datensätze bis zu 24 Stunden lang weiter bereitstellen, unabhängig davon, was Cloudflare bereits sagt.

Die richtige Strategie beginnt zwei Tage vor der Migration. Senken Sie die TTL aller kritischen Datensätze beim aktuellen Anbieter auf 300 Sekunden (fünf Minuten). Warten Sie die Zeit, die der ursprünglichen TTL entspricht: Wenn die Datensätze bei 3600 Sekunden lagen, warten Sie eine Stunde. Wenn sie bei 86400 waren, warten Sie 24 Stunden. Erst dann die Nameserver einschalten. Wenn also die Änderung eintritt, verfallen Caches auf der ganzen Welt innerhalb von maximal fünf Minuten, und alle Probleme, die während der Migration auftreten, werden schnell gelöst – Sie müssen nicht darauf warten, dass 24-Stunden-Caches ablaufen, während der Vorfall auftritt.

Dieser Schritt wird am häufigsten ignoriert, da er eine vorherige Planung erfordert. Diejenigen, die am Tag vor der Migration eintreffen und feststellen, dass die TTLs bei 86400 liegen, haben zwei Möglichkeiten: Senken Sie die TTL und warten Sie 24 Stunden, bevor Sie fortfahren, oder nehmen Sie das Risiko eines langen Ausbreitungsfensters in Kauf. Die zweite Option ist der häufigste Weg zu einem Stromausfall, der länger anhält, als er sollte.

DNSSEC: das Detail, das die Weitergabe in einen Validierungsfehler verwandelt

Wenn für die Domäne DNSSEC beim aktuellen Anbieter aktiv ist, führt die Migration der Nameserver ohne Bearbeitung der DS-Einträge beim Registrar zu einem Validierungsfehler bei allen Resolvern, die DNSSEC prüfen. Der Resolver erhält die Benachrichtigung, dass die Domain DNSSEC verwendet (über den DS-Eintrag beim Registrar), fragt Cloudflare ab, erhält mit Cloudflare-Schlüsseln signierte Signaturen und lehnt die Antwort ab, weil die Schlüssel nicht mit dem DS übereinstimmen, der immer noch auf den vorherigen Anbieter verweist.

Die richtige Reihenfolge besteht aus vier Schritten mit dazwischen liegenden Wartefenstern. Entfernen Sie zunächst die DS-Einträge vom Registrar (nicht beim DNS-Anbieter, sondern beim Registrar, bei dem die Domain registriert ist). Warten Sie zweitens, bis die TTL der DS-Einträge abgelaufen ist – normalerweise zwischen einer und vier Stunden, je nach Rekorder. Drittens stellen Sie die Nameserver auf Cloudflare um. Viertens aktivieren Sie DNSSEC im Cloudflare-Dashboard und fügen Sie die neuen DS-Einträge hinzu, die die Plattform dem Registrar bereitstellt. Das Überspringen der Wartezeit zwischen dem ersten und dritten Schritt ist die häufigste Ursache für DNSSEC-Vorfälle bei Migrationen.

Wie man die Migration strukturiert, um unter Druck nicht zu improvisieren

Der Unterschied zwischen einer Migration, die in dreißig Minuten endet, und einer, die zu einem dreistündigen Vorfall wird, ist fast immer organisatorischer Natur. Teams mit guten Leistungen legen im Voraus fest, wer jeden Schritt validiert, was das Rollback konfiguriert und was die Erfolgskriterien sind, bevor sie die Migration für abgeschlossen erklären.

Der funktionierende Ablauf beginnt mit dem Vergleich der Zonen zwischen dem aktuellen Anbieter und Cloudflare, der vor jedem Pivot durchgeführt wird. Domains mit SPF, DKIM und DMARC erfordern besondere Aufmerksamkeit: TXT-Einträge können Anführungszeichen oder Verkettungen enthalten, die automatisch Neuformatierungen importieren und die Validierung unterbrechen, selbst wenn der Inhalt korrekt erscheint. SRV-Einträge für Dienste wie SIP, XMPP oder Minecraft erfordern eine manuelle Überprüfung der Prioritäts- und Gewichtungsfelder.

Nachdem die Nameserver übergeben wurden, enthält das Verifizierungsprotokoll drei Befehle, die nacheinander ausgeführt werden müssen. Der Befehl dig @1.1.1.1 +short exemplo.com NS bestätigt, dass Cloudflare bereits für die Domäne auf diesem Resolver autorisierend ist. Der Befehl dig @8.8.8.8 +short mail.exemplo.com A überprüft, ob das E-Mail-Protokoll die tatsächliche IP des Servers und keine Cloudflare-IP zurückgibt. Ein Testversand einer E-Mail von einer externen Adresse innerhalb der ersten dreißig Minuten nach der Bearbeitung schließt den grundlegenden Verifizierungszyklus ab.