Questa è una domanda canonica sulla propagazione DNS
Quanto tempo richiede la propagazione dei vari tipi di record?
Alcuni si propagano più velocemente di altri?
Perché la propagazione dei record DNS richiede tempo e come funziona?
Questa è una domanda canonica sulla propagazione DNS
Quanto tempo richiede la propagazione dei vari tipi di record?
Alcuni si propagano più velocemente di altri?
Perché la propagazione dei record DNS richiede tempo e come funziona?
Risposte:
La "propagazione DNS" non è di per sé un fenomeno reale. Piuttosto, è l'effetto manifest della funzionalità di memorizzazione nella cache specificata nel protocollo DNS. Dire che i cambiamenti "si propagano" tra i server DNS è una falsità conveniente che, probabilmente, è più facile da spiegare agli utenti non tecnici piuttosto che descrivere tutti i dettagli del protocollo DNS. Tuttavia, non è proprio come funziona il protocollo.
I server DNS ricorsivi eseguono query per conto dei client. I server DNS ricorsivi, generalmente gestiti da ISP o dipartimenti IT, vengono utilizzati dai computer client per risolvere i nomi delle risorse Internet. I server DNS ricorsivi memorizzano nella cache i risultati delle query effettuate per migliorare l'efficienza. È possibile rispondere alle query per le informazioni già memorizzate nella cache senza effettuare ulteriori query. La durata, in secondi, in cui un risultato viene memorizzato nella cache dovrebbe essere basata su un valore configurabile chiamato Time To Live (TTL). Questo valore è specificato dal server DNS autorevole per il record richiesto.
Non esiste una risposta a tutte le domande poste perché il DNS è un protocollo distribuito. Il comportamento del DNS dipende dalla configurazione del server DNS autorevole per un determinato record, dalla configurazione dei server DNS ricorsivi che effettuano query per conto dei computer client e dalla funzionalità di cache DNS integrata nei sistemi operativi dei computer client.
È buona norma specificare un valore TTL abbastanza breve da contenere le necessarie modifiche giornaliere ai record DNS, ma abbastanza da creare una "vincita" nella memorizzazione nella cache (ovvero non così breve da esaurire la cache troppo rapidamente per fornire un miglioramento dell'efficienza). L'utilizzo di una strategia equilibrata con valori TTL si traduce in una "vittoria" per tutti. Riduce sia il carico che l'utilizzo della larghezza di banda per i server DNS autorevoli per un determinato dominio, i server root e i server TLD. Riduce l'utilizzo della larghezza di banda upstream per l'operatore del server DNS ricorsivo. Risulta in risposte di query più veloci per i computer client.
Poiché il TTL di un record DNS è impostato, il carico inferiore e l'utilizzo della larghezza di banda sui server DNS autorevoli aumenteranno perché i server DNS ricorsivi non saranno in grado di memorizzare nella cache il risultato per un lungo periodo. Poiché il TTL di un record è più elevato, le modifiche ai record non sembrano "avere effetto" rapidamente poiché i computer client continueranno a ricevere i risultati memorizzati nella cache archiviati nei loro server DNS ricorsivi. L'impostazione del TTL ottimale si riduce a un atto di bilanciamento tra utilizzo e capacità di modificare rapidamente i record e vedere tali cambiamenti riflessi sui clienti.
Vale la pena notare che alcuni ISP sono offensivi e ignorano i valori TTL specificati dai server DNS autorevoli (sostituendo il proprio override amministrativo, che costituisce una violazione di RFC). Non c'è nulla da fare al riguardo, dal punto di vista tecnico. Se gli operatori di server DNS abusivi possono trovare lamentele nei confronti dei loro amministratori di sistema, ciò potrebbe comportare l'implementazione delle migliori pratiche (probabilmente ciò che equivale al buon senso per qualsiasi ingegnere di rete che abbia familiarità con DNS). Questo particolare tipo di abuso non è un problema tecnico.
Se tutti "rispettano le regole" le modifiche ai record DNS possono "avere effetto" molto rapidamente. Nel caso di modifica dell'indirizzo IP assegnato a un record "A", ad esempio, verrebbe eseguito un backoff esponenziale del valore TTL, fino al momento in cui verrà effettuata la modifica. Il TTL potrebbe iniziare ad 1 giorno, ad esempio, e diminuire a 12 ore per un periodo di 24 ore, quindi a 6 ore per un periodo di 12 ore, 3 ore per un periodo di 6 ore, ecc., Fino a un intervallo adeguatamente piccolo. Una volta eseguito il backup del TTL, è possibile modificare il record e riportare il TTL al valore desiderato per le operazioni quotidiane. (Non è necessario utilizzare un backoff esponenziale, tuttavia questa strategia riduce al minimo il tempo in cui il record avrà un TTL basso e riduce il carico sul server DNS autorevole.)
Dopo aver effettuato un record DNS, i registri delle modifiche devono essere monitorati per tentativi di accesso effettuati a seguito del vecchio record DNS. Nell'esempio di modifica di un record "A" per fare riferimento a un nuovo indirizzo IP, un server dovrebbe rimanere presente al vecchio indirizzo IP per gestire i tentativi di accesso risultanti da computer client che utilizzano ancora il vecchio record "A". Una volta che i tentativi di accesso basati sul vecchio record hanno raggiunto un livello accettabilmente basso, è possibile disattivare il vecchio indirizzo IP. Se le richieste relative a un vecchio record non si riducono rapidamente, è possibile che (come descritto sopra) un server DNS ricorsivo stia ignorando l'autorevole TTL. Conoscere l'indirizzo IP di origine di un tentativo di accesso, tuttavia, non fornisce informazioni dirette sul server DNS ricorsivo responsabile della fornitura di un vecchio record.
Personalmente, ho visto i cambiamenti "avere effetto" immediatamente, in poche ore e in alcuni casi con un particolare ISP danneggiato dal cervello, dopo diversi giorni. Fare un backoff del tuo TTL ed essere consapevole di come funziona il processo aumenterà le tue modifiche per il successo, ma non puoi mai essere sicuro di ciò che un idiota ben intenzionato potrebbe fare con i loro server DNS ricorsivi.
1.1.1.1
o 8.8.8.8
o 9.9.9.9
o 80.80.80.80
. È importante capire che sono trasmessi: la risposta potrebbe cambiare in base all'IP di origine perché colpirà potenzialmente un'istanza fisica completamente diversa E la cache che hanno potrebbe essere globale in tutte le istanze o meno.