Il DNS e il suo funzionamento sono forse accompagnati da più incomprensioni, leggende, superstizioni e mitologia come qualsiasi aspetto dell'IT.
Anche quelli di noi che sanno che stiamo essenzialmente mentendo (o almeno drasticamente semplificando) quando parliamo di "propagazione" dei cambiamenti tendono ancora a usare il termine per descrivere qualcosa che è - contemporaneamente - estremamente semplice e diretto ... ma difficile da spiegare ... e non ha nulla a che fare con la propagazione in sé , ma tutto a che fare con la memorizzazione nella cache e la memorizzazione nella cache negativa, entrambe le quali sono una componente essenziale di come funziona il sistema (e, probabilmente, di come evita il collasso totale sotto il suo stesso peso) - essenzialmente il rovescio, l'opposto dell'attuale "propagazione", non la spinta.
Nonostante tutte le preoccupazioni e il tormento a mano sui brevi TTL, tendono a lavorare il più delle volte, al punto che potrebbe essere nel tuo interesse semplicemente provarli. A $ {day_job}, quando i nostri siti migrano da una "vecchia" piattaforma a una "nuova" piattaforma, spesso significa che stanno migrando in modo tale da non condividere nulla nell'infrastruttura. Il mio primo passo in una tale migrazione è far cadere il TTL a 60 anni abbastanza in anticipo rispetto al taglio in modo che il vecchio TTL abbia multipli multipli di se stesso da esaurire, dandomi una ragionevole garanzia che questi RR transitori con TTL brevi "si propagheranno ". Quando sono pronto per il taglio, riconfiguro il vecchio bilanciamento¹ per bloccare il traffico sul nuovo sistema - su Internet - in modo tale che il bilanciamento non stia più bilanciando più sistemi interni, ma invece sia "
Quindi taglio il DNS e guardo il nuovo bilanciamento e il vecchio.
Sono sempre piacevolmente sorpreso dalla rapidità con cui avviene la transizione. I holdout sembrano essere quasi sempre ragni di ricerca e siti di "controllo dello stato" di terze parti che si agganciano inspiegabilmente ai vecchi record.
Ma c'è uno scenario che si interrompe in modo prevedibile: quando le finestre del browser di un utente rimangono aperte, tendono ad agganciarsi all'indirizzo già scoperto e spesso persiste fino a quando tutte le finestre del browser non vengono chiuse.
Ma nella narrazione precedente, trovi la soluzione al problema: un "bilanciamento del carico" - in particolare e più precisamente, un proxy inverso - può essere il sistema a cui punta il tuo record DNS esposto.
Il proxy inverso quindi inoltra la richiesta all'indirizzo IP di destinazione corretto, che risolve utilizzando un secondo nome host "fittizio" con un breve TTL, che punta al vero server back-end .³ Perché il proxy onora sempre il TTL DNS su quello dummy DNS entry, hai la certezza di una commutazione rapida e completa.
Il lato negativo è che potresti instradare il traffico attraverso un'infrastruttura aggiuntiva non necessaria o pagare di più per il trasporto attraverso più confini della rete, in modo ridondante.
Esistono servizi che offrono questo tipo di funzionalità su scala globale e quello con cui ho più familiarità è CloudFront. (Molto probabilmente, Cloudflare avrebbe esattamente lo stesso scopo, dato che il piccolo amo dei test che ho fatto indica che si comporta anche correttamente, e sono sicuro che ce ne sono altri.)
Sebbene commercializzato principalmente come CDN, CloudFront è al centro una rete globale di proxy inversi con la possibilità di memorizzare nella cache le risposte opzionalmente . Se i www.example.compunti verso CloudFront e CloudFront sono configurati per inoltrare queste richieste backend.example.come il record DNS per backend.example.comutilizza un breve TTL, allora CloudFront farà la cosa giusta, perché onora quel breve TTL. Quando il record di back-end cambia, il traffico migrerà tutti entro il tempo di esaurimento del TTL.
Il TTL sul record del lato frontale che punta a CloudFront e se i browser e i risolutori della cache lo onorano non è importante, perché le modifiche alla destinazione back-end non richiedono cambiamenti nel www.example.comrecord ... quindi l'idea che "Internet" ha, per quanto riguarda il target corretto per www.example.comè coerente, indipendentemente da dove si trovi il sistema di back-end.
Questo, per me, risolve completamente il problema sollevando il browser da qualsiasi necessità di "seguire" le modifiche all'IP del server di origine.
TL; dr: indirizza le richieste a un sistema che funge da proxy per il vero server Web, in modo che solo la configurazione del proxy debba accogliere la modifica dell'IP del server di origine, non il DNS rivolto verso il browser.
Si noti che CloudFront minimizza anche la latenza da parte della magia DNS che impone sul lato anteriore, il che si traduce nella www.example.comrisoluzione della posizione del bordo CloudFront più ottimale in base alla posizione del browser che esegue la query www.example.com, quindi vi sono minime possibilità che il traffico segua un percorso inutilmente tortuoso dal browser al bordo all'origine ... ma questa parte è trasparente e automatica e al di fuori dell'ambito della domanda.
E, naturalmente, la memorizzazione nella cache dei contenuti può anche essere utile riducendo il carico sul server di origine o sul trasporto: ho configurato siti Web su CloudFront in cui il server di origine si trovava su un circuito ADSL e l'ADSL è intrinsecamente vincolato per la larghezza di banda a monte. Il server di origine in cui CloudFront si connette per recuperare il contenuto non deve essere un server all'interno dell'ecosistema AWS.
¹ Parlo del bilanciatore come una singola entità quando in realtà ha più nodi. Quando il bilanciamento è un ELB, una macchina dietro il bilanciamento funge da server di app fittizio e fa il vero tornante al bilanciamento della nuova piattaforma, poiché ELB non può farlo da solo.
² L'unica conoscenza del nuovo bilanciatore sul vecchio è che deve fidarsi dell'X-Forwarded-For del vecchio bilanciatore e che non deve applicare alcuna tariffa basata su IP che limiti gli indirizzi di origine del vecchio bilanciatore.
³ Quando il proxy è uno o più server che controlli, hai la possibilità di saltare usando il DNS sul retro e semplicemente usando gli indirizzi IP nella configurazione del proxy, ma lo scenario ospitato / distribuito discusso successivamente ha bisogno di quel secondo strato di DNS .