J'ai exécuté le basculement DNS RR sur un site Web de production à trafic modéré mais critique (sur deux sites géographiques) pendant de nombreuses années.
Cela fonctionne bien, mais il y a au moins trois subtilités que j'ai apprises à la dure.
1) Les navigateurs passeront d’une adresse IP inutilisée à une adresse IP opérationnelle après 30 secondes (la dernière fois que j’ai vérifiée) si les deux sont considérés comme actifs dans le DNS mis en cache disponible pour vos clients. C'est fondamentalement une bonne chose.
Mais attendre "la moitié" de vos utilisateurs attendre 30 secondes est inacceptable, vous voudrez probablement mettre à jour vos enregistrements TTL en quelques minutes, et non quelques jours ou semaines, afin qu'en cas de panne, vous puissiez rapidement supprimer le serveur hors service. de votre DNS. D'autres ont fait allusion à cela dans leurs réponses.
2) Si l'un de vos serveurs de noms (ou l'une de vos deux régions géographiques) tombe en panne et sert votre domaine round robin, et si le premier d'entre eux tombe en panne, je me souviens vaguement que vous pouvez rencontrer d'autres problèmes en essayant de le supprimer. Si vous n'avez pas défini votre durée de vie SOA / expiration pour le serveur de noms sur une valeur suffisamment basse, DNS est également en panne. Je pourrais avoir des détails techniques faux ici, mais il y a plus d'un paramètre TTL dont vous avez besoin pour bien vous défendre et vous défendre réellement contre les points de défaillance uniques.
3) Si vous publiez des API Web, des services REST, etc., ceux-ci ne sont généralement pas appelés par les navigateurs. Par conséquent, à mon avis, le basculement DNS commence à montrer de véritables failles. C'est peut-être pour cela que certains disent, comme vous dites, "ce n'est pas recommandé". Voici pourquoi je dis ça. Premièrement, les applications qui consomment ces URL ne sont généralement pas des navigateurs. Elles ne disposent donc pas des propriétés / logique de basculement de 30 secondes des navigateurs classiques. Deuxièmement, le fait que la deuxième entrée DNS soit appelée ou non, ou même que le DNS soit réinterrogé, dépend beaucoup des détails de programmation de bas niveau des bibliothèques réseau dans les langages de programmation utilisés par ces clients API / REST, ainsi que de la façon dont elles sont appelées par l'application cliente API / REST. (Sous leurs couvertures, la bibliothèque appelle-t-elle get_addr et quand? Si des sockets se ferment ou se ferment, l'application ouvre-t-elle de nouveaux sockets? Existe-t-il une sorte de logique de délai d'attente? Etc etc)
C'est bon marché, bien testé et "fonctionne principalement". Comme dans la plupart des cas, votre kilométrage peut varier.