DNS-Routing und Failover

1) Die Rolle von DNS in der Fehlertoleranz

• Verfügbarkeit (schneller/zuverlässiger Failover);
• Leistung (Geo/Latenz-Routing);
• Kosten (Minimierung der interregionalen egress und 3rd-Party-Anrufe);
• Sicherheit (DNSSEC, Anti-Hijack, CAA/DMARC/SPF-Kontrolle).

Der Schlüssel: kurze TTLs, wo Dynamik wichtig ist, und eine stabile Zonenarchitektur (public + private, split-horizon).

2) Arten von Aufzeichnungen und Praktiken

A/AAAA - Hauptadressen; Veröffentlichen Sie IPv6 wo immer möglich.
CNAME vs ALIAS/ANAME: Verwenden Sie im Stammverzeichnis der Domain ALIAS/ANAME (oder Provider apex-flattening).
TXT - SPF/DMARC/DKIM, Verifikation; CAA - Einschränkung für Zertifikatsinhaber.
SRV/NS - Service Discovery und Delegation.
SVCB/HTTPS ist ein moderner alternativer Mechanismus mit Prioritäten und Parametern (ALPN, Ports).

Empfehlung: TTL-Standards nach Klassen (Edge/API/Statik) festlegen.

3) Routing-Richtlinien

Weighted (gewichtet) - kontrollierte Verkehrsanteile (Kanarienvögel/blau-grün).
Latency-based - Wählen Sie den Pool aus, der der Verzögerung am nächsten liegt.
Geo-Routing - nach Land/Kontinent/Region; wichtig für die Datenresidenz.
Failover (primär/sekundär) - aktive Überwachung und Umschaltung.
Multi-Wert - mehrere A/AAAA; der Kunde selbst wählt (ersetzt nicht health-checks).
Proximity/ASN Routing - bei einigen Anbietern: über das Kundennetz.

Kombinieren Sie: geo → latency → weight → health.

4) TTL, Caching und Propagierung

TTL API/Lautsprecher: 30-120 s (Balance zwischen Failover-Geschwindigkeit und Last).
Static/CDN: 1–24 ч.
Negative TTL (SOA 'Minimum') - ≤ 60-300 s, sonst wird NXDOMAIN „klebrig“.
Denken Sie daran: Resolver müssen den Cache nicht sofort wegwerfen; Berücksichtigen Sie den „schmutzigen Schwanz“.

5) Gesundheit und Endpoint-Check

Health-Checks aus mehreren Regionen: TCP/443 + HTTP 2xx/3xx und Lambda-Checks von Geschäftskriterien (z.B. successful '/health? deep = true' mit Abhängigkeitsprüfung).
Synthetik (RUM/aktiv): API-Proben entlang der Hauptrouten, TLS/OCSP-Prüfung, DNSSEC-Prüfungen.
Belichten Sie '/ready'(tief) und '/live'(oberflächlich); Binden Sie den DNS-Pool an/ready.

6) Öffentliches vs privates DNS (split-horizon)

Public Zone - Client-Zugriff.
Private Zone - interne Lösung für private Endpunkte (VPC/VNet, on-prem).
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
Benennung: 'api. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) Sicherheit: DNSSEC und Domain-Politik

DNSSEC: Zonensignatur (KSK/ZSK) einfügen, Schlüsselrotation und Vertrauenskette überwachen.
CAA: Liste der gültigen CAs; Aktivieren Sie' iodef 'für Alert.
SPF/DMARC/DKIM: E-Mail-Reputation und Phishing-Schutz.
Registrar-Lok und MFA auf den Konten des DNS-Anbieters; Änderungsprotokoll (WORM-Speicher).

8) Failover-Design

8. 1 Modelle

Aktiv-Aktiv: zwei + gesunde Pools; Balance durch Latenz/Gewicht, Gesundheitschecks schließen ungesunde aus.
Aktiv-Passiv: Hauptpool + Reserve (0% Gewicht vor Unfall).
Regionalring: Verkehr in die „benachbarte“ Region bei einem lokalen Unfall.
Degradierter Modus: Schreiben Sie auf eine „leichte“ Website/Landing, wenn das Backend nicht verfügbar ist.

8. 2 Schritt-für-Schritt-Szenen

1. Das Monitoring erfasst die Degradation '/ready'.
2. DNS ändert die Antworten (schließt den Pool aus oder ändert die Gewichte).
3. Der Verkehr geht in eine gesunde Region, TTL bestimmt die Geschwindigkeit.
4. Nach der Stabilisierung - die grace-Periode (15-30 min) und nur dann die Rückkehr der Waage.

9) Beispiele für Konfigurationen

9. 1 AWS Route 53 — latency + health + weighted

hcl
Two latency aliases for different regions resource "aws_route53_record" "api_latency_eu" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1"
latency_routing_policy { region = "eu-central-1" }
alias { name = aws_lb. api_eu. dns_name zone_id = aws_lb. api_eu. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_eu. id ttl = 60
}

resource "aws_route53_record" "api_latency_us" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "us1"
latency_routing_policy { region = "us-east-1" }
alias { name = aws_lb. api_us. dns_name zone_id = aws_lb. api_us. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_us. id ttl = 60
}

Canary in EU: 10% of the weight of the resource "aws_route53_record" "api_weighted_canary" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1-canary"
weighted_routing_policy { weight = 10 }
alias { name = aws_lb. api_eu_canary. dns_name zone_id = aws_lb. api_eu_canary. zone_id evaluate_target_health = true }
ttl = 30
}

9. 2 Cloudflare - Geo/ASN und Failover Pool (Idee)

Load Balancer Pools c health-checks (HTTP/TCP), Load Balancer mit Geo Steering (Kontinente/Länder) und Session affinity.
Fallback: Seitenregel/Transformationsregel auf vereinfachtes Backend bei 5xx Peaks.

9. 3 Azure/GCP

Azure Traffic Manager: Priority/Weighted/Performance/Geographic.
Google Cloud Load Balancing + Cloud DNS policy: geo-policy + health-checks через External HTTP(S) LB.

10) Beobachtbarkeit und SLO DNS

SLI: Resolve-Erfolgsrate, 95. Perzentil der Resolve-Zeit, Anteil der frischen (Nicht-Stale) Antworten innerhalb der TTL.
SLO: z. B. '99. 95% der erfolgreichen Antworten ≤ 100 ms.
Metriken: NXDOMAIN-Rate, SERVFAIL-Rate, Gesundheitspools, Anteil des Verkehrs nach Regionen, Anteil der Kanarienvögel.
Beispiele: Verknüpfen Sie SLIs mit HTTP-Traces über 'trace _ id' in synthetics.

11) Test und Betrieb

Synthetik aus verschiedenen ASNs/Regionen (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/„ delv “zur Überprüfung auf DNSSEC;„ dig + trace “bei Anomalien.
Staging-Zone ('stg. example. com') für Failover-Proben; rehearsal-script ändert die Gewichte/Prioritäten und kehrt zurück.
Runbook: Wer und wie manuell Gewichte erhöht/senkt, wie man den Pool deaktiviert, wie man „Freeze“ durchführt.

12) Antipatterns

TTL = 3000 + bei kritischen A/AAAA → langsamer/chaotischer Failover.
Keine Health-Checks oder Überprüfung nur des TCP-Ports ohne geschäftliche Invarianten.
Ein Haufen CNAME-Ketten → langsame Resolves, Cash-Chaos.
Der einzige DNS-Anbieter ohne secondary/axfr-Reserve.
Nicht signierte Zone bei DNSSEC-Anforderung; irrelevante CAAs.
Einträge, die auf öffentliche IPs privater Backends/DBs hinweisen.

13) Spezifität von iGaming/Finanzen

Jurisdiktionen: Geo-/Country-Routing für Compliance (Weiterleitung an lokale Domain/Front).
PSP/KYC: dedizierte Subdomains mit separaten TTLs und Failover-Policies; Schnelle Umstellung auf Backup-PSP.
Verantwortungsvolles Spielen: Subdomains mit legalen Seiten sind immer verfügbar (Backup Statics/CDNs).
Audit: Zonenänderungsprotokoll im WORM-Speicher, Signatur der Änderungen und regelmäßige Reviews.
Blocklisten: DNS-Compliance-Regeln nach Region (Edge-Filterung + DNS-Routing).

14) Checkliste Prod-Ready

• TTL-Profile nach Klassen; negative TTL ≤ 300 s.
• Zwei unabhängige DNS-Anycast-Netzwerke (primary/secondary), MFA/Registrar-Lock.
• Policies: geo/latency/weight + health-checks aus mehreren Regionen.
• DNSSEC aktiviert, CAA/DMARC/DKIM/SPF aktuell.
• Split-horizon (public/private), private Zonen für den internen Verkehr.
• Runbook des Failovers/Return, Rehearsal-Skript, kanarische Domänen.
• SLI/SLO-Überwachung, Warnungen zu NXDOMAIN/SERVFAIL/RTT-Wachstum.
• Stajing Zone und regelmäßige „Übungen“ failover.
• Für iGaming: Routing nach Gerichtsbarkeit, separate Domains für PSP/KYC, unveränderliche Prüfung.

15) TL; DR

Bauen Sie eine kombinierte Politik auf: Geo/Latenz + Gesundheitschecks + Gewichte, mit TTL 30-120 s auf Dynamik. Trennen Sie Public/Private (Split-Horizon), aktivieren Sie DNSSEC und CAA, halten Sie Secondary DNS. Machen Sie einen rehearsalen Failover und beobachten Sie SLI/SLO DNS. Berücksichtigen Sie bei iGaming die Gerichtsbarkeiten und Reservierungen von PSP/KYC-Domains mit separaten Regeln und Protokollierung von Änderungen an WORM.