In che modo 8.8.8.8 è tenuto * sempre * in vita?

So come è possibile gestire la ridondanza del datacenter se esiste un server DNS funzionante che può puntare a qualsiasi sito di lavoro della tua azienda - c'è VRRP, multi WAN ecc ecc. Ma come vengono mantenuti online i server DNS stessi? Viene colpito per la prima volta quando qualcuno si connette al servizio e non è possibile eseguirne il provisioning. Intendo per esempio 8.8.8.8o 8.8.4.4. Non ricordo che fossero a terra. Mai. In che modo gli ISP riescono a mantenere tali IP sempre online?

So che probabilmente è una domanda molto ampia, ma mi piacerebbe sentire solo nomi di protocolli / tecniche che possono essere utilizzati per questo. Posso leggere i dettagli su di loro da solo.

Innanzitutto, VRRP non dipende in alcun modo dal DNS. Per la ridondanza all'interno di un singolo sito è possibile eseguire i server DNS su un indirizzo VRRP condiviso bene.

Ma come altri hanno menzionato nei commenti, i servizi usano anche qualsiasi routing di routing , il che significa essenzialmente che lo stesso indirizzo IP esiste in più luoghi in tutto il mondo. Quando un intero sito si arresta, i percorsi in tutto il mondo vengono ricalcolati in modo che i pacchetti finiscano per andare in un altro sito di lavoro.

Un esempio migliore di DNS pubblico di Google sarebbe la radice server DNS - quelli che servono la .zona e tenere puntatori a com, org, eue così via - perché hanno una mappa di tutte le istanze dei 13 indirizzi logici. La "L" di ICANN è servita da 160 siti diversi!

Notare che anycast non ha nulla a che fare con i round robin basati su DNS (dove lo stesso nome ha più indirizzi). Anycast si basa essenzialmente sul protocollo di routing.

Internet utilizza BGP per scambiare informazioni di routing tra organizzazioni.

BGP supporta intrinsecamente la selezione del migliore tra diversi percorsi verso la stessa rete, sulla base di vari criteri. Ad esempio, lo stesso cliente potrebbe avere uplink ridondanti allo stesso ISP (annuncio di due percorsi che differiscono solo per peso / preferenza). Oppure il cliente potrebbe avere uplink attraverso diversi ISP e tutti selezioneranno il loro percorso preferito (principalmente AS-path più breve) - questo è il senso del "vero" multi-WAN.

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

Tuttavia, BGP conduce solo il traffico verso le porte d'ingresso, ma non importa cosa succede oltre. Pertanto, se imposti internamente entrambi i percorsi verso lo stesso server, otterrai il multihoming. Ma se ogni "ingresso" conduce a un server diverso (configurato per lo stesso IP), si ottiene anycast.

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

È importante sottolineare che questo significa anche che a BGP non importa se l'AS non è affatto contiguo. Per ottenere la ridondanza in tutto il mondo, basta annunciare la stessa rete da più posizioni fisiche - se si collegano tali posizioni insieme (in modo che instradino quella rete in un posto), si ottiene il multihoming; se sono isole, ottieni anycast.

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(Del resto, non deve nemmeno essere lo stesso AS - ad esempio i relè 6to4 sono gestiti da più organizzazioni indipendenti, ognuna delle quali annuncia il proprio percorso verso 192.88.99.0/24.)

Avvertenze:

• Anycast fornisce ridondanza, ma non bilanciamento del carico. Una volta che BGP converge, ciascun router avrà scelto un singolo percorso preferito (o occasionalmente alcuni) e continuerà ad usarlo fino a quando la rete non cambierà.

• Tuttavia, non è possibile prevedere per quanto tempo i percorsi rimarranno stabili, quindi qualsiasi servizio con stato può essere complicato. Il DNS se la cava perché è apolide e utilizza principalmente UDP (EDNS ha ridotto la necessità di connessioni TCP).

• È necessario un coordinamento tra il servizio effettivo e il router BGP, in modo che il percorso venga ritirato in caso di arresto anomalo del servizio.

Vedi anche "Storia del 4.2.2.2. Qual è la storia?" sulla mailing list di NANOG: post 1 , post 2 .

Un modo per ottenere ciò è utilizzare i bilanciatori lato server . Quando ti connetti al gateway su IP 8.8.8.8, distribuirà la richiesta a un server libero all'interno del sistema. Di conseguenza, quando un server muore, non distrugge l'intero sistema.

Per i servizi Internet, il bilanciamento del carico sul lato server è in genere un programma software in ascolto sulla porta in cui i client esterni si connettono ai servizi di accesso. Il bilanciamento del carico inoltra le richieste a uno dei server "back-end", che di solito risponde al bilanciamento del carico. Ciò consente al bilanciamento del carico di rispondere al client senza che il client sia mai a conoscenza della separazione interna delle funzioni. Inoltre, impedisce ai client di contattare direttamente i server back-end, il che può comportare vantaggi in termini di sicurezza nascondendo la struttura della rete interna e prevenendo attacchi allo stack di rete del kernel o servizi non correlati in esecuzione su altre porte.

Alcuni servizi di bilanciamento del carico forniscono un meccanismo per fare qualcosa di speciale nel caso in cui tutti i server back-end non siano disponibili. Ciò potrebbe includere l'inoltro a un bilanciamento del carico di backup o la visualizzazione di un messaggio relativo all'interruzione.

È anche importante che il bilanciamento del carico stesso non diventi un singolo punto di errore. Solitamente i servizi di bilanciamento del carico sono implementati in coppie ad alta disponibilità che possono anche replicare i dati di persistenza della sessione se richiesto dall'applicazione specifica. [5]