DNS Round Robin: i browser si attengono a un solo IP purché sia ​​online?

Come si comportano la maggior parte dei browser se ottengono più record A dal server DNS? Attenersi a un IP purché sia ​​raggiungibile (e utilizzarne un altro solo se l'IP è inattivo)? O cambiano continuamente senza motivo?

Se i browser più diffusi si attengono a un solo IP, DNS-RR sarebbe sufficiente per me come semplice soluzione di failover.

Ogni browser ha il proprio metodo di gestione del DNS round robin, ho passato un po 'di tempo oggi a ricercare questo problema e continuerò ad aggiornare la mia risposta quando trovo la prova dell'implementazione che limiterà le mie risposte ai browser che espongono il loro comportamento.

Google Chrome

Google Chrome (utilizzato v58) richiederà tutte le voci host per un indirizzo (A, AAAA, CNAME) e le inserirà in un array ( address_list ). Chrome tenterà quindi di aprire un socket su ciascun indirizzo IP in ordine dal primo all'ultimo, Chrome non tenterà l'IP più veloce o più vicino, presuppone che il primo IP (fornito dai resolver DNS upstream) sia l'IP migliore. Nei miei test i server bind e windows dns danno un diverso ordine di IP per ricerca, dando a ogni IP ciò che sembra diviso in larghezza di banda 50/50. Questa funzionalità è esposta inchrome://net-internals/#events&q=type:SOCKET%20is:active

Curl (libcurl / 7.54.0)

Anche Curl ha questa funzione di failover, ma --connect-timeoutè molto più lunga di quella predefinita in Chrome, Chrome fallisce immediatamente, Curl no. Se usi libcurl e vuoi sopravvivere a un'istanza DNS round robin in cui un IP fallisce, (funziona in Chrome ma non nel codice) assicurati di specificare questo valore in basso.

DEFAULT_CONNECT_TIMEOUT: 0 mi ha fatto pensare che questo non fosse possibile con il ricciolo.

* After 149990ms connect time, move on!

Su entrambi i browser , l'IP non era appiccicoso , seguivano il TTL indicato in DNS e una volta scaduto il ttl (Chrome lo mantiene internamente, il ricciolo chiede su ogni richiesta), la selezione dell'ip viene eseguita ogni volta come descritto sopra.

Cosa significa questo? DNS-RR è ok per alcuni sistemi, ma non è progettato per il failover. Dovresti aspettarti che tutti i risultati del DNS siano (una fonte di verità) validi e disponibili per servire il traffico. Esistono molti modi per garantire la disponibilità dell'IP, come IP float virtuali, trucchi BGP / Routing, ecc . Usali .

Tutti i test eseguiti in ambiente solo IPv4, verranno restituiti con risultati dual-stack quando sarà disponibile un'infrastruttura sufficiente per il test.

Immagino che queste modifiche siano un effetto collaterale degli Happy Eyeballs RFC IPv6-Fallback

Aggiornamento Una considerazione utile, RR DNS può solo aiutare con il bilanciamento del carico, non i guasti delle applicazioni, se uno dei tuoi nodi ha un 503, servirai il 40-60% se il tuo traffico è 503. Si presume che tutti gli IP elencati siano endpoint di lavoro validi se raggiungibili

modifica: Modifica la mia risposta da quando HiPerFreak mi ha istruito.

I server DNS restituiranno un elenco di tutti i record A che ha per un determinato nome host. Il round robin entra nel fatto che ruota come viene ordinato l'elenco. Il link che è stato pubblicato è un ottimo esempio di come i browser web useranno tale elenco.

Round Robinning può essere utilizzato per una forma molto primitiva di bilanciamento del carico, ma è un sostituto molto scarso per il bilanciamento del carico reale, poiché se uno degli host nella rotazione round robin diminuisce, il server DNS non sarà il più saggio e continuerà a essere inserire l'indirizzo IP del nodo scaricato nell'elenco.

Vedi questa mia domanda (e risposta): come i browser gestiscono più IP .

In breve, Round Robin DNS non migliora affatto la disponibilità. Il browser sceglie un IP e si attiene ad esso, anche se non risponde. (Controllato con FF e cromo).

Una volta scaduta la cache DNS del browser, il nome host si è risolto di nuovo e il processo si è ripetuto, indipendentemente dalla risposta dell'IP o meno.

Per l'HA di base, è possibile utilizzare DNS dinamico o vari approcci basati su IP.

EDIT: questo comportamento si verifica quando l'host inaccessibile funge da "buco nero". Se invece l'host rifiuta in modo attivo le connessioni in entrata, il browser proverà un IP, si rifiuterà e utilizzerà immediatamente un altro IP e quindi fallirà abbastanza bene.

Cambiano gli IP, non è una soluzione di failover.

I browser consentono al sistema operativo di eseguire la risoluzione dei nomi e, per esempio, Linux randomizza sempre gli indirizzi IP, provare più volte l' host google.com . Gli IP arriveranno in ordine casuale.

Il DNS restituisce tutti gli IP in un elenco ma cambiano l'ordine dell'elenco e questo ordine non è casuale o cambia quando 1 fallisce ma restituiscono sempre gli IP nella stessa sequenza per motivi di bilanciamento del carico. Quando il browser riceve l'elenco, suppongo che scelga il primo nell'elenco se non noto come non funzionante.