Ho cambiato il mio TTL da 24 ore a 5 minuti. Devo aspettare 24 ore prima di modificare i record?

37

Sto migrando la nostra app da un server cloud sul server dedicato Rackspace.

Voglio far scendere l'applicazione per circa 5 minuti per copiare i dati dal server cloud al server dedicato, quindi non voglio che le richieste vadano sul vecchio server dopo aver copiato i dati.

Voglio puntare il nostro record DNS sul nuovo server, ma il TTL è stato impostato su 24 ore. L'ho cambiato in 300 secondi. Devo attendere le 24 ore prima di aggiornare l'ip a cui punta il dominio / copiare i dati?

domain-name-system  rackspace  ttl 
— wobbily_col
fonte
9
A proposito, anche se aspetti il ​​TTL, ti consiglio vivamente di modificare la configurazione sul vecchio server per assicurarsi che non vengano accettati altri aggiornamenti. In realtà non tutti i resolver DNS seguono gli standard.
— Peter Green,
5
Quello che ho fatto quando ho spostato un'applicazione Web da un provider di hosting a un altro è stato utilizzare un port forwarding ssh per far sì che tutti i visitatori continuassero a utilizzare il vecchio IP diretto al nuovo server.
— Kasperd,

Risposte:

58

Chiunque abbia una copia cache del record di dominio non si preoccuperà di aggiornarlo per 24 ore, quindi sì, se il tuo intento è di avere al massimo una finestra di 5 minuti di indisponibilità, dovresti aspettare fino a quando tutte le cache in sospeso non si sono aggiornate per non vivere più di 5 minuti.

— Jeff Meden
fonte
23
... per 24 ore since they last cached it. Potrebbe essere compreso tra 1 e 86399 secondi.
— user9517 supporta GoFundMonica
6
@Iain Devi assumere il peggio, dal momento che uno o tutti loro potrebbero averlo memorizzato nella cache appena prima della modifica.
— Barmar,
6
@Barmar Non dare per scontato nulla. Molti ISP ignorano semplicemente il TTL.
— user9517 supporta GoFundMonica
13
@Iain lavoravo per Akamai, un CDN che fa un uso intensivo di TTL brevi (come 60 secondi) per il bilanciamento del carico. Ricordo che abbiamo fatto uno studio e scoperto che la maggior parte degli ISP obbediva ai nostri TTL.
— Barmar,
1
Lavoro per un'azienda di web hosting, la nostra esperienza è che i TTL bassi hanno più probabilità di essere ignorati che superiori.
— Henrik - smetti di ferire Monica
39

È (potenzialmente) anche peggio di così: devi aspettare 24 ore dopo l'aggiornamento di tutti i tuoi server autorevoli. Il modo normale in cui si verificano gli aggiornamenti è che si apporti una modifica alla zona sul server primario e quindi ciascuno dei secondari trasferisca i dati della nuova zona la volta successiva che accedono con il primario. La frequenza di check in è controllata dall'intervallo di aggiornamento nel record SOA della zona. Pertanto, nel peggiore dei casi dovresti attendere l'intervallo di aggiornamento della zona + il TTL del record.

Potrebbe anche essere necessario attendere così a lungo per le effettive modifiche al record. Un TTL di 5 minuti non farà molto bene se i secondari si aggiornano solo ogni 6 ore. Pertanto, probabilmente si desidera ridurre anche l'intervallo di aggiornamento sulla zona per il periodo in cui si desidera poter apportare modifiche rapide.

Intendiamoci, questo potrebbe non essere applicabile al tuo setup. Se hai un sistema che aggiorna tutti i server autorevoli insieme, questo non è un problema (e non ho familiarità con la configurazione DNS di Rackspace). Ma ti consiglio di interrogare tutti i tuoi server autorevoli singolarmente ( dig server.example.com @secondaryserver.example.com) per assicurarti che abbiano il nuovo TTL prima di iniziare il conto alla rovescia di 24 ore.

— Gordon Davisson
fonte
1
Questa dovrebbe essere la risposta accettata.
— dotancohen,
4
Sembra che tu stia ignorando il protocollo di notifica DNS, che dice ai server slave di aggiornarsi poco dopo l'aggiornamento del master. La maggior parte dei server DNS utilizza questa funzione.
— Barmar,
@Barmar: è vero, ma allo stesso tempo il master potrebbe impiegare un po 'di tempo per aggiornarsi a seconda del provider. (Ad esempio, alcuni provider ricostruiscono le zone dal database ogni 5 o 15 minuti, anche se quelli moderni lo fanno immediatamente.)
— Grawity
1
Il mio commento riguardava solo il problema dell'attesa dell'intervallo di aggiornamento, che è per lo più obsoleto in questi giorni. Attendere l'aggiornamento del master è vero, a meno che non si gestisca il proprio master. Ma penso sia improbabile che debbano affrontare l'ora esatta in cui tutto diventa sicuro per l'aggiornamento; 5-15 minuti in più non dovrebbero fare molta differenza. Il punto della domanda originale è se devono aspettare un giorno intero.
— Barmar,
1
@GordonDavisson: se non ti fidi, verifica. dig +nssearch example.comè uno strumento utile per confrontare rapidamente SOA su tutti i server; nsdiff mostra le differenze effettive.
— Grawity
23

Sì, dovresti aspettare. Anche allora, ovviamente, non è garantito che tutti rispettino il TTL.

— Sven
fonte
6
+1 per non tutti obbediscono al TTL, ho visto i ritardatari arrivare una settimana dopo aver apportato una modifica al DNS. Un modo in cui l'ho gestito in passato era impostare un nuovo nome univoco come alias sul nuovo sito e utilizzare un reindirizzamento dal vecchio sito per reindirizzare gli utenti dal vecchio dominio a quelli nuovi, come da www.mycompany .com -> newsite.mycompany.com
— Johnny
Sì, ma molte persone disprezzeranno giustamente l'idea di dover usare un nuovo nome. I nomi sono marchi. Inoltre, questo funziona solo per HTTP e praticamente per nient'altro.
— Sven
8
Un'altra opzione è quella di configurare il vecchio server come proxy inverso per il nuovo server. Puoi quindi lasciarlo attivo per circa una settimana dopo il passaggio e spegnerlo quando non c'è traffico che lo attraversa.
— bdsl,
1
Le persone con server DNS ben educati che obbediscono al TTL non vedranno mai il nuovo dominio. E mentre "solo" funziona con HTTP (S), penso che scoprirai che HTTP è un protocollo abbastanza comune su Internet. Il suggerimento di bdsl di impostare un proxy inverso è ancora meglio, ma richiede più lavoro
— Johnny,
@Johnny Il problema con un nuovo dominio è che corri il rischio che le persone aggiungano un segnalibro a quel dominio. A meno che tu non preveda di lasciare tale nuovo dominio accessibile per sempre.
— Bob,
5

Riunire vari commenti e risposte alla procedura completa sarebbe qualcosa di simile.

  1. Assicurati di poter aggiornare i tuoi server autorevoli in modo tempestivo.
  2. Ridurre il TTL.
  3. Controlla che tutti i server autorevoli abbiano il nuovo ttl.
  4. Attendere il vecchio TTL in modo che i valori memorizzati nella cache con il vecchio TTL vengano (principalmente) eliminati dalle cache (non è possibile garantire che se ne andranno da ogni cache perché alcune cache potrebbero ignorare gli standard).
  5. Metti il ​​sito sul vecchio server in modalità di sola lettura (o se non riesci a farlo sostituiscilo con una pagina "siamo in attesa di manutenzione").
  6. Eseguire la copia finale dal vecchio server al nuovo server (risultante in un sito di sola lettura sul nuovo server).
  7. Modifica i record DNS.
  8. Assicurarsi che tutti i server autorevoli dispongano dei nuovi record DNS.
  9. Attendi il nuovo ttl (puoi saltare questo passaggio se non ti interessa che alcuni utenti possano contribuire al sito e che altri utenti non vedano i risultati di tali contributi).
  10. Metti il ​​sito sul nuovo server in modalità lettura / scrittura.
  11. Nota sul vecchio server che si tratta di una copia di sola lettura obsoleta e che l'utente probabilmente ha rotto il DNS.
  12. Attendere qualche istante affinché i record vengano eliminati dalle cache DNS non conformi.
  13. Mettere fuori servizio il vecchio server.
— Peter Green
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.