DNS-Management und Routing

Kurze Zusammenfassung

DNS ist ein „Name Level Router“. Von kompetenten TTLs, Zonen und Richtlinien hängt es ab, wie schnell und vorhersehbar die Benutzer an die richtigen Fronten/Gateways gelangen. Mindestsatz: Anycast-Anbieter, gesunde TTL, Health-Checks mit automatischem Failover, DNSSEC + CAA, IaC-Management und Beobachtbarkeit (SLO nach Antworten und Resolve-Zeit).

Grundlegende Architektur

Seriöse Server (Zonen) - verantwortlich für die Domänen des Unternehmens.
Rekursive Resolver (Clients/ISPs/eigene) - Fragen Sie die Wurzel → TLDs → autoritativ.
Anycast ist die gleiche IP-Adressierung auf einer Vielzahl von PoPs: Ein naher PoP reagiert schneller und übersteht Unfälle.

Zonen und Delegation

Die Root-Zone der Domain → 'NS' auf Provider seriöser Server.
Subdomains (z.B. 'api. example. com') kann zur Unabhängigkeit an einzelne' NS '/Provider delegiert werden.

Datensatztypen (Minimum)

„A “/„ AAAA“ - IPv4/IPv6 Adressen.
„CNAME“ das Pseudonym des Namens; nicht an der Wurzel der Zone verwenden (stattdessen ALIAS/ANAME bei den Anbietern).
'TXT' - Verifizierungen, SPF, benutzerdefinierte Tags.
'MX' - Mail (falls verwendet).
„SRV“ - Dienste (SIP, LDAP usw.).
'CAA' - wer kann Zertifikate für eine Domain ausstellen.
'NS '/' SOA' - Delegierung/Zonenparameter.
„DS“ - DNSSEC-Schlüssel für die übergeordnete TLD.

Beispiel für eine Zone (Fragment)

$TTL 300
@    IN SOA ns1.dns.example. noc.example. (2025110501 3600 600 604800 300)
IN NS ns1.dns.example.
IN NS ns2.dns.example.
@    IN A  203.0.113.10
@    IN AAAA 2001:db8::10 api   IN CNAME api-prod.global.example.
_www  IN CNAME cdn.example.net.
_caa  IN CAA 0 issue "letsencrypt.org"

TTL und Caching

Kurze TTL (30-300 c) - für Dynamik (API-Fronten, Failover).
Durchschnittliche TTL (300-3600 c) - für CDN/Statik.
Lange TTL (≥ 1 Tag) - für seltene Veränderungen (MX/NS/DS).
Wenn Sie Migrationen planen, senken Sie die TTL 24 bis 72 Stunden im Voraus.
Berücksichtigen Sie Negative Caching TTL (NXDOMAIN): verwaltet von 'SOA MINIMUM'.

Routing-Richtlinien (GSLB-Ebene)

Failover (aktiv/passiv) - Wir geben die Haupt-IP vor dem Fail Health-Check, dann die Reserve.
Weighted (traffic-split) - Verteilung des Verkehrs (z.B. canary 5/95).
Latency-based - die am nächsten gelegene PoR/Region für Netzwerkverzögerung.
Geo-Routing - nach Land/Kontinent; nützlich für lokale Gesetze/PCI/PII.
Multivalue - mehrere' A/AAAA 'mit Gesundheitskontrollen für jeden.

Räte

Für kritische APIs verbinden Sie Latenz-basierte + Gesundheitschecks + kurze TTL.
Für reibungslose Veröffentlichungen - gewichtet und schrittweise Erhöhung des Anteils.
Für regionale Beschränkungen - Geo und Listen erlaubter Anbieter.

Gesundheit und automatisches Schalten

Health-checks: HTTP (S) (200 OK, body/header), TCP (port), ICMP.
Reputation/Fingerprint: Überprüfen Sie nicht nur den Port, sondern auch die Richtigkeit des Backends (Version, Build-ID).
Empfindlichkeitsschwelle: „N“ erfolgreiche/erfolglose Prüfungen hintereinander, um Flapping zu vermeiden.
Wir essen die Metriken: Anteil der Healthy-Endpoints, Reaktionszeit, Anzahl der Umschaltungen.

Private Bereiche und Split-Horizon

Private DNS: interne Zonen in VPC/VNet/On-prem (z.B. 'svc. local. example`).
Split-Horizon: unterschiedliche Antworten für interne und externe Kunden (interne IP vs öffentliche).
Schutz vor Leckagen: Verwenden Sie keine „internen“ Namen nach außen; Stellen Sie sicher, dass private Bereiche nicht über öffentliche Anbieter abgewickelt werden.

DNS-Sicherheit

DNSSEC: Zonensignaturen (ZSK/KSK), Veröffentlichung von 'DS' in der übergeordneten Zone, Schlüsselrolle.
CAA: Limitieren Sie die Freigabe von TLS-Serts auf eine vertrauenswürdige CA.
DoT/DoH für Rekursor - Verschlüsselung von Kundenanfragen.
ACL/Rate-Limit auf maßgebliche: Schutz vor reflektierenden DDoS/ANY-Anfragen.
Subdomain Takeover: Scannen Sie regelmäßig CNAME/ALIAS „hängend“ nach Remote-Diensten (gelöschte Ressource - CNAME bleibt).
NS/Glue-Einträge: Konsistenz zwischen Registrar und DNS-Provider.

SLO und Beobachtbarkeit

SLO (Beispiele)

Verfügbarkeit von autoritativen Antworten: ≥ 99. 99 %/30 Tage.
Reaktionszeit zum Rekursor (p95): ≤ 50 ms lokal/ ≤ 150 ms global.
Erfolg der Gesundheitschecks: ≥ 99. 9%, falsch positive - ≤ 0. 1%.
Nachlaufzeit (Propagation): ≤ 5 min bei 60 s TTL.

Metriken

RCODE (NOERROR/NXDOMAIN/SERVFAIL), QPS, p50/p95 Antwortzeit.
Aktien IPv6/IPv4, EDNS-Größe, Truncated (TC) Antworten.
Anzahl der Wechsel durch Health-Check, Flapping, DNSSEC Signaturfehler.
Anteile der DoH/DoT-Anfragen (wenn Sie den Recursor steuern).

Hohlwege

Abfragen (qname, qtype, rcode, client ASN/geo), Anomalien (ANY-Stürme, häufige NXDOMAIN durch ein Präfix).

IaC und Automatisierung

Terraform/DNS-Anbieter: Halten Sie Zonen im Repository, PR-Revue, Plan/Appruve.
ExternalDNS (K8s): Automatische Erstellung/Löschung von Einträgen aus Ingress/Service.
Zwischenumgebungen: Präfixe' dev. '/' stg. 'und individuelle Konten des DNS-Providers.

Terraform (vereinfachtes Beispiel)

hcl resource "dns_a_record_set" "api" {
zone = "example.com."
name = "api"
addresses = ["203.0.113.10","203.0.113.20"]
ttl = 60
}

resource "dns_caa_record" "caa" {
zone = "example.com."
name = "@"
ttl = 3600 record {
flags = 0 tag  = "issue"
value = "letsencrypt.org"
}
}

Resolver, Cache und Performance

Native Recursor (Unbound/Knot/Bind) sind näher an Anwendungen → kleiner als p95.
Aktivieren Sie prefetch hot records, serve-stale, wenn die Autorität nicht verfügbar ist.
EDNS (0) und die richtige Puffergröße, DNS Cookies, minimal-responses.
Trennen Sie Resolve-Threads und Anwendungsverkehr (QoS).
Berücksichtigen Sie Negative TTL: Eine Menge NXDOMAIN von einem „gebrochenen“ Client kann den Cache punkten.

DDoS und Nachhaltigkeit

Anycast-Anbieter mit globalen PoPs und Bot-Traffic-Aggregation.
Response Rate Limiting (RRL) auf maßgebliche, Schutz vor Amplifikation.
Verbot „ANY“, Beschränkung des EDNS-Puffers, Filter auf „schwere“ Typen.
Zonensegmentierung: kritisch - beim Anbieter mit dem besten DDoS-Schild; weniger kritisch - getrennt.
Standby-Provider (secondaries) mit 'AXFR/IXFR' und automatischem NS-Failover auf Registrar-Ebene.

Aktivitäten und Prozesse

Änderungen: PR-Überprüfung, kanarische Aufzeichnungen, Aufwärmen von Caches (niedrige TTL → Deploy → TTL zurückgeben).
DNSSEC Rollover: Vorschriften, Fenster, Validitätsüberwachung (RFC 8901 KSK/ZSK).
Runbook: PoP-Sturz, falsche NS-Delegation, abgefallener Gesundheitscheck, massive SERVFAIL.
DR-Plan: alternativer DNS-Anbieter, vorgefertigte Zonenvorlagen, Zugriff auf den Registrar, SLA auf NS-Schicht.

Checkliste Umsetzung

• Zwei unabhängige seriöse Anbieter/RoR (Anycast), korrekte' NS 'beim Registrar.
• TTL-Strategie: kurz für Dynamik, lang für stabile Aufnahmen; negative TTL unter Kontrolle.
• Health-checks and policies: failover/weighted/latency/geo on the profile of services.
• DNSSEC (KSK/ZSK/DS), 'CAA' begrenzt die Freigabe von Serts.
• IaC für Zonen, ExternalDNS für K8s, separate Umgebungen/Konten.
• Monitoring: rcode/QPS/latency/propagation, Alerts per SERVFAIL/Signaturen.
• DDoS: Anycast, RRL, EDNS-Einschränkungen, Blocklisten/ACLs.
• Regelungen für Domain-Migrationen und TTL-Downgrades in 48 bis 72 Stunden.
• Regelmäßige Prüfung der „hängenden“ CNAME/ALIAS, MX/SPF/DKIM/DMARC (wenn Post verwendet wird).

Typische Fehler

Zu große TTL bei kritischen 'A/AAAA' - lange Migrationen/Failover.
Ein DNS-Anbieter/ein PoP ist SPOF.
Kein DNSSEC/CAA - Gefahr von Substitutionen/unkontrollierten Serts.
Inkonsistente Split-Horizon → interne Namenslecks nach außen.
Keine Gesundheitschecks bei der GSLB - Umschalten mit den Händen und Verzögerungen.
Vergessene CNAMEs auf externe Dienste → das Takeover-Risiko.
Das Fehlen von IaC → „Schneeflocke“ -Konfigs und Fehlern bei manuellen Bearbeitungen.

Spezifität für iGaming/Fintech

Regionale Versionen und PSP: Geo/Latency-Routing, Partner-IP/ASN-Whitelists, schneller Gateway-Failover.
Peaks (Matches/Turniere): kurze TTL, Aufwärmen des CDN, separate Namen für Events ('event-N. example. com') mit einer verwalteten Richtlinie.
Rechtliche Korrektheit: Zeit und Version der Zonen bei kritischen Änderungen erfassen (Prüfprotokoll).
Anti-Fraud/BOT-Schutz: separate Namen für Tiebreakers/Captchi/Check-Endpoints; schneller Rückzug auf das „schwarze Loch“ (Sinkhole) bei Angriffen.

Mini-plejbuki

1. `api-canary. example. com '→ 5% des Datenverkehrs; 2) p95/p99/Fehler überwachen; 3) Wir erhöhen bis zu 25/50/100%; 4) beim Abbau zusammenrollen.

1. TTL 60 s; 2) health-check markierte die region down → GSLB zog sich aus den Antworten zurück; 3) Überprüfung der externen Resolver; 4) Statuskommunikation.

1. Importieren einer Zone in einen neuen Anbieter; 2) Wir schließen synchrones secondary am alten ein; 3) Ändern Sie' NS 'am Recorder in ein „ruhiges“ Fenster; 4) Wir beobachten SERVFAIL/val-Fehler.

Ergebnis

Eine zuverlässige DNS-Schleife ist Anycast-Autorität + vernünftige TTL + Gesundheit/Verzögerung Routing + DNSSEC/CAA + IaC und Beobachtbarkeit. Erfassen Sie Migrations- und Rollover-Prozesse, halten Sie einen Backup-Anbieter, überprüfen Sie die Zone regelmäßig auf „hängende“ Einträge - und Ihre Benutzer werden selbst in der „heißesten“ Stunde stabil an die richtigen Fronten gelangen.