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


D'après la lecture, il semble que le basculement DNS n'est pas recommandé simplement parce que DNS n'a pas été conçu pour cela. Mais si vous avez deux serveurs Web sur des sous-réseaux différents hébergeant un contenu redondant, quelles autres méthodes existe-t-il pour garantir que tout le trafic est acheminé vers le serveur en direct si l'un des serveurs tombe en panne?

Pour moi, il me semble que le basculement DNS est la seule option de basculement, mais le consensus est que ce n'est pas une bonne option. Pourtant, des services comme DNSmadeeasy.com le fournissent, il doit donc y avoir du mérite. Des commentaires?


166
2017-08-30 17:57


origine


Regardez ici pour une discussion actualisée sur le sujet. Le basculement est maintenant effectué automatiquement par les navigateurs modernes. - GetFree


Réponses:


Par 'basculement DNS', je suppose que vous entendez 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 inactive lorsque la surveillance détecte qu'un serveur est en panne. Cela peut fonctionner pour des sites Web de petite taille et moins soumis à la traite.

De par leur conception, lorsque vous répondez à une demande DNS, vous fournissez également une durée de vie (TTL) pour la réponse que vous distribuez. En d'autres termes, vous dites aux autres serveurs et caches DNS "vous pouvez stocker cette réponse et l'utiliser pendant x minutes avant de vérifier avec moi". Les inconvénients proviennent de ceci:

  • Avec le basculement DNS, un pourcentage inconnu de vos utilisateurs aura vos données DNS mises en cache avec des quantités variables de durée de vie restante. Jusqu'à l'expiration de la durée de vie, ceux-ci peuvent se connecter au serveur hors service. Il existe des moyens plus rapides pour effectuer le basculement que cela.
  • En raison de ce qui précède, vous êtes enclin à définir une durée de vie relativement basse, par exemple 5 à 10 minutes. Toutefois, 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 problème ponctuel dans le trafic réseau. Par conséquent, l'utilisation du basculement basé sur DNS va à l'encontre des valeurs de durée de vie élevées, mais les valeurs de durée de vie élevées font partie du DNS et peuvent être utiles.

Les méthodes les plus courantes pour obtenir une bonne disponibilité impliquent:

  • Placement des serveurs ensemble sur le même réseau local.
  • Placez le réseau local dans un centre de données avec des plans d'alimentation et de réseau hautement disponibles.
  • Utilisez un équilibreur de charge HTTP pour répartir la charge et basculer sur des défaillances de serveur individuelles.
  • Obtenez le niveau de redondance / la disponibilité attendue dont vous avez besoin pour vos pare-feu, équilibreurs de charge et commutateurs.
  • Ayez une stratégie de communication en place pour les pannes de centre de données complet et les pannes occasionnelles d'un commutateur / serveur de base de données / autre ressource qui ne peuvent pas être facilement mises en miroir.

Une très petite minorité de sites Web utilisent des configurations multi-centres de données, avec «équilibrage géographique» entre centres de données.


93
2017-08-30 18:39



Je pense qu'il essaie spécifiquement de gérer le basculement entre deux centres de données différents (notez les commentaires sur différents sous-réseaux). Le regroupement des serveurs / l'utilisation d'équilibreurs de charge / la redondance supplémentaire ne l'aideront pas (à part les centres de données redondants. Mais vous toujours besoin de dire à Internet d'aller à celui qui est encore en place). - Cian
Ajoutez anycast à la configuration multi-datacenter et celle-ci devient une preuve d'échec du datacenter. - petrus
entrée wikipedia sur anycast (en.wikipedia.org/wiki/Anycast) aborde cette question en relation avec la résilience du serveur racine DNS. - dunxd
Les attaques DDoS sont si courantes que des centres de données entiers peuvent maintenant être mis hors ligne (ce qui est arrivé à Linode London et à leurs autres centres de données en décembre 2015). Il est donc déconseillé d'utiliser le même fournisseur dans le même centre de données. Par conséquent, plusieurs centres de données avec différents fournisseurs constitueraient une bonne stratégie, ce qui nous ramène au basculement DNS à moins qu'il n'existe une meilleure alternative. - Laurence Cope
Pourquoi le basculement n'existe-t-il pas, car vous devez garder votre site actif lorsqu'un périphérique est en panne / défectueux? A quoi servira votre basculement quand il est dans le même réseau partageant les mêmes périphériques, par exemple. routeurs? - user2128576


Le basculement DNS fonctionne parfaitement. Je l'utilise depuis de nombreuses années pour transférer manuellement le trafic entre des 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. Lorsque vous voyez la vitesse à laquelle cela fonctionne et les volumes de trafic du monde réel qui peuvent être facilement déplacés, vous ne regarderez jamais en arrière. J'utilise Zabbix pour surveiller tous mes systèmes et les graphiques visuels qui montrent ce qui se passe pendant une situation de basculement DNS dissipent tous mes doutes. Il existe peut-être quelques FAI qui ignorent les TTL et certains utilisateurs utilisent encore d'anciens navigateurs, mais lorsque vous consultez du trafic provenant de millions de pages vues par jour sur deux centres de données, vous effectuez un transfert du trafic DNS - le trafic résiduel entrant qui ignore les TTL est risible. Le basculement DNS est une technique solide.

DNS n'a pas été conçu pour le basculement - mais il a été conçu avec des TTL qui fonctionnent à merveille pour les besoins de basculement lorsqu'ils sont combinés avec un système de surveillance solide. Les TTL peuvent être très courts. J'ai utilisé efficacement des TTL de 5 secondes en production pour alléger les solutions basées sur le basculement DNS rapide. Vous devez avoir des serveurs DNS capables de gérer la charge supplémentaire - et nommés ne vont pas la couper. Cependant, powerdns fait l'affaire quand il est sauvegardé avec une base de données répliquée mysql sur des serveurs de noms redondants. Vous avez également besoin d'un système de surveillance distribué solide sur lequel vous pouvez compter pour l'intégration du basculement automatisé. Zabbix fonctionne pour moi - je peux vérifier les pannes de plusieurs systèmes Zabbix distribués presque instantanément - mettre à jour les enregistrements mysql utilisés à la volée par powerdns - et fournir un basculement presque instantané pendant les pannes et les pics de trafic.

Mais bon, j’ai construit une entreprise qui fournit des services de basculement DNS après des années de travail pour les grandes entreprises. Alors, prenez mon opinion avec un grain de sel. Si vous voulez voir des graphiques de trafic zabbix de sites à volume élevé pendant une panne - pour voir par vous-même exactement comment fonctionne le basculement DNS - envoyez-moi un message, je serai ravi de le partager.


44
2017-10-20 17:17



La réponse de Cian serverfault.com/a/60562/87017 contredit directement votre un ..... alors qui a raison? - Pacerier
Je pense que les TTLs courts ne fonctionnent pas sur Internet. Vous utilisez peut-être des serveurs DNS qui respectent les RFC - mais il en existe beaucoup qui ne le font pas. N'assumez pas qu'il s'agit d'un argument contre Round Robin DNS - voir également la réponse de vmiazzo ci-dessous - j'ai exécuté des sites très sollicités à l'aide de RR DNS et je l'ai testé - cela fonctionne. Les seuls problèmes que j'ai rencontrés concernaient des clients Java (pas des navigateurs) qui n'essayaient même pas de se reconnecter en cas d'échec, ne parcouraient que la liste des hôtes sur un serveur RST. - symcbean
Je parie que les gens qui disent que le basculement DNS surveillé est génial et ceux qui disent que ça craint ont des expériences similaires, mais avec des attentes différentes. Le basculement DNS n’est PAS transparent, mais il évite les temps morts importants. Si vous avez besoin d'un accès totalement transparent (ne perdez jamais une seule requête, même en cas de panne de serveur), vous avez probablement besoin d'une architecture beaucoup plus sophistiquée - et plus chère. Ce n'est pas une exigence pour de nombreuses applications. - Tom Wilson


Le problème avec le basculement DNS est qu’il est, dans de nombreux cas, peu fiable. Certains fournisseurs de services Internet ignoreront votre durée de vie. Cela ne se produit pas immédiatement même s'ils respectent votre durée de vie. Lorsque votre site est réactualisé, cela peut créer des problèmes avec les sessions lorsque le cache DNS d'un utilisateur arrive à expiration. sur l'autre serveur.

Malheureusement, c'est pratiquement la seule option, à moins que vous ne soyez assez grand pour effectuer votre propre routage (externe).


31
2017-08-30 18:27



+1 lent et peu fiable - Chris S
Regarde aussi serverfault.com/q/315199/87017 - Pacerier


L’opinion qui prévaut est que, avec DNS RR, lorsqu’une adresse IP tombe en panne, certains clients continuent à utiliser l’adresse IP endommagée pendant quelques minutes. Cela a été dit dans certaines des réponses précédentes à la question et cela est également écrit sur Wikipedia.

En tous cas,

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

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

L'utilisation de plusieurs enregistrements A n'est pas une astuce du métier, ni une fonctionnalité conçue par les fournisseurs d'équipement d'équilibrage de charge. Le protocole DNS a été conçu avec la prise en charge de plusieurs enregistrements A pour cette raison même. Les applications telles que les navigateurs, les serveurs proxy et les serveurs de messagerie utilisent cette partie du protocole DNS.

Certains experts peuvent peut-être commenter et expliquer plus clairement pourquoi DNS RR n’est pas adapté à la haute disponibilité.

Merci,

Valentino

PS: désolé pour le lien brisé mais, en tant que nouvel utilisateur, je ne peux pas poster plus de 1


19
2017-09-29 10:06



Plusieurs enregistrements A sont conçus dans, mais pour un équilibrage de charge plutôt que pour un basculement. Les clients vont mettre en cache les résultats et continuer à utiliser le pool complet (y compris l'adresse IP endommagée) pendant quelques minutes après le changement de l'enregistrement. - Cian
Alors, est ce qui est écrit sur crypto.stanford.edu/dns/dns-rebinding.pdf chapitre 3.1 faux? << Internet Explorer 7 épingle les liaisons DNS pendant 30 minutes.1 Malheureusement, si le domaine de l'attaquant contient plusieurs enregistrements A et que le serveur actuel devient indisponible, le navigateur essaiera une adresse IP différente en une seconde. >> - Valentino Miazzo
J'ai déplacé ma sous-question ici serverfault.com/questions/69870/… - Valentino Miazzo


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 basculeront d’une adresse IP non opérationnelle à 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) qui dessert votre domaine round robin tombe en panne, 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. serveur de noms abaissé à partir du DNS si vous n'avez pas non plus défini votre durée de vie SOA TTL / expiration pour le serveur de noms sur une valeur suffisamment basse. 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 courants. Deuxièmement, que la seconde entrée DNS soit appelée ou non, ou même que le DNS soit réinterrogé, dépend largement 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.


11
2018-04-12 01:21



une bibliothèque qui ne réessaie pas sur les autres RR pour une adresse est cassée. pointez les développeurs vers les pages de manuel de getaddrinfo (), etc. - Jasen


Il y a beaucoup de gens qui nous utilisent (Dyn) pour le basculement. C'est la même raison pour laquelle les sites peuvent créer une page de statut lorsqu'ils ont un temps mort (pensez à Fail Whale, par exemple, sur Twitter) ... ou simplement rediriger le trafic en fonction des TTL. Certaines personnes peuvent penser que DNS Failover est un ghetto ... mais nous avons sérieusement conçu notre réseau avec le basculement depuis le début ... afin qu'il fonctionne aussi bien que le matériel. Je ne sais pas comment DME le fait, mais 3 de nos 17 points de présence les plus proches diffusés sur 17 surveillent votre serveur depuis l'emplacement le plus proche. Lorsqu'il détecte une panne sur deux des trois, nous redirigeons simplement le trafic sur l'autre IP. Le seul temps d'arrêt concerne ceux qui étaient à la demande du reste de cet intervalle TTL.

Certaines personnes aiment utiliser les deux serveurs à la fois ... et dans ce cas, peuvent effectuer un équilibrage de la charge à tour de rôle ... ou un équilibrage de la charge basé sur la géo. Pour ceux qui s'intéressent réellement aux performances ... notre gestionnaire de trafic en temps réel surveillera chaque serveur ... et si l'un est plus lent ... redirigez le trafic sur le plus rapide en fonction des adresses IP que vous associez à vos noms d'hôte. Encore une fois ... cela fonctionne sur la base des valeurs que vous avez mises en place dans notre interface utilisateur / API / portail.

Je suppose que ce que je veux dire, c’est… Nous avons conçu le basculement DNS exprès. Bien que le DNS n’ait pas été conçu pour le basculement lorsqu’il a été créé à l'origine, notre réseau DNS a été conçu pour l'implémenter dès le départ. Il peut généralement être aussi efficace que le matériel .. sans amortissement ni coût du matériel. J'espère que cela ne me fera pas sembler boiteux d'avoir branché Dyn ... il y a beaucoup d'autres entreprises qui le font ... je parle juste du point de vue de notre équipe. J'espère que cela t'aides...


9
2018-05-25 19:38



Que voulez-vous dire par "peut être aussi efficace que du matériel"? Quel type de matériel le routage DNS est-il utilisé? - mpen
@ Ryan, que veux-tu dire par "ghetto"? - Pacerier
Pour ce mot dictionnaire urbain ne donne pas de définitions à connotation positive, je suppose que "la solution du mendiant" pourrait être une traduction appropriée. - Jasen


Une autre option consisterait à configurer le serveur de noms 1 à l’emplacement A et le serveur de noms 2 à l’emplacement B, mais de configurer chacun d’entre eux de manière à ce que tous les enregistrements A sur le trafic de points NS1 vers les adresses IP de l’emplacement A et sur NS2 tous les enregistrements A pointent sur les adresses IP de emplacement B. Définissez ensuite vos TTL pour un nombre très bas et assurez-vous que votre enregistrement de domaine chez le registraire a été configuré pour NS1 et NS2. De cette façon, la charge sera automatiquement équilibrée et basculera en cas de panne d’un serveur ou d’un lien vers un emplacement.

J'ai utilisé cette approche d'une manière légèrement différente. J'ai un emplacement avec deux fournisseurs de services Internet et utilise cette méthode pour diriger le trafic sur chaque lien. Maintenant, il s’agit peut-être d’un peu plus de maintenance que vous ne le souhaitez ... mais j’ai pu créer un simple logiciel extrayant automatiquement les enregistrements NS1, mettant à jour les adresses IP des enregistrements pour certaines zones et les poussant vers NS2.


5
2017-08-07 05:13



Les serveurs de noms ne prennent-ils pas trop pour se propager? Si vous modifiez un enregistrement DNS avec une valeur TTL faible, cela fonctionnera instantanément, mais lorsque vous changerez de serveur de noms, il faudra 24 heures ou plus pour se propager. Par conséquent, je ne vois pas en quoi cela pourrait être une solution de basculement. - Marco Demaio