Le DNS et son fonctionnement s'accompagnent peut-être de plus de malentendus, de légendes, de superstitions et de mythologies que n'importe quel aspect de l'informatique.
Même ceux d'entre nous qui savent que nous mentons essentiellement (ou du moins drastiquement simplifient à l'extrême) lorsque nous parlons de «propagation» des changements ont encore tendance à utiliser le terme pour décrire quelque chose qui est - simultanément - extrêmement simple et direct ... pourtant difficile à expliquer ... et n'a rien à voir avec la propagation en soi , mais tout à voir avec la mise en cache et la mise en cache négative, qui sont toutes deux un élément essentiel du fonctionnement du système (et, sans doute, de la façon dont il évite l'effondrement pur et simple sous son propre poids) - essentiellement le sens intérieur-opposé de la «propagation» réelle - pas la poussée.
Pour tous les inquiétants et les tordus à la main sur les TTL courts, ils ont tendance à fonctionner plus souvent qu'autrement, au point qu'il peut être dans votre intérêt de simplement les essayer. À $ {day_job}, lorsque nos sites migrent d'une "ancienne" plate-forme vers une "nouvelle" plate-forme, cela signifie souvent qu'ils migrent de telle manière que rien dans l'infrastructure n'est partagé. Ma première étape dans une telle migration consiste à laisser tomber le TTL à 60 ans suffisamment avant la coupe pour que l'ancien TTL ait plusieurs multiples de lui-même à courir, me donnant une assurance raisonnable que ces RR de transition avec des TTL courts "se propageront" . " Lorsque je suis prêt pour la coupe, je reconfigure l'ancien équilibreur¹ pour épingler le trafic vers le nouveau système - sur Internet - de telle sorte que l'équilibreur n'équilibre plus plusieurs systèmes internes, mais plutôt "
Ensuite, je coupe le DNS et regarde le nouvel équilibreur et l'ancien.
Je suis toujours agréablement surpris de la rapidité avec laquelle la transition se produit. Les récalcitrants semblent presque toujours être des araignées de recherche et des sites tiers de «vérification de la santé» qui s'accrochent inexplicablement aux anciens enregistrements.
Mais il y a un scénario qui tombe en panne de façon prévisible: lorsque les fenêtres du navigateur d'un utilisateur restent ouvertes, elles ont tendance à se verrouiller sur l'adresse déjà découverte, et elle persiste souvent jusqu'à ce que toutes les fenêtres de leur navigateur soient fermées.
Mais dans le récit ci-dessus, vous trouvez la solution au problème: un «équilibreur de charge» - spécifiquement et plus précisément, un proxy inverse - peut être le système vers lequel pointe votre enregistrement DNS exposé.
Le proxy inverse transmet ensuite la demande à l'adresse IP cible correcte, qu'il résout en utilisant un deuxième nom d'hôte "factice" avec un court TTL, qui pointe vers le vrai serveur principal.³ Parce que le proxy honore toujours le DNS TTL sur ce entrée DNS factice, vous êtes assuré d'un basculement rapide et complet.
L'inconvénient est que vous pouvez acheminer le trafic via une infrastructure supplémentaire inutile, ou payer plus cher pour le transport à travers plusieurs frontières du réseau, de manière redondante.
Il existe des services qui offrent ce type de capacité à l'échelle mondiale, et celui que je connais le plus est CloudFront. (Très probablement, Cloudflare servirait exactement le même objectif, car la petite incertitude des tests que j'ai effectués indique qu'il se comporte également correctement, et je suis sûr qu'il y en a d'autres.)
Bien qu'il soit principalement commercialisé en tant que CDN, CloudFront est à la base un réseau mondial de proxys inverses avec la possibilité de mettre en cache les réponses en option . Si des www.example.compoints sur CloudFront et CloudFront sont configurés pour transmettre ces demandes à backend.example.com, et que l'enregistrement DNS backend.example.comutilise un court TTL, alors CloudFront fera ce qu'il faut, car il respecte ce court TTL. Lorsque l'enregistrement principal change, le trafic migre tous au moment où le TTL s'épuise.
Le TTL sur l'enregistrement frontal pointant vers CloudFront, et si les navigateurs et les résolveurs de mise en cache le respectent est sans importance, car les modifications apportées à la destination principale ne nécessitent pas de modifications dans l' www.example.comenregistrement ... donc l'idée que "Internet" a, en ce qui concerne l'objectif correct pour www.example.comest cohérent, indépendamment de l'endroit où se trouve le système dorsal.
Pour moi, cela résout complètement le problème en libérant le navigateur de tout besoin de "suivre" les modifications de l'adresse IP du serveur d'origine.
tl; dr: acheminez les demandes vers un système qui sert de proxy pour le serveur Web réel, de sorte que seule la configuration du proxy doit prendre en compte le changement d'adresse IP du serveur d'origine - pas le DNS orienté navigateur.
Notez que CloudFront minimise également la latence grâce à la magie DNS qu'il impose sur la face avant, ce qui se traduit par la www.example.comrésolution de l'emplacement périphérique CloudFront le plus optimal en fonction de l'emplacement du navigateur qui interroge www.example.com, il y a donc peu de chances que le trafic emprunte un itinéraire inutilement détourné du navigateur au bord à l'origine ... mais cette partie est transparente et automatique et sort du cadre de la question.
Et, bien sûr, la mise en cache de contenu peut également être utile en réduisant la charge sur le serveur d'origine ou le transport - J'ai configuré des sites Web sur CloudFront où le serveur d'origine était sur un circuit ADSL, et l'ADSL est intrinsèquement contraint pour la bande passante en amont. Le serveur d'origine auquel CloudFront se connecte pour récupérer le contenu n'a pas besoin d'être un serveur à l'intérieur de l'écosystème AWS.
¹ Je parle d'équilibreur comme d'une entité unique alors qu'en fait il a plusieurs nœuds. Lorsque l'équilibreur est un ELB, une machine derrière l'équilibreur agit comme un serveur d'application factice et effectue l'épingle à cheveux réelle de l'équilibreur de la nouvelle plate-forme, car ELB ne peut pas le faire seul.
² La seule connaissance du nouvel équilibreur sur l'ancien est qu'il doit faire confiance au X-Forwarded-For de l'ancien équilibreur et qu'il ne doit pas limiter le débit basé sur IP sur les adresses source de l'ancien équilibreur.
³ Lorsque le proxy est un ou plusieurs serveurs que vous contrôlez, vous avez la possibilité de sauter à l'aide de DNS sur le côté arrière et simplement d'utiliser des adresses IP dans la configuration du proxy, mais le scénario hébergé / distribué discuté par la suite a besoin de cette deuxième couche de DNS .