L2 TunnelDNS

Failover senza toccare il DNS: il dividendo dell'L2

Cambiare i record DNS in emergenza è la cosa più stressante di un DR L3. Con un L2 tunnel non serve, perché l'IP è lo stesso.

2 min di lettura

TL;DR

Cambiare i record DNS in emergenza è la cosa più stressante di un DR Layer 3: TTL, propagazione, cache di sistema, bug applicativi. Con un L2 tunnel non serve, perché l'IP della VM ricoverata è lo stesso del primario.

Il problema del DNS in emergenza

In un DR Layer 3 standard:

  1. la VM cloud ottiene un IP nuovo (es. 10.99.0.50);
  2. i record DNS interni vanno aggiornati (erp.local A 10.99.0.50);
  3. il TTL precedente resta in cache fino alla scadenza (15 min - 24h);
  4. alcuni client hanno cache locale aggressiva;
  5. alcune app fanno DNS lookup solo all'avvio e tengono l'IP in cache.

Risultato: nei 30-90 minuti dopo il fail-over, alcuni client funzionano, altri no, in modo apparentemente random. È la peggior esperienza per i sistemisti in emergenza.

I tre tipi di cache DNS

Cache del resolver

I server DNS interni (Active Directory DNS, BIND, ecc.) cachano risposte. TTL configurato. Solitamente 1-4 ore.

Cache del sistema operativo

Windows: cache fino a TTL. Linux: con nscd o systemd-resolved, configurabile. macOS: aggressivo.

Cache applicativa

Le app Java, .NET, Python con configurazione default cachano DNS per la durata della JVM/processo. Restart dell'app = lookup nuovo. Senza restart = ostinata sul vecchio IP.

Il workaround del TTL basso

Una pratica diffusa: tenere TTL DNS interno bassi (5-15 min) per le risorse critiche. Aiuta, ma:

  • carica i resolver con più query;
  • non risolve la cache delle app;
  • richiede rigorosa policy di gestione DNS.

Funziona, ma è fragile.

Il vantaggio L2

Con tunnel L2 il problema non esiste:

  • l'IP della VM ricoverata è lo stesso del primario;
  • i client trovano l'IP in cache: corretto;
  • le app con IP cablato: continuano a funzionare;
  • nessuna modifica DNS necessaria.

Tempo speso per risolvere problemi DNS in emergenza: zero.

Quando comunque serve il DNS

Anche con L2 tunnel, alcuni casi richiedono DNS:

  • servizi pubblici (es. webmail, VPN aziendale verso l'esterno) — l'IP pubblico cambia, quindi DNS pubblico va aggiornato;
  • failover fra datacenter Sefthy diversi (caso raro);
  • migrazioni planificate.

FAQ

Posso disabilitare il TTL aggressivo dei client?

Sì, ma è un workaround fragile e impatta le performance. Meglio usare L2.

Le app cloud-native (web app moderne) hanno il problema?

Meno, perché si appoggiano a service discovery dinamico. Ma per app legacy il problema è reale.

Quanto si risparmia in RTO?

In media 15-45 minuti, dipende dal mix di app legacy.

Per il pillar L2, L2 tunnel per il DR. Per le legacy, L2 e applicazioni legacy.

Vuoi vedere Sefthy in azione?

Stesso IP, stessa subnet, RTO in minuti. Provalo gratis per 7 giorni o parla con un nostro specialista.

Vedi i piani Richiedi una demo