Introduzione
DNS Failover è una tecnica per garantire alta disponibilità: se il server primario non risponde, il DNS reindirizza automaticamente verso un server secondario. In questa guida vediamo come funziona e come configurarlo correttamente.
Cos'è il DNS Failover
Il DNS Failover combina health check automatici su uno o più endpoint con la possibilità di cambiare dinamicamente la risposta DNS quando un'endpoint risulta non disponibile. Risultato: visitatori sempre indirizzati a un server funzionante.
Componenti
- Server primario: l'endpoint principale.
- Server secondario: backup in caso di down.
- Health check: probe periodici HTTP/TCP/ICMP.
- Policy: regole su quando fare switch.
- Notifiche: alert via email/Slack/webhook.
Provider con DNS Failover
- AWS Route 53: Health Checks + Failover Routing.
- Cloudflare: Load Balancing con pool e steering.
- DNS Made Easy: Real-time Failover.
- Constellix: ITO + Sonar.
- NS1: Filter Chain.
- Google Cloud DNS: tramite Cloud Load Balancing.
- Azure DNS Traffic Manager.
Setup base con Route 53
- Crea due record A: uno primario, uno secondario.
- Configura un Health Check sull'IP/URL primario.
- Imposta routing policy "Failover" sui due record.
- Primario: "Primary", associato all'health check.
- Secondario: "Secondary".
Route 53 monitora ogni 30 sec; se il primario fallisce 3 check consecutivi, il DNS inizia a restituire il secondario.
Tipi di health check
- HTTP/HTTPS: GET su URL, verifica codice 2xx/3xx.
- TCP: connessione TCP sulla porta indicata.
- String match: cerca una stringa specifica nel body HTTP.
- Calculated: combinazione logica di altri health check.
- CloudWatch alarm: integra metriche custom (Route 53).
TTL e velocità di failover
Il TTL del record influenza il tempo di switch:
- TTL 60 sec → failover entro ~1 min.
- TTL 300 sec → failover entro ~5 min.
- TTL 3600 sec → failover entro ~1 h.
TTL bassi accelerano il failover ma aumentano il carico DNS.
Cache aggressiva dei resolver
Alcuni resolver ignorano TTL bassi e cacheano comunque per minuti/ore. Non puoi controllare al 100% i tempi di propagazione. Per applicazioni critiche valuta soluzioni anycast IP (BGP-based) invece di DNS-based.
Multi-region failover
Esempio scenario:
- Datacenter A (Milano): primario.
- Datacenter B (Francoforte): standby.
- Datacenter C (Londra): secondo standby.
Configura health check su A, B, C. Se A cade, switch a B; se anche B cade, a C.
Active-active vs Active-passive
- Active-passive: solo primario riceve traffico, secondario in attesa.
- Active-active: traffico distribuito (round robin, weighted, geo) tra tutti i server. Se uno cade, viene rimosso dal pool.
Best practice
- Health check sempre da più location geografiche.
- Timeout health check breve (5-10 sec).
- Verifica path significativo (non solo homepage che potrebbe essere cachata).
- Allerta immediata su trigger del failover.
- Test periodici di failover manuale.
- Documenta procedura di failback.
- Sincronizza dati tra server (database replication).
Limiti del DNS Failover
- Cache resolver imprevedibile.
- Browser e OS cache.
- Latenza di rilevamento (almeno 30-60 sec).
- Non gestisce sessioni: utenti già connessi potrebbero vedere errore.
Alternative
Per failover sub-secondo: soluzioni BGP anycast (Cloudflare, AWS Global Accelerator) o load balancer geografici.
Hai bisogno di aiuto?
Se vuoi gestione DNS affidata a G Tech Group, scrivici tramite il modulo di contatto.