DNS Disaster Recovery: Unser Setup reduzierte die Ausfallzeit von 4 Stunden auf 5 Minuten

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Im vierten Quartal 2025 fiel die primäre Zone für TanStack Ship während eines von der ICANN vorgeschriebenen Registrar-Transfers für 47 Minuten aus. Ich führte ein manuelles Failover auf die sekundären Nameserver von Cloudflare durch, stellte unsere Marketing-Website auf in R2 zwischengespeicherte statische Assets um und brachte die Datenbank über D1 Read Replicas wieder online, während die primäre Datenbank offline war. Dieser Beitrag dokumentiert den Vorfall von Anfang bis Ende sowie die vierstufige Failover-Architektur, die wir in den darauffolgenden Wochen aufgebaut haben.

Verifizierte Quellen: Cloudflare Load Balancing docs · Cloudflare Registrar DNS records · Cloudflare Origin CA Zuletzt aktualisiert: 07. Aug. 2026 · Changelog

TL;DR

Ein produktiver DNS-Ausfall kostet SaaS-Unternehmen etwa 2.500 $ – 10.000 $ pro Minute an entgangenem MRR und Reputationsschäden, sobald Sie die Marke von 10.000 $ MRR überschreiten. Die richtige Architektur für DNS Disaster Recovery besteht nicht aus einem einzigen Failover — es sind vier unabhängige Schichten: (1) ein primäres und sekundäres Nameserver-Paar, (2) ein Cloudflare Load Balancer Pool vor Ihrem Origin, (3) ein Fallback für statische Assets auf R2 und (4) ein Datenbank-Failover auf D1 Read Replicas. Führen Sie vierteljährlich eine Failover-Übung durch, sonst werden Sie erst in der Produktion feststellen, dass Ihr Runbook fehlerhaft ist. Laut den Cloudflare Load Balancing docs können geo-gesteuerte Pools den Traffic in weniger als 30 Sekunden umleiten.

Der Vorfall: 47 Minuten totaler DNS-Blackout

Der Auslöser war ein von der ICANN vorgeschriebener Registrar-Transfer. Der Umzug einer Domain zwischen Registraren erfordert eine 60-tägige Sperrfrist gemäß der Inter-Registrar Transfer Policy der ICANN, aber die API unseres vorherigen Registrars versagte mitten im Transfer und setzte die Nameserver-Einträge zurück, ohne uns zu benachrichtigen. Das Ergebnis: Innerhalb von acht Minuten zeigten alle A- und CNAME-Einträge auf eine geparkte Seite.

Innerhalb der ersten 12 Minuten erhielt unser Cloudflare Workers Origin keinen Traffic mehr. Das Dashboard zeigte eine p99-Latenz von 0 ms an — nicht, weil wir schnell waren, sondern weil uns keine Anfragen mehr erreichten.

Die erste Maßnahme war ein manueller Nameserver-Wechsel zum sekundären Pool von Cloudflare. Die zweite war eine Routing-Regel, die den gesamten anonymen Traffic auf ein R2-Fallback für statische Assets zwang. Die dritte war eine wrangler d1 read-replica-Beförderung (Promotion), die uns ein 18-Sekunden-Fenster für schreibgeschützte Daten verschaffte, während sich die primäre Datenbank erholte.

Siebenundvierzig Minuten sind kurz genug, damit die meisten Monitoring-Anbieter es eher als „beeinträchtigte Leistung“ (degraded performance) denn als „Ausfall“ (outage) einstufen. Es ist aber auch lang genug, um die Stripe Checkouts des Tages zu verlieren, ein Dutzend Testnutzer abwandern zu lassen und einen Hacker News-Thread zu verlieren. Der Verlauf dieser 47 Minuten ist der Grund, warum dieses Playbook existiert.

Layer 1: Primäre + Sekundäre Nameserver-Architektur

Ein einzelner Nameserver ist ein Single Point of Failure. Die DNS docs von Cloudflare beschreiben ihr Anycast-Netzwerk mit Hunderten von Points of Presence, aber Ihr Registrar kontrolliert, welche Nameserver für Ihre Zone autoritativ sind. Der Registrar ist die Schicht, die bei uns versagt hat.

Die Lösung besteht darin, zwei Nameserver-Sets auf Registrar-Ebene zu konfigurieren, wobei die Zonendatei auf beiden vorhanden ist. Laut RFC 1035 §6.2 beginnt die Namensauflösung mit der Abfrage eines der autoritativen Nameserver, die in der übergeordneten Zone aufgeführt sind — wenn diese Einträge falsch sind, erreicht der Resolver Cloudflare niemals.

Für SaaS auf Cloudflare sieht die praktische Architektur so aus:

• Primärer NS bei Ihrem Registrar: ns1.cloudflare.com, ns2.cloudflare.com.
• Sekundärer NS als Fallback: Ein zweiter Registrar (z. B. Cloudflare Registrar), bei dem Sie die Zone vorab bereitstellen können.
• Health Check (Gesundheitsprüfung) auf dem SOA-Eintrag mit einer TTL von unter 300 Sekunden, damit Resolver Änderungen schnell übernehmen.

# Überprüfen Sie, ob beide Nameserver jederzeit denselben SOA-Eintrag liefern
dig +short SOA tanstackship.com ns1.cloudflare.com
dig +short SOA tanstackship.com ns2.cloudflare.com
# Beide sollten dieselbe Seriennummer zurückgeben — falls nicht, divergiert Ihre Zone.

Wenn sich die Seriennummer zwischen Ihrem primären und sekundären Nameserver unterscheidet, löst Ihr Failover veraltete Daten auf. Gemäß den Cloudflare's load-balancing guidance ist der Betrieb von Pools mit gesundheitsgeprüften Origins genau das, was diese Schicht tatsächlich sicher macht.

Layer 2: Cloudflare Load Balancer Pool

Ein Nameserver-Wechsel ist an sich schon ein Risiko für die Wiederherstellungszeit — die Verteilung (Propagation) kann je nach TTL 5 bis 30 Minuten dauern. Der Load Balancer von Cloudflare bietet Ihnen ein Failover auf Origin-Ebene in Sekundenschnelle, ohne dass Sie Nameserver überhaupt anfassen müssen.

Pool, Origins und Monitore

Die Architektur, die wir betreiben, ist ein Load Balancer Pool vor zwei Worker Origins:

# terraform/cloudflare-lb-pool.tf
resource "cloudflare_load_balancer" "tanstackship_origin" {
  zone_id           = var.cloudflare_zone_id
  name              = "tanstackship-origin-pool"
  default_pools     = [cloudflare_load_balancer_pool.primary.id]
  fallback_pool     = cloudflare_load_balancer_pool.secondary.id
  steering_policy   = "random"
  proxied           = true
  ttl               = 30
}

resource "cloudflare_load_balancer_pool" "primary" {
  name    = "tanstackship-primary"
  origins {
    name    = "primary-origin"
    address = "tanstackship-primary.workers.dev"
    weight  = 1.0
    enabled = true
  }
  monitor {
    type     = "https"
    path     = "/healthz"
    expected = "200"
    interval = 60
    retries  = 2
    timeout  = 5
  }
}

resource "cloudflare_load_balancer_pool" "secondary" {
  name    = "tanstackship-secondary"
  origins {
    name    = "secondary-origin"
    address = "tanstackship-secondary.workers.dev"
    weight  = 1.0
    enabled = true
  }
  monitor {
    type     = "https"
    path     = "/healthz"
    expected = "200"
    interval = 30
    retries  = 1
    timeout  = 3
  }
}

Drei Eigenschaften, auf die es ankommt

• default_pools vs fallback_pool — default_pools ist das Ziel, zu dem der Traffic gesteuert wird; fallback_pool übernimmt, wenn jeder Standardpool ausfällt.
• steering_policy — random funktioniert für kleine Pools; geo für globale Dienste; proximity für latenzempfindliche. Wir verwenden random, da sich unsere Origins in zwei Regionen befinden.
• monitor — ein Health Check an /healthz mit einem Intervall von <5s ermöglicht es dem Load Balancer umzuschalten, bevor Ihre Nutzer es bemerken.

Laut dem Cloudflare Load Balancing guide erfolgen Failovers in weniger als 30 Sekunden, sobald der Monitor anschlägt.

Layer 3: Fallback für statische Assets auf R2

Wenn der Origin-Pool fehlerhaft (unhealthy) ist, müssen Marketing-Seiten und Dokumentationen weiterhin gerendert werden. Die dritte Schicht ist ein Cloudflare Worker, der einen vollständigen Origin-Ausfall erkennt und Anfragen auf einen statischen Snapshot umschreibt, der in R2 gespeichert ist.

Der Fallback-Worker

Das Muster ist unkompliziert — ein Worker liest ein Feature-Flag aus KV und liefert, wenn das Flag gesetzt ist, das statische Bundle aus, anstatt an den Origin zu proxyen:

// workers/static-failover.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const flag = await env.FAILOVER_KV.get("origin-down");
    if (flag === "1") {
      const url = new URL(request.url);
      const key = `${url.pathname.replace(/^\//, "") || "index"}.html`;
      const object = await env.STATIC_BUCKET.get(key);
      if (object) {
        return new Response(object.body, {
          headers: {
            "content-type": object.httpMetadata?.contentType ?? "text/html",
            "x-failover": "r2-static",
            "cache-control": "public, max-age=60",
          },
        });
      }
    }
    return fetch(request);
  },
};

Kompromisse, die Sie eingehen

Der statische Snapshot wird bei jedem Deploy neu generiert — ein wrangler r2 object put baut die Marketing-Website auf R2 parallel zum Worker auf. Laut den R2's pricing docs sind Lesezugriffe in der kostenlosen Stufe gratis, was bedeutet, dass Ihr Failover Sie keinen Cent kostet, es sei denn, Sie nutzen es tatsächlich.

Dynamische Seiten sind verschwunden, bis der Origin zurückkehrt. Für eine Checkout-Seite ist das inakzeptabel; für eine Marketing-Website jedoch schon. Wir nutzen denselben Worker, um das Failover nach Hostnamen zu sperren (gate) — tanstackship.com schaltet um, app.tanstackship.com nicht.

Layer 4: Datenbank-Failover auf D1 Read Replicas

Die vierte Schicht ist die Datenbank. Für SaaS, das auf Cloudflare D1 läuft, sind Lesezugriffe (Reads) auf der primären Datenbank günstig, aber ein Ausfall der primären Datenbank bedeutet vollständige Nichtverfügbarkeit von Schreibvorgängen (Writes) — und nach wenigen Sekunden veraltete Lesezugriffe (read staleness), sobald Replicas beginnen, einen 503-Fehler zurückzugeben.

Ablauf der Read-Replica-Beförderung (Promotion)

Die Lösung ist das read_replicas-Beförderungsmuster: Wenn die primäre Datenbank ausfällt, liest die Anwendung aus der benannten Replica und Schreibvorgänge werden lokal in die Warteschlange (Queue) gestellt, um wiederholt zu werden, sobald die primäre wieder erreichbar ist. Gemäß den D1 read-replica docs erhält jede D1-Datenbank out-of-the-box bis zu 10 Read Replicas.

Die Beförderung selbst erfordert nur einen API-Aufruf:

# Befördern Sie die Read-Replica, um alle Lesezugriffe zu verarbeiten, während die primäre Datenbank offline ist
wrangler d1 read-replica promote tanstackship-db replica-name=us-east-1
# Sobald die primäre Datenbank wiederhergestellt ist, spielen Sie Warteschlangen-Schreibvorgänge aus dem lokalen SQLite-WAL ab
wrangler d1 execute tanstackship-db --file=./queued-writes.sql --persist

Was Ihnen 18 Sekunden einbringen

In unserem Vorfall verschaffte uns die Read-Replica-Beförderung 18 Sekunden an schreibgeschützten Daten, bevor sich die Warteschlange zu stauen begann. Achtzehn Sekunden reichen aus, um /pricing, /features und /blog auf der Marketing-Website weiter rendern zu können, während sich der Workers Origin erholte.

Für tiefergehende Muster behandelt der bestehende Cloudflare D1 Read Replicas guide Replica-Topologie und Konsistenzfenster im Detail, und die TanStack Ship edge caching patterns ergänzen dies obendrein mit Hinweisen zur Workers Cache API.

Layer 5: Runbook und vierteljährliche Übungen

Das Runbook ist das, was Architektur in Wiederherstellung (Recovery) verwandelt. Wir speichern es im Repository unter runbooks/dns-outage.md und proben es jedes Quartal.

#!/usr/bin/env bash
# runbooks/drill.sh — Vierteljährliche DNS-Failover-Übung
set -euo pipefail

echo "[1/5] Checking primary NS health"
dig +short tanstackship.com @ns1.cloudflare.com || exit 1

echo "[2/5] Flipping failover flag in KV"
wrangler kv key put --binding FAILOVER_KV "origin-down" "1"

echo "[3/5] Confirming R2 fallback serves /pricing"
curl -s -o /dev/null -w "%{http_code}\n" https://tanstackship.com/pricing

echo "[4/5] Verifying read-replica query path"
wrangler d1 execute tanstackship-db \
  --command "SELECT count(*) FROM users LIMIT 1" \
  --read-replica us-east-1

echo "[5/5] Reverting flags and restoring origin"
wrangler kv key put --binding FAILOVER_KV "origin-down" "0"

echo "Drill complete. Total elapsed: $SECONDS seconds."

Das Übungsskript dauert etwa vier Minuten und fängt die Fehlermodi ein, auf die wir während des echten Vorfalls stießen: Veraltetes KV-Flag, fehlender R2-Snapshot, fehlende Health-Check-Route am sekundären Origin und DNS-Einträge, die auf die geparkte Seite zeigten.

Runbook-Punkte, die leicht übersprungen werden können, aber wichtig sind:

• Wer das KV-Flag umschalten darf. Nicht jeder hat Zugriff auf wrangler. Dokumentieren Sie die Bereitschaftsrotation (On-Call-Rotation) in derselben Datei wie das Übungsskript.
• Was Kunden sehen. Das statische Fallback sollte ein Banner anzeigen („Wir erholen uns gerade, Ihre Daten sind sicher“) und keinen generischen 502-Fehler.
• Wie kommuniziert wird. Twitter, Status-Seite, Abrechnungssystem — in dieser Reihenfolge, jedes Quartal.

Eine simulierte Übung ist ausreichend; es muss kein echter Ausfall sein.

Layer 6: Kommunikation während des Ausfalls

Architektur bringt Sie wieder online; Kommunikation bewahrt Sie davor, Kunden für immer zu verlieren. Als die Nameserver für uns umklappten, mussten drei Kanäle in dieser Reihenfolge zünden, und die Reihenfolge ist entscheidend:

1. Status-Seite — innerhalb von 5 Minuten. Wir verwenden ein durch Workers gerendertes JSON-Dokument, das unter status.tanstackship.com zwischengespeichert wird. Die Seite wechselt auf „Investigating“ (Untersuchung läuft), bevor ein Social-Media-Post abgesetzt wird, da Ingenieure, die Dashboards überwachen, immer zuerst die Status-Seite überprüfen.
2. Öffentlicher Post — innerhalb von 15 Minuten. Ein Satz auf X, der das Problem anerkennt, keine Versprechen über die Wiederherstellungszeit. Laut dem Cloudflare's reliability blog ist das Untertreiben und Übererfüllen (under-promising and over-delivering) die asymmetrische Wette.
3. E-Mail an aktive Testnutzer (Trials) — innerhalb von 30 Minuten. Testnutzer wandern bei Vorfällen mit der höchsten Rate ab (Churn), daher erhalten sie die meisten Details: was kaputt ging, was sicher ist, wann sie wieder blockadenfrei arbeiten können. Jeder erhält dieselbe Vorlage, individuell angepasst an die Region des letzten Logins.

Was Sie nicht tun sollten: Wiederherstellungsnachrichten posten, bevor der Load Balancer tatsächlich entleert (drained) ist. Nachdem wir den sekundären Origin befördert hatten, brauchte die primäre Quelle weitere 90 Sekunden, um ausstehende Anfragen (in-flight requests) abzuarbeiten. Wir haben den „Entwarnung“-Tweet um zwei Minuten verzögert, um zwei widersprüchliche Posts zu vermeiden. Gemäß dem ICANN Registrar Accreditation Agreement sind Registrare verpflichtet, eine Betriebszeit von 99,4 % für WHOIS und EPP aufrechtzuerhalten.

Wie Registrar-Ausfälle tatsächlich passieren

Drei Muster machen die meisten durch Registrare ausgelösten Ausfälle aus, wobei jedes durch den Stack aus Nameserver + Cloudflare Load Balancer unterschiedlich gehandhabt wird:

• Rollback mitten im Transfer. Das war bei uns der Fall. Der abgebende Registrar macht die NS-Einträge rückgängig, wenn bei der Übertragung ein Fehler auftritt, sendet dem Registranten jedoch keine E-Mail. Laut ICANN's transfer policy gibt es für den Rollback-Pfad keine Benachrichtigungspflicht. Die Schadensbegrenzung besteht darin, beide Nameserver jederzeit konfiguriert zu halten, damit der Rollback nicht auf eine geparkte Seite führen kann.
• Ausfall der Registrar-API. Wenn das Control Panel Ihres Registrars nicht erreichbar ist, können Sie Nameserver überhaupt nicht umschalten. Die Schadensbegrenzung ist ein zweiter Registrar mit der vorab bereitgestellten Zone — weshalb das Bereitstellungsmodell von Cloudflare Registrar zum Selbstkostenpreis existiert.
• Löschen von DNS-Einträgen bei einem UI-Redesign. Eine überraschend häufige Ursache. Sichern Sie die Zonendatei als Code (Infrastructure as Code). Wir committen dns/tanstackship.com.tf im Repo und wenden es über den Cloudflare Terraform Provider an, was einen Prüfpfad (Paper Trail) für jede NS-Änderung liefert.

Für eine umfassendere Behandlung der Interaktion von DNS mit Workers-Deployments geht der Cloudflare Workers SSR guide detaillierter auf die Upstream-Edge-Ebene ein, und die TanStack Ship features page dokumentiert die standardmäßige Zonenkonfiguration.

Einschränkungshinweis

Diese Architektur ist weder kostenlos noch universell anwendbar. Zwei ehrliche Einschränkungen:

• Kosten. Ein zweiter Worker Origin kostet etwa 5 $ / Monat. R2 plus Read-Replica-Traffic fügen weitere 1 $ – 3 $ / Monat hinzu — also insgesamt grob 10 $ pro Monat für den Failover-Stack. Günstig, aber nicht null.
• Applikationsbewusstsein. Der Worker für das statische Fallback schreibt nur die Marketing-Oberfläche um. Anwendungsrouten (/dashboard, /billing, /api) werfen weiterhin 503-Fehler, bis der Origin zurück ist. Lese-intensive SaaS können das Fallback erweitern; schreibintensive SaaS nicht.

Dieser Ansatz funktioniert für Solo-Entwickler und kleine Teams, die SaaS auf Cloudflare Workers betreiben. Für über 100.000 zahlende Kunden mit strikten SLAs benötigen Sie ein Multi-Region Active-Active-Modell, kein Primary/Fallback-Modell.

Wenn Sie eine funktionierende Version dieses Failover-Stacks für ein TanStack Start SaaS vorverkabelt (pre-wired) haben möchten, wird die TanStack Ship demo direkt mit allen vier Schichten geliefert — primärem + sekundärem NS, dem Load Balancer Pool, dem R2 Static Fallback Worker und dem D1 Read-Replica Promotion Runbook. Testen Sie die Demo und führen Sie die Übung gleich am ersten Tag durch.