Pourquoi le basculement DNS n'est-il pas recommandé ?

Par "basculement DNS", je suppose que vous voulez dire DNS Round Robin combiné à une certaine surveillance, c'est-à-dire la publication de plusieurs adresses IP pour un nom d'hôte DNS, et la suppression d'une adresse morte lorsque la surveillance détecte qu'un serveur est en panne. Cela peut être réalisable pour les petits sites Web à faible trafic.

Par conception, lorsque vous répondez à une demande DNS, vous fournissez également un temps de vie (TTL) pour la réponse que vous donnez. En d'autres termes, vous dites aux autres serveurs DNS et aux caches "vous pouvez stocker cette réponse et l'utiliser pendant x minutes avant de revenir me voir". Les inconvénients viennent de là :

• Avec le basculement DNS, un pourcentage inconnu de vos utilisateurs aura vos données DNS en cache avec des quantités variables de TTL restants. Jusqu'à ce que le TTL expire, ils peuvent se connecter au serveur mort. Il existe des moyens plus rapides de réaliser un basculement que cela.
• En raison de ce qui précède, vous êtes enclin à régler le TTL assez bas, disons 5-10 minutes. Mais une valeur plus élevée offre un avantage (très faible) en termes de performances et peut aider votre propagation DNS à fonctionner de manière fiable, même en cas de bref accroc dans le trafic réseau. L'utilisation du basculement basé sur le DNS va donc à l'encontre des TTL élevés, mais ces derniers font partie intégrante du DNS et peuvent être utiles.

Les méthodes les plus courantes pour obtenir un bon temps de fonctionnement sont les suivantes :

• Placer les serveurs ensemble sur le même réseau local.
• Placez le réseau local dans un centre de données avec une alimentation et des plans de réseau hautement disponibles.
• Utilisez un équilibreur de charge HTTP pour répartir la charge et basculer en cas de défaillance d'un serveur individuel.
• Obtenez le niveau de redondance et le temps de fonctionnement prévu dont vous avez besoin pour vos pare-feu, équilibreurs de charge et commutateurs.
• Mettez en place une stratégie de communication en cas de défaillance d'un centre de données complet et de la défaillance occasionnelle d'un commutateur, d'un serveur de base de données ou d'une autre ressource qui ne peut pas être facilement mise en miroir.

Une très petite minorité de sites web utilisent des configurations multi-datacentres, avec un "géo-équilibrage" entre les centres de données.

Le basculement DNS fonctionne très bien. Je l'utilise depuis de nombreuses années pour transférer manuellement le trafic entre les centres de données, ou automatiquement lorsque les systèmes de surveillance détectent des pannes, des problèmes de connectivité ou des serveurs surchargés. Quand vous voyez la vitesse à laquelle il fonctionne et les volumes de trafic réel qui peuvent être déplacés avec facilité, vous ne reviendrez jamais en arrière. J'utilise Zabbix pour surveiller tous mes systèmes et les graphiques visuels qui montrent ce qui se passe lors d'une situation de basculement DNS mettent fin à tous mes doutes. Il se peut que quelques FAI ignorent les TTL et que certains utilisateurs utilisent encore de vieux navigateurs, mais lorsque vous regardez le trafic de millions de pages vues par jour dans deux centres de données et que vous effectuez un transfert de trafic DNS, le trafic résiduel entrant qui ignore les TTL est risible. Le basculement DNS est une technique solide.

Le DNS n'a pas été conçu pour le basculement, mais il a été conçu avec des TTL qui fonctionnent étonnamment bien pour les besoins du basculement lorsqu'ils sont combinés à un système de surveillance solide. Les TTL peuvent être définis très courts. J'ai effectivement utilisé des TTL de 5 secondes en production pour des solutions de basculement DNS à la vitesse de l'éclair. Vous devez disposer de serveurs DNS capables de gérer la charge supplémentaire - et les serveurs nommés ne suffiront pas. Cependant, powerdns fait l'affaire lorsqu'il est soutenu par des bases de données mysql répliquées sur des serveurs de noms redondants. Vous avez également besoin d'un système de surveillance distribué solide auquel vous pouvez faire confiance pour l'intégration du basculement automatique. Zabbix fonctionne pour moi - je peux vérifier les pannes à partir de plusieurs systèmes Zabbix distribués presque instantanément - mettre à jour les enregistrements mysql utilisés par powerdns à la volée - et fournir un basculement presque instantané pendant les pannes et les pics de trafic.

Mais bon, j'ai créé une entreprise qui fournit des services de basculement DNS après avoir passé des années à les faire fonctionner pour de grandes entreprises. Prenez donc mon opinion avec un grain de sel. Si vous voulez voir des graphiques de trafic zabbix de sites à fort volume pendant une panne - pour voir par vous-même à quel point le basculement DNS fonctionne bien - envoyez-moi un e-mail et je serai ravi de le partager.

Le problème du basculement DNS est qu'il est, dans de nombreux cas, peu fiable. Certains fournisseurs d'accès ignorent vos TTL, le basculement ne se produit pas immédiatement même s'ils respectent vos TTL, et lorsque votre site est rétabli, cela peut entraîner des problèmes de sessions lorsque le cache DNS d'un utilisateur est saturé et qu'il se dirige vers l'autre serveur.

Malheureusement, c'est à peu près la seule option, à moins que vous ne soyez assez grand pour faire votre propre routage (externe).

L'opinion la plus répandue est qu'avec le DNS RR, lorsqu'une IP tombe en panne, certains clients continuent à utiliser l'IP cassée pendant des minutes. C'est ce qui a été dit dans certaines des réponses précédentes à la question et c'est également écrit sur Wikipedia.

De toute façon,

http://crypto.stanford.edu/dns/dns-rebinding.pdf explique que ce n'est pas vrai pour la plupart des navigateurs HTML actuels. Ils essaieront la prochaine IP dans quelques secondes.

http://www.tenereillo.com/GSLBPageOfShame.htm semble être encore plus forte :

L'utilisation de plusieurs enregistrements A n'est pas une astuce du métier, ni une fonctionnalité conçue par les vendeurs d'équipements d'équilibrage de charge. Le protocole DNS a été conçu pour prendre en charge les enregistrements A multiples pour cette raison précise. Des applications telles que les navigateurs, les proxies et les serveurs de messagerie utilisent cette partie du protocole DNS.

Peut-être qu'un expert peut commenter et donner une explication plus claire de la raison pour laquelle DNS RR n'est pas bon pour la haute disponibilité.

Merci,

Valentino

PS : désolé pour le lien cassé mais, en tant que nouvel utilisateur, je ne peux pas poster plus d'un lien.

J'ai géré le basculement DNS RR sur un site web de production modérément fréquenté mais critique pour l'entreprise (sur deux zones 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 basculeront d'une IP non fonctionnelle à une IP fonctionnelle après 30 secondes (la dernière fois que j'ai vérifié) si les deux sont considérées comme actives dans le DNS mis en cache disponible pour vos clients. C'est fondamentalement une bonne chose.

Mais le fait que "la moitié" de vos utilisateurs attendent 30 secondes est inacceptable. Vous voudrez donc probablement mettre à jour vos enregistrements TTL pour qu'ils soient de quelques minutes, et non de 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 à ce point dans leurs réponses.

2) Si l'un de vos serveurs de noms (ou l'une de vos deux géographies) qui dessert votre domaine round-robin tombe en panne, et si le principal d'entre eux tombe en panne, je me souviens vaguement que vous pouvez rencontrer d'autres problèmes en essayant de supprimer ce serveur de noms en panne du DNS si vous n'avez pas défini votre TTL/expiration SOA pour le serveur de noms à une valeur suffisamment basse également. Je peux me tromper dans les détails techniques, mais il n'y a pas qu'un seul paramètre TTL à prendre en compte pour vraiment se défendre 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, et donc, à mon avis, le basculement DNS commence à présenter de réelles failles. C'est peut-être la raison pour laquelle certains disent, comme vous le dites, "ce n'est pas recommandé". Voici pourquoi je dis cela. Tout d'abord, les applications qui consomment ces URL ne sont généralement pas des navigateurs, et ne disposent donc pas des propriétés/logiques de basculement en 30 secondes des navigateurs courants. Deuxièmement, le fait d'appeler ou non la deuxième entrée DNS ou même de relancer le DNS dépend beaucoup des détails de programmation de bas niveau des bibliothèques de mise en réseau dans les langages de programmation utilisés par ces clients API/REST, ainsi que de la manière exacte dont elles sont appelées par l'application cliente API/REST. (Sous la couverture, la bibliothèque appelle-t-elle get_addr, et quand ? Si les sockets se bloquent ou se ferment, l'application rouvre-t-elle de nouveaux sockets ? Y a-t-il une sorte de logique de temporisation ? etc etc)

C'est bon marché, bien testé, et ça marche en général. Donc, comme pour la plupart des choses, votre kilométrage peut varier.