J'ai changé mon TTL de 24 heures à 5 minutes. Dois-je attendre 24 heures avant de modifier les enregistrements?
Je migre notre application depuis un serveur cloud chez Rackspace vers un serveur dédié.
Je veux arrêter l'application pendant environ 5 minutes pour copier les données du serveur cloud vers le serveur dédié, donc je ne veux pas que les demandes soient envoyées à l'ancien serveur après avoir copié les données.
Je veux pointer notre enregistrement DNS vers le nouveau serveur, mais le TTL a été défini sur 24 heures. Je l'ai changé à 300 secondes. Dois-je attendre 24 heures avant de mettre à jour l'ip ce domaine pointe/copie les données?
Quiconque possède une copie en cache de l'enregistrement de domaine ne prendra pas la peine de le mettre à jour pendant 24 heures, donc oui si votre intention est d'avoir au plus une fenêtre d'indisponibilité de 5 minutes, vous devez attendre que tous les caches en suspens soient mis à jour pour ne plus vivre. de 5 minutes.
C'est (potentiellement) encore pire que cela - vous devez attendre 24 heures après la mise à jour de tous de vos serveurs faisant autorité. La manière normale pour que les mises à jour se produisent est que vous apportiez une modification à la zone sur le serveur principal, puis que chacun des secondaires transfère les nouvelles données de zone la prochaine fois qu'ils se connectent avec le principal. La fréquence d'enregistrement est contrôlée par l'intervalle de rafraîchissement dans l'enregistrement SOA de la zone. Ainsi, dans le pire des cas, vous devrez attendre l'intervalle de rafraîchissement de la zone + le TTL de l'enregistrement.
Vous devrez peut-être aussi attendre aussi longtemps les modifications d'enregistrement réelles. Un délai de 5 minutes TTL ne fera pas beaucoup de bien si les secondaires ne se rafraîchissent que toutes les 6 heures. Donc, vous voudrez probablement réduire également l'intervalle de rafraîchissement sur la zone pour la période que vous voulez pour pouvoir effectuer des changements rapides.
Attention, cela peut ne pas s'appliquer à votre configuration. Si vous avez un système qui met à jour tous les serveurs faisant autorité ensemble, ce n'est pas un problème (et je ne connais pas la configuration DNS de Rackspace). Mais je recommanderais d'interroger tous de vos serveurs faisant autorité individuellement (Dig server.example.com @secondaryserver.example.com) pour vous assurer qu'ils disposent du nouveau TTL avant de commencer votre compte à rebours de 24 heures.
Oui, tu devrais attendre. Même alors, bien sûr, il n'est pas garanti que tout le monde respectera le TTL.
En plus des autres réponses, vous pouvez utiliser https://www.whatsmydns.net/ pour vérifier comment votre enregistrement DNS se propage en presque temps réel. 
En rassemblant divers commentaires et réponses, la procédure complète ressemblerait à quelque chose.
- Assurez-vous que vous pouvez mettre à jour vos serveurs faisant autorité en temps opportun.
- Réduisez le TTL.
- Vérifiez que tous les serveurs autorisés disposent du nouveau ttl.
- Attendez l'ancien TTL pour que les valeurs mises en cache avec l'ancien TTL soient (principalement) éliminées des caches (vous ne pouvez pas garantir qu'elles seront supprimées de chaque cache) car certains caches peuvent ignorer les normes).
- Mettez le site sur l'ancien serveur en mode lecture seule (ou si vous ne pouvez pas le faire, remplacez-le par une page "nous sommes en maintenance").
- Effectuez la copie finale de l'ancien serveur vers le nouveau serveur (résultant en un site en lecture seule sur le nouveau serveur).
- Modifiez les enregistrements DNS.
- Assurez-vous que tous les serveurs faisant autorité disposent des nouveaux enregistrements DNS.
- Attendez le nouveau ttl (vous pouvez ignorer cette étape si vous ne vous souciez pas que certains utilisateurs puissent contribuer au site et que d'autres utilisateurs ne voient pas les résultats de ces contributions).
- Mettez le site sur le nouveau serveur en mode lecture/écriture.
- Mettez un avis sur l'ancien serveur qu'il s'agit d'une copie en lecture seule obsolète et que l'utilisateur a probablement cassé le DNS.
- Attendez un moment que les enregistrements quittent les caches DNS non conformes.
- Mettez hors service l'ancien serveur.