J'ai changé ma durée de vie de 24 heures à 5 minutes. Dois-je attendre 24 heures avant de changer les enregistrements?

37

Je migre notre application depuis un serveur cloud chez Rackspace sur un serveur dédié.

Je souhaite interrompre l'application pendant environ 5 minutes pour copier les données du serveur cloud sur le serveur dédié. Par conséquent, je ne souhaite pas que les demandes soient envoyées à l'ancien serveur après avoir copié les données.

Je souhaite pointer notre enregistrement DNS sur le nouveau serveur, mais la durée de vie a été définie sur 24 heures. Je l'ai changé à 300 secondes. Dois-je attendre 24 heures avant de mettre à jour l'adresse IP vers laquelle le domaine pointe / copier les données?

domain-name-system rackspace ttl

— wobbily_col
source

9

BTW même si vous attendez le TTL, je vous recommande fortement de modifier la configuration sur l’ancien serveur pour vous assurer qu’aucune autre mise à jour ne sera acceptée. Tous les résolveurs DNS ne respectent pas les normes.

— Peter Green

5

Lorsque j'ai déplacé une application Web d'un fournisseur d'hébergement à un autre, j'ai utilisé une redirection de port ssh pour que tous les visiteurs utilisant encore l'ancienne adresse IP soient dirigés vers le nouveau serveur.

— Kasperd

58

Quiconque possède une copie en cache de l'enregistrement de domaine ne se mettra pas à jour avant 24 heures. Si vous souhaitez conserver une fenêtre d'indisponibilité d'au plus 5 minutes, vous devez attendre que tous les caches en attente aient été mis à jour pour ne plus vivre. que 5 minutes.

— Jeff Meden
source

23

... ça fait 24 heures since they last cached it. Cela pourrait être n'importe quoi de 1 à 86399 secondes.

— user9517 prend en charge GoFundMonica

6

@Iain Vous devez assumer le pire, car n'importe lequel d'entre eux aurait pu le mettre en cache juste avant le changement.

— Barmar

6

@Barmar Ne présumez rien. Beaucoup de fournisseurs d'accès ignorent tout simplement TTL.

— user9517 prend en charge GoFundMonica

13

@Iain J'avais l'habitude de travailler pour Akamai, un CDN qui fait un usage intensif de TTL courts (comme 60 secondes) pour l'équilibrage de charge. Je me souviens que nous avons effectué une étude et que nous avons constaté que la plupart des fournisseurs de services Internet respectaient nos TTL.

— Barmar

1

Je travaille pour une entreprise d’hébergement Web, notre expérience est qu’il est plus probable que les faibles TTL soient ignorés que plus élevés.

— Henrik - Cessez de faire mal à Monica

39

C'est (potentiellement) même pire que cela - vous devez attendre 24 heures après la mise à jour de tous vos serveurs faisant autorité. Pour que les mises à jour se produisent normalement, vous apportez une modification à la zone sur le serveur principal, puis chaque serveur secondaire transfère les nouvelles données de zone lors de son prochain enregistrement auprès du serveur principal. La fréquence d'enregistrement est contrôlée par l'intervalle d'actualisation dans l'enregistrement SOA de la zone. Ainsi, dans le pire des cas, vous devrez attendre l'intervalle d'actualisation de la zone + la durée de vie de l'enregistrement.

Vous devrez peut-être aussi attendre aussi longtemps pour que les changements d’enregistrement soient effectifs. Une durée de vie de 5 minutes ne sera pas très utile si les secondaires ne sont rafraîchis que toutes les 6 heures. Par conséquent, vous souhaiterez probablement diminuer l'intervalle d'actualisation de la zone pour la période pour laquelle vous souhaitez pouvoir effectuer des modifications rapides.

Remarquez, 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 suis pas familier avec la configuration DNS de Rackspace). Mais je vous recommande d’interroger individuellement chacun de vos serveurs faisant autorité ( 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.

— Gordon Davisson
source

1

Cela devrait être la réponse acceptée.

— dotancohen

4

Vous semblez ignorer le protocole de notification DNS, qui demande aux serveurs esclaves de se réactualiser peu de temps après la mise à jour du maître. La plupart des serveurs DNS utilisent cette fonctionnalité.

— Barmar

@Barmar: C'est vrai, mais dans le même temps, la mise à jour du maître peut prendre un certain temps, en fonction du fournisseur. (Par exemple, certains fournisseurs ne reconstruisent les zones de la base de données que toutes les 5 ou 15 minutes, bien que les modernes le fassent instantanément.)

— grawity

1

Mon commentaire ne traitait que de l'attente de l'intervalle de rafraîchissement, qui est pour la plupart obsolète de nos jours. Attendre que le maître soit mis à jour est vrai, sauf si vous utilisez votre propre maître. Mais je pense qu'il est peu probable qu'ils aient besoin de gérer l'heure exacte à laquelle tout devient sûr pour la mise à jour; 5-15 minutes supplémentaires ne devraient pas faire beaucoup de différence. La question initiale est de savoir s’ils doivent attendre une journée entière.

— Barmar

1

@GordonDavisson: Si vous ne faites pas confiance - vérifiez. dig +nssearch example.comest un outil utile pour comparer rapidement les SOA de tous les serveurs; nsdiff montre les différences réelles.

— Grawity

23

Oui, tu devrais attendre. Même dans ce cas, bien entendu, il n’est pas garanti que tout le monde respectera le TTL.

— Sven
source

6

+1 pour que tout le monde ne respecte pas le TTL, j'ai vu des retardataires arriver une semaine après avoir effectué un changement de DNS. Par le passé, j’ai géré ce problème en configurant un nouveau nom unique en tant qu’alias sur le nouveau site et en utilisant une redirection à partir de l’ancien site pour rediriger les utilisateurs de l’ancien domaine vers les nouveaux, tels que ceux de www.mycompany. .com -> newsite.mycompany.com

— Johnny

Oui, mais beaucoup de gens mépriseront à juste titre l’idée de devoir utiliser un nouveau nom. Les noms sont des marques. En outre, cela ne fonctionne que pour HTTP et pour à peu près rien d'autre.

— Sven

8

Une autre option consiste à configurer l'ancien serveur en tant que proxy inverse pour le nouveau serveur. Vous pouvez ensuite laisser cela environ une semaine après le commutateur et l'éteindre lorsqu'il n'y a pas de trafic.

— bdsl

1

Les personnes qui disposent de serveurs DNS qui se comportent bien et qui respectent la durée de vie ne verront jamais le nouveau domaine. Et bien que cela "ne" fonctionne qu'avec HTTP (S), je pense que vous constaterez que HTTP est un protocole assez courant sur Internet. bdsl suggère de mettre en place un proxy inverse, c'est encore mieux, mais c'est plus de travail

— Johnny

@Johnny Le problème avec un nouveau domaine, c'est que vous courez le risque que des personnes en fassent un bookmarking. Sauf si vous prévoyez de laisser ledit nouveau domaine accessible pour toujours.

— Bob

5

Réunir divers commentaires et réponses à l'ensemble de la procédure ressemblerait à quelque chose.

Assurez-vous de pouvoir mettre à jour vos serveurs d'authentification en temps utile.
Réduisez le TTL.
Vérifiez que tous les serveurs autorisés ont le nouveau ttl.
Attendez l'ancien TTL afin que les valeurs mises en cache avec l'ancien TTL soient (pour la plupart) éliminées des caches (vous ne pouvez pas garantir qu'elles disparaîtront de chaque cache car certaines caches pourraient ignorer les normes).
Mettez le site de l'ancien serveur en mode lecture seule (ou si vous ne pouvez pas le faire, remplacez-le par une page "Nous sommes en panne pour la maintenance").
Effectuez la copie finale de l'ancien serveur sur le nouveau serveur (pour créer un site en lecture seule sur le nouveau serveur).
Changer les enregistrements DNS.
Assurez-vous que tous les serveurs autorisés possèdent les nouveaux enregistrements DNS.
Attendez le nouveau texte (vous pouvez ignorer cette étape si certains utilisateurs ne peuvent pas 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 sur l'ancien serveur une notification indiquant qu'il s'agit d'une copie obsolète en lecture seule et que l'utilisateur a probablement un DNS endommagé.
Attendez un peu que les enregistrements soient supprimés des caches DNS non conformes.
Mettez le vieux serveur hors service.

— Peter Green
source

5

En plus des autres réponses, vous pouvez utiliser https://www.whatsmydns.net/ pour vérifier comment votre enregistrement DNS se propage en temps quasi réel.

— Madis Nome
source