DNS rutare și failover

1) Rolul DNS în toleranța la erori

• Disponibilitate (failover rapid/fiabil);
• Performanță (geo/latență-rutare);
• Cost (minimizarea ieșirilor interregionale și a apelurilor terților);
• Securitate (DNSSEC, anti-deturnare, CAA/DMARC/SPF control).

Cheie: TTL-uri scurte în care dinamica este importantă și arhitectura zonală stabilă (public + privat, split-horizon).

2) Tipuri de înregistrări și practici

A/AAAA - adrese principale; publicați întotdeauna IPv6 ori de câte ori este posibil.
CNAME vs ALIAS/ANAME: La rădăcina domeniului, utilizați ALIAS/ANAME (sau furnizorul apex-aplatizare).
TXT - SPF/DMARC/DKIM, verificare; CAA - limitarea emitenților de certificate.
SRV/NS - descoperirea serviciului și delegarea.
SVCB/HTTPS este un mecanism alternativ modern cu prioritizare și parametri (ALPN, porturi).

Recomandare: fixați standardele TTL pe clase (edge/API/static).

3) Politici de rutare

Ponderat - cote controlate de trafic (canari/albastru-verde).
Bazat pe latență - Selectați piscina care este cea mai apropiată în latență.
Geo-rutare - pe țări/continente/regiuni; important pentru rezidența datelor.
Failover (primar/secundar) - monitorizare activă și comutare.
Multi-valoare - mai multe A/AAAA; clientul se alege singur (nu înlocuiește controalele de sănătate).
Proximitate/rutare ASN - pentru unii furnizori: prin rețeaua clientului.

Combină: geo → latență → greutate → sănătate.

4) TTL, cache și propagare

TTL API/boxe: 30-120 s (echilibru între viteza feiler și sarcina).
Static/CDN: 1-24 ч.
TTL negativ (SOA „Minim”) - ≤ 60-300 s, în caz contrar NXDOMAIN va fi „lipicios”.
Amintiți-vă: rezolvătoarele nu sunt necesare pentru a arunca instantaneu memoria cache; ia în considerare „coada murdară”.

5) Criterii finale de sănătate și verificare

Controale de sănătate din mai multe regiuni: verificări ale criteriilor de afaceri TCP/443 + HTTP 2xx/3xx și lambda (de ex. succes "/sănătate? deep = true 'cu verificarea dependenței).
Sintetice (RUM/active): probe API de-a lungul rutelor principale, controale TLS/OCSP, verificări DNSSEC.
Expuneți „/gata ”(adânc) și „/viu” (superficial); Legați piscina DNS la/gata.

6) Public vs privat DNS (split-orizont)

Zona publică - acces client.
Zonă privată - rezoluție internă la puncte finale private (VPC/VNet, on-prem).
Redirecționarea condiționată между on-prem ↔ nor, regiune ↔ regiune.
Denumire: 'api. <brand>. <regiune> .internal. Corp 'и' api. <brand> .com '.

7) Securitate: DNSSEC și politica de domeniu

DNSSEC: activați semnătura zonei (KSK/ZSK), monitorizați rotația cheii și lanțul de încredere.
AAC: lista CA valabile; include „iodef” pentru alerte.
SPF/DMARC/DKIM: reputația poștei și protecția împotriva phishingului.
Blocare registrator și MFA pentru conturile furnizorului DNS; schimbare jurnal (magazin WORM).

8) Proiectarea failover

8. 1 Modele

Active-Active: două + piscine sănătoase; echilibrul prin latență/greutate, controalele de sănătate exclud nesănătoase.
Activ-pasiv: piscina principală + rezervă (0% greutate înainte de accident).
Inel regional: traficul către regiunea „vecină” într-un dezastru local.
Mod degradat: scrieți la site-ul „ușor ”/aterizare dacă backend-ul nu este disponibil.

8. 2 Scenariu pas cu pas

1. Monitorizarea înregistrează degradarea „/gata ”.
2. DNS modifică răspunsurile (elimină piscina sau modifică greutatea).
3. Traficul merge într-o regiune sănătoasă, TTL determină viteza.
4. După stabilizare - perioada de grație (15-30 min) și numai apoi întoarcerea solzilor.

9) Exemple de configurare

9. 1 AWS Route 53 - latență + sănătate + ponderat

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 și failover pool (idee)

Balansoare de încărcare c controale de sănătate (HTTP/TCP), Balancer de încărcare cu direcție geo (continente/țări) și afinitate de sesiune.
Rezervă: Regula paginii/Regula transformării într-un backend simplificat la vârfurile 5xx.

9. 3 Azure/GCP

Managerul de trafic Azure: prioritate/ponderat/performanță/geografic.
Google Cloud Load Balancing + Cloud DNS policy: geo-policy + health-checks через Extern HTTP (S) LB.

10) Observabilitate și DNS SLO

SLI: rezoluția ratei de succes, a 95-a percentilă a timpului de rezoluție, proporția de răspunsuri proaspete (non-stale) în TTL.
SLO: de exemplu, '99. 95% din răspunsurile de succes ≤ 100 ms.
Metrics: NXDOMAIN-rata, SERVFAIL-rata, bazine de sănătate-stat, cota de trafic pe regiune, cota canar.
Exemplare: Asociați SLI cu urme HTTP prin 'trace _ id' în sintetică.

11) Testarea și funcționarea

Sintetice din diferite ASN/regiuni (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/" delv "pentru a verifica DNSSEC;" dig + trace "pentru anomalii.
Zona de punere în scenă ('stg. exemplu. com ") pentru repetiții feilover; scriptul de repetiție schimbă greutăți/priorități și revine.
Runbook: cine și cât de manual ridică/scade greutățile, cum să opriți piscina, cum să efectuați „înghețarea”.

12) Antipattern

TTL = 3000 + pe critic A/AAAA → feilover lent/haotic.
Nu există controale de sănătate sau controale portuare numai TCP fără invarianți de afaceri.
O grămadă de lanțuri CNAME → rezoluții lente, haos cache.
Singurul furnizor DNS fără backup secundar/axfr.
Zonă nesemnată atunci când este necesară DNSSEC; AAC irelevante.
Intrări care indică IP-ul public al backendurilor/bazelor de date private.

13) Specificul iGaming/Finanțe

Jurisdicții: geo/țară-rutare pentru conformitate (redirecționare către domeniul local/față).
PSP/KYC: subdomenii dedicate cu TTL individuale și politici feilover; transfer rapid la PSP standby.
Joc responsabil: subdomenii cu pagini legale sunt întotdeauna disponibile (backup static/CDN).
Audit - Modificări ale zonei jurnalului în magazinul WORM, modificări ale semnelor și revizuire regulată.
Liste de blocuri: reguli de conformitate DNS pe regiuni (filtrare margine + rutare DNS).

14) Lista de verificare Prod Readiness

• Profiluri TTL pe clase; TL negativ ≤ 300 s.
• Două rețele DNS independente (primar/secundar), blocare MFA/registrar.
• Politici: geo/latență/greutate + controale de sănătate din mai multe regiuni.
• DNSSEC activat, CAA/DMARC/DKIM/SPF până la data.
• Split-orizont (public/privat), zone private pentru traficul intern.
• Flyer/return runbook, script repetiție, domenii canare.
• Monitorizarea SLI/SLO, alerte privind creșterea NXDOMAIN/SERVFAIL/RTT.
• Zona de montare și regulat failover „burghiu”.
• Pentru iGaming: rutare pe jurisdicție, domenii separate pentru PSP/KYC, audit de neschimbat.

15) TL; DR

Construiți o politică combinată: geo/latență + controale de sănătate + greutăți, cu TTL 30-120 s pe difuzor. Separat public/privat (split-horizon), activați DNSSEC și CAA, păstrați DNS secundar. Faceți o repetiție-feilover și observați SLI/SLO DNS. Pentru iGaming, luați în considerare jurisdicțiile și rezervările de domenii PSP/KYC cu reguli separate și înregistrarea modificărilor în WORM.