Anycast DNS: come funziona e perché è così veloce

Di norma un indirizzo IP identifica una macchina precisa, raggiungibile attraverso un preciso percorso di rete. L'anycast rompe questo presupposto di proposito: lo stesso indirizzo IP viene annunciato, nello stesso momento, da molte sedi fisicamente separate in giro per il mondo. Il routing di Internet consegna poi ogni richiesta alla sede più vicina a chi la invia in termini topologici: non necessariamente la più vicina in distanza fisica, ma la più vicina per percorso di rete.

Perché l'infrastruttura DNS ne fa un uso così intenso

I resolver pubblici come 1.1.1.1 e 8.8.8.8 sono indirizzi anycast. Quando interroghi 1.1.1.1 da Tokyo e qualcun altro interroga lo stesso identico indirizzo da Berlino, in realtà raggiungete due server fisici diversi (quello più vicino sulla rete), pur avendo entrambi scritto esattamente lo stesso indirizzo IP nella configurazione. È ciò che permette a un singolo IP facile da ricordare di garantire una latenza costantemente bassa in tutto il mondo, invece di far convergere tutti su un solo data center fisico, ovunque si trovino.

• Resilienza: se una sede anycast va offline, il routing sposta semplicemente il traffico su quella successiva più vicina, spesso senza che il client se ne accorga.
• Non è una prerogativa del DNS: anche le CDN e altri servizi sensibili alla latenza usano la stessa tecnica di fondo.

Cosa ne ricavi in pratica

Per sfruttare l'anycast non devi configurare nulla di diverso: tutto avviene a livello di routing di rete, in modo invisibile all'applicazione che esegue la query. Vale la pena conoscerlo soprattutto perché spiega come mai un grande resolver pubblico riesca a restare veloce e disponibile a livello globale senza che tu debba scegliere un endpoint specifico per regione, come invece ti capita con un database cloud o con un'istanza di calcolo.

Il BGP è il meccanismo che sta sotto «più vicino in termini topologici»

«Più vicino per percorso di rete» non viene deciso da qualcosa che misura in tempo reale la distanza fisica. Ogni rete che annuncia un indirizzo anycast lo fa tramite BGP, il protocollo di routing che tiene insieme le singole reti di Internet, e ogni router lungo il tragitto sceglie il percorso verso quell'indirizzo che in quel momento gli appare più breve secondo le metriche del BGP stesso: di solito il minor numero di salti di rete, non il minor numero di chilometri. In pratica questo di solito coincide con la vicinanza fisica, ma non alla perfezione: una richiesta può talvolta essere instradata verso una sede un po' più lontana se quel percorso risulta più breve in termini BGP, in particolare in caso di interruzioni di rete o di accordi di peering insoliti.

Perché l'anycast non va bene per tutto

L'anycast si adatta perfettamente a scambi brevi e senza stato come una singola query e risposta DNS: non c'è nulla da perdere se un pacchetto successivo finisce instradato su un server fisico diverso dal primo. Non è adatto invece alle connessioni longeve e con stato: se il percorso di rete cambia a metà connessione (un route flap, una modifica di peering), una sessione TCP anycast verso un endpoint fisico diverso da quello che l'ha avviata semplicemente si interrompe, perché il nuovo server non sa nemmeno che quella connessione sia mai esistita. È una delle ragioni per cui l'anycast è così legato al DNS e ad altri protocolli basati su UDP e su richiesta-risposta, ed è molto meno usato per cose come una connessione a un database di lunga durata o uno stream video.