Routing e failover DNS

1) Ruolo DNS nella disponibilità

• Disponibilità (failover veloce/affidabile)
• Prestazioni (geo/latency-routing)
• Costo (riduzione dell'egress interregionale e 3rd-party chiamate);
• Sicurezza (DNSSEC, anti-hijack, controllo CAA/DMARC/SPF).

Chiave: TTL brevi dove l'altoparlante è importante e architettura di zona stabile (public + private, split-horizon).

2) Tipi di record e pratiche

A/AAAA - indirizzi principali; pubblicare sempre IPv6 dove possibile.
CNAME vs ALIAS/ANAME: alla radice del dominio, utilizzare ALIAS/ANAME (o apex-flattening di provider).
TXT - SPF/DMARC/DKIM, verifiche; CAA - limitazione dei certificati.
SRV/NS - servizio discovery e delega.
SVCB/HTTPS è un moderno meccanismo alternativo con priorità e parametri (ALPN, porte).

Raccomandazione: fissa gli standard TTL per classe (edge/API/statico).

3) Criteri di instradamento

Weighted è una quota di traffico controllata (canarini/blue-green).
Latency-based - Seleziona il pool più vicino in ritardo.
Geo-routing - per paese/continente/regione; è importante per data residency.
Failover (primary/secondary) - Monitoraggio attivo e failover.
Multi-value - più A/AAAA; il client seleziona (non sostituisce health-checks).
Proximity/ASN routing - Alcuni provider utilizzano la rete client.

Combinare geo → latency → weight → health.

4) TTL, memorizzazione e memorizzazione

API/altoparlanti TTL: 30-120 s (bilanciamento tra velocità del feelover e carico).
Static/CDN: 1–24 ч.
Il TTL negativo (SOA 'Minimum') è di 60-300 s, altrimenti NXDOMAIN sarà «appiccicoso».
Ricordate che i resuscitori non devono buttare la cache immediatamente; Considerate la coda sporca.

5) Salute e controllo degli endpoint

Health-checks provenienti da diverse regioni: TCP/443 + HTTP 2xx/3xx e controllo lambda dei criteri aziendali (ad esempio, successo '/health? deep = true "con controllo delle dipendenze).
Sintetico (RUM/Active): prove API sulle rotte principali, controllo TLS/OCSP, controlli DNSSEC.
Esporre «/ready »(profondo) e «/live» (superficiale); Collegare il pool DNS a/ready.

6) Pubblico vs DNS privato (split-horizon)

Public zone - Accesso client.
Private zone - Risoluzione interna a private endpoint (VPC/VNet, on-prem).
Conditional forwarding между on-prem ↔ cloud, region ↔ region.
Denominazione: 'api. <brand>.<region>.internal. corp` и `api. <brand>.com`.

7) Protezione: DNSSEC e criteri di dominio

DNSSEC: abilita la firma della zona (KSK/ZSK), controlla la rotazione delle chiavi e la catena di fiducia.
CAA: elenca CA validi; accendete iodef per gli alert.
SPF/DMARC/DKIM - Reputazione e protezione contro il phishing.
Registrar-lock e MFA per gli account del provider DNS; Registro delle modifiche (WORM).

8) Progettazione failover

8. 1 Modelli

Active-Active: due pool più sani bilanciamento attraverso latency/weight, health-checks escludono i malsani.
Attivo-Passive: pool principale + riserva (0% di peso prima dell'incidente).
Regionale ring: traffico verso la regione «vicina» in caso di incidente locale.
Modalità Delraded: scrittura su un sito/landing «leggero» se il backend non è disponibile.

8. 2 Sceneggiatura passo passo

1. Il monitoraggio rileva la degradazione dì/ready ".
2. Il DNS cambia le risposte (esclude il pool o cambia peso).
3. Il traffico va verso una regione sana, TTL determina la velocità.
4. Dopo la stabilizzazione, il periodo grace (15-30 min) e solo dopo il ritorno della bilancia.

9) Esempi di configurazione

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 e failover pool (idea)

Load Balanner Pools c health-checks (HTTP/TCP), Load Balanker con Geo Steering (continenti/paesi) e Sessione affinity.
Fallback: Page Rule/Form Rule per backend semplificato a 5xx picchi.

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) Osservabilità e SLO DNS

SLI: success-rate resolva, 95 percento del tempo resoluto, la percentuale di risposte fresche (non stale) all'interno della TTL.
Ad esempio, '99. Il 95% delle risposte riuscite è 100 ms.
Metriche: NXDOMAIN-rate, SERVFAIL-rate, health-state pool, quota di traffico per regione, quota di canarini.
Exemplars: collega la SLI ai tracciati HTTP tramite «trace _ id» nel sintetico.

11) Test e utilizzo

Sintetici di diverse ASN/regioni (RIPE Atlas, Catchpoint, k6-DNS).
dnsviz/« delv »per il controllo DNSSEC;« dean + trace »in caso di anomalie.
Zona staging ('stg. example. com ') per le prove del feelover; rehearsal-script cambia peso/priorità e riporta indietro.
Runbook: chi e come aumenta/diminuisce il peso manualmente, come disattivare il pool, come eseguire «freeze».

12) Antipattern

TTL = 3000 + su critici A/AAAA → lento/caotico.
Nessuna health-checks o convalida solo porta TCP senza invarianti aziendali.
Un mucchio di catene CNAME, → lenti, caos cache.
Unico provider DNS senza secondary/axfr.
Zona non firmata quando il DNSSEC è richiesto; CAA non rilevanti.
Registrazioni che indicano un IP pubblico di backend/database privati.

13) Specificità iGaming/finanza

Giurisdizione: geo-/country-routing per soddisfare i requisiti (reindirizzamento al dominio/fronte locale).
PSP/KYC: sottotitoli selezionati con singoli TTL e regole di feeling; Rapida traduzione su PSP di riserva.
Gioco responsabile: le finte pagine legali sono sempre disponibili (statici di riserva/CDN).
Controllo: registro delle modifiche della zona all'archivio WORM, firma delle modifiche e ruvidità regolari.
Fogli di blocco: regole DNS per regione (edge-filtro + instradamento DNS).

14) Foglio di assegno prod

• Profili TTL per classe TTL negativo da 300 ≤.
• Due reti anycast indipendenti DNS (primary/secondary), MFA/registratore-lock.
• Criteri: geo/latency/weight + health-checks da più regioni.
• DNSSEC abilitato, CAA/DMARC/DKIM/SPF valido.
• Split-horizon (public/private), zone private per il traffico interno.
• Runbook feelover/ritorno, script rehearsal, domini canarini.
• Monitoraggio SLI/SLO, alert su NXDOMAIN/SERVFAIL/Crescita RTT.
• Zona di stallo e «esercitazioni» regolari failover.
• Routing per giurisdizione, domini separati per PSP/KYC, controllo invariato.

15) TL; DR

Costruisci una politica combinata: geo/latency + health-checks + peso, con TTL 30-120 s sulla dinamica. Separare public/private (split-horizon), includere DNSSEC e CAA, mantenere secondary DNS. Fare rehearsal-feelover e osservare SLI/SLO DNS. Per iGaming, tenere conto della giurisdizione e della ridondanza di domini PSP/KYC con regole separate e la logica delle modifiche WORM.