Comment configurer le DNS primaire / secondaire /… pour la redondance et la réduction de latence?

Je pensais que le DNS primaire / secondaire à des fins de redondance était simple. Ma compréhension est que vous devez avoir un primaire et au moins un secondaire, et que vous devez configurer votre secondaire dans un emplacement géographiquement différent, mais également derrière un routeur différent (voir par exemple /server/48087 / pourquoi-y-a-t-il-plusieurs-serveurs-de-nom-pour-mon-domaine )

Actuellement, nous avons deux serveurs de noms dans notre centre de données principal. Récemment, nous avons subi des pannes pour diverses raisons, qui ont entraîné la suppression des deux serveurs de noms et nous ont laissé, ainsi que nos clients, sans DNS actif pendant quelques heures. J'ai demandé à mon équipe sysadmin de terminer la configuration d'un serveur DNS dans un autre centre de données et de le configurer comme serveur de noms secondaire.

Cependant, nos administrateurs système affirment que cela n'aide pas beaucoup si l'autre centre de données n'est pas au moins aussi fiable que le centre de données principal. Ils affirment que la plupart des clients ne parviennent toujours pas à rechercher correctement ou expirent trop longtemps lorsque le centre de données principal est en panne.

Personnellement, je suis convaincu que nous ne sommes pas la seule entreprise à avoir ce genre de problème et que c'est probablement déjà un problème résolu. Je ne peux pas imaginer que toutes ces sociétés Internet soient affectées par notre genre de problème. Cependant, je ne trouve pas de bons documents en ligne qui expliquent ce qui se passe dans les cas d'échec (par exemple, les délais d'attente des clients) et comment les contourner.

Quels arguments puis-je utiliser pour percer des trous dans le raisonnement de nos administrateurs système? Y a-t-il des ressources en ligne que je peux consulter pour mieux comprendre les problèmes qu'ils prétendent exister?

Quelques notes supplémentaires après lecture des réponses:

• nous sommes sous Linux
• nous avons des besoins DNS compliqués supplémentaires; nos entrées DNS sont gérées par un logiciel personnalisé, BIND étant actuellement asservi à partir d'une implémentation DNS torsadée, et certaines vues dans le mélange également. Cependant, nous sommes totalement capables de configurer nos propres serveurs DNS dans un autre centre de données.
• Je parle de DNS faisant autorité pour que les étrangers trouvent nos serveurs, pas de serveurs DNS récursifs pour nos clients locaux.

Il existe un très bon document, bien que très technique, sur les "meilleures pratiques" qui peut s'avérer utile lors de la lutte contre votre administrateur système. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

S'il ne reconnaît pas la validité des articles rédigés par Cisco, alors vous pourriez tout aussi bien arrêter de vous disputer avec l'administrateur système - montez à un niveau de gestion.

De nombreux autres documents sur les "meilleures pratiques" recommandent de séparer vos serveurs de noms principal et secondaire non seulement par bloc IP, mais par emplacement physique. En fait, la RFC 2182 recommande que les services DNS secondaires soient géographiquement séparés. Pour de nombreuses entreprises, cela signifie louer un serveur dans un autre centre de données ou s'abonner à un fournisseur DNS hébergé tel que ZoneEdit ou UltraDNS .

Cependant, nos administrateurs système affirment que cela n'aide pas beaucoup si l'autre centre de données n'est pas au moins aussi fiable que le centre de données principal. Ils affirment que la plupart des clients ne parviennent toujours pas à rechercher correctement ou expirent trop longtemps lorsque le centre de données principal est en panne.

Ah, la mise au point est fiable . Il semble qu'ils prennent un coup sur votre lien vers l'extérieur, plutôt que de configurer un DNS secondaire. Tout de même, configurez le DNS secondaire et continuez à partir de là. Cela aidera avec la charge et soutiendra les choses dans un pincement ... mais demandez pourquoi ils pensent que l'autre emplacement n'est pas fiable .

Personnellement, je suis convaincu que nous ne sommes pas la seule entreprise à avoir ce genre de problème et que c'est probablement déjà un problème résolu. Je ne peux pas imaginer que toutes ces sociétés Internet soient affectées par notre genre de problème.

Vous n'êtes pas la seule entreprise, et cela a probablement été refait un million de fois dans des entreprises du monde entier.

Cependant, je ne trouve pas de bons documents en ligne qui expliquent ce qui se passe dans les cas d'échec (par exemple, les délais d'attente des clients) et comment les contourner.

Quels arguments puis-je utiliser pour percer des trous dans le raisonnement de nos administrateurs système? Y a-t-il des ressources en ligne que je peux consulter pour mieux comprendre les problèmes qu'ils prétendent exister?

• Je parle de DNS faisant autorité pour que les étrangers trouvent nos serveurs, pas de serveurs DNS récursifs pour nos clients locaux.

Vous pouvez faire toutes sortes de choses, y compris la mise en place d'un service DNS externe qui est enregistré en tant qu'autorité pour votre zone, mais en faisant secrètement des serveurs faisant autorité (externes) secondaires à vos propres serveurs DNS (internes). Cette configuration est horrible, fausse, montre que je suis vraiment un SysAdmin diabolique, et un chaton meurt chaque fois que je le recommande. Mais cela fait deux choses:

• Vous obtenez votre service DNS pour gérer le poids de la charge, ce qui rend les questions sur la capacité de votre propre DNS (interne) comme théorique.
• Vous obtenez que votre service DNS reste actif pendant que vos serveurs DNS internes sont en panne, donc peu importe la fiabilité de votre lien - ce qui compte, c'est la fiabilité de votre fournisseur de services DNS .

Les raisons pour lesquelles ce n'est pas la bonne chose à faire:

• Vous mettriez en place ce qu'on appelle un "serveur de noms furtif", car bien qu'il apparaisse dans vos enregistrements de zone et que vous puissiez interroger l'IP pour le nom du serveur, il ne sera jamais touché par l'extérieur. Les requêtes des clients n'y parviendront jamais.
• Bien que votre DNS continue de fonctionner correctement (car votre service hébergé résoudrait le problème), cela ne signifie pas que tous les sites Web que vous possédez fonctionneraient si votre connexion Internet était en panne, c'est-à-dire qu'il ne résout que la moitié du problème . Cela ressemble vraiment à d'autres problèmes qui préoccupent les administrateurs.

Malheureusement, le résolveur DNS Linux ne semble pas avoir de prise en charge directe pour détecter et effectuer des basculements pour les serveurs DNS. Il continue d'alimenter les requêtes vers votre serveur de noms de résolution principal, attend un délai configuré, tente à nouveau, etc.

Cela signifie souvent jusqu'à 30 secondes de retard pour toute demande. Sans d'abord essayer le secondaire tant que le primaire est en panne.

Je voulais résoudre ce problème car notre serveur de noms de résolution Amazon EC2 est inaccessible pour beaucoup de nos employés. Cela entraîne de gros retards dans nos processus et même des temps d'arrêt dans certains cas, car nous comptons sur la résolution. Je voulais un bon basculement vers les serveurs de noms Google / Level3 au cas où Amazon tomberait à nouveau. Et retomber dès que possible, car Amazon résoudra les noms d'hôte en adresses locales le cas échéant, en résolvant dans une latence plus faible, par exemple pour la communication d'instance.

Mais quel que soit le cas d'utilisation, un meilleur basculement est nécessaire. Je voulais résoudre ça. Je voulais éviter les démons, les services, etc., car cela ne ferait qu'introduire plus de points de défaillance uniques. Je voulais utiliser une technologie aussi archaïque et robuste que possible.

J'ai décidé d'utiliser crontab & bash et j'ai écrit nsfailover.sh . J'espère que cela t'aides.

Il semble que le problème est que les clients - qui pourraient être n'importe qui, n'importe où - voient deux serveurs DNS et si l'un échoue, ils ne basculent pas vers le serveur secondaire ou il y a un long délai d'attente avant eux.

Je conviens que les serveurs DNS principal et secondaire devraient être situés dans différentes installations comme meilleure pratique, mais je ne vois pas comment cela résoudrait ce problème particulier.

Si le client insiste pour demander une adresse IP spécifique, en ignorant l'adresse IP du secondaire (ou en prenant un certain temps pour y arriver), il vous suffit de trouver une solution qui maintient cette adresse IP en état de marche, même si le le serveur principal est en panne.

Certaines directions à explorer seraient un équilibreur de charge qui peut rediriger le trafic pour une seule adresse IP vers plusieurs serveurs dans différents centres de données; ou peut-être un routage anycast.

Tant que chacun de vos centres de données se trouve sur des circuits différents (idéalement avec différents fournisseurs en amont loin dans le cloud), vous pouvez configurer un DNS assez fiable avec seulement les deux centres de données. Vous devez simplement vous assurer que votre registraire de choix remplit les enregistrements de colle appropriés sur les grands serveurs dans le ciel.

Notre configuration est:

• 2 centres de données physiques (circuits séparés, FAI et fournisseurs en amont)
• 2 serveurs de requêtes physiques dans un cluster derrière une SLB dans chaque installation
• 2 dispositifs d'équilibrage de charge pour servir des enregistrements spécifiques dont nous voulons gérer l'équilibre entre les deux datacetners
• maître caché accessible en interne par les deux clusters de serveurs (je crois très fortement aux configurations de maître caché pour la sécurité)

Cette configuration a été suffisamment efficace pour nous donner environ 5 9 de temps de disponibilité au cours des 6 ou 7 dernières années, même avec des temps d'arrêt occasionnels du serveur pour les mises à jour, etc. Si vous êtes prêt à dépenser quelques dollars supplémentaires, vous pouvez envisager d'externaliser hébergement de la zone avec quelqu'un comme les ultradns ...

Quant à la conversation de chargement mentionnée par KPWINC, elle est correcte à 100%. Si votre plus petit centre de données ne peut pas gérer 100% de votre charge, alors vous êtes probablement désossé de toute façon parce que votre panne va se produire quand vous le voudrez le moins =)

Je prends la charge maximale de tous mes routeurs de périphérie, je les additionne tous ensemble, puis je divise par 0,65 ... c'est la bande passante minimale que nous devons avoir dans chaque centre de données. J'ai mis cette règle en place il y a environ 5 ans, avec certains documents pour la justifier que j'ai recueillis auprès de CCO et sur Internet, et cela ne nous a jamais fait défaut. Cependant, vous devez vérifier ces statistiques au moins tous les trimestres. Notre trafic a presque triplé entre novembre et février de l'année dernière et je n'y étais pas préparé. Ce côté positif est que la situation m'a permis de générer des données matérielles très claires qui disent qu'à 72% de charge sur notre circuit WAN, nous commençons à abandonner les paquets. Aucune justification supplémentaire ne m'a jamais été demandée pour plus de bande passante.

J'ai réalisé en lisant votre description qu'il n'est pas clair si vous voulez dire DNS faisant autorité pour que les étrangers trouvent vos serveurs, ou serveurs DNS récursifs pour vos clients locaux. Le comportement de ces deux-là est très différent.

Pour les serveurs DNS faisant autorité, les "clients" seront d'autres serveurs DNS qui ont une mise en cache et beaucoup d'intelligence. Ils auront tendance à essayer plusieurs serveurs à la fois si le premier est lent, et auront tendance à préférer celui qui leur donne des réponses plus rapides. Dans ce cas, les temps d'arrêt d'un centre de données auraient un très léger impact sur les performances.

Pour les serveurs DNS récursifs, les clients sont vos clients locaux qui ont probablement les serveurs DNS répertoriés dans DHCP. Ils essaieront leurs serveurs dans l'ordre indiqué à chaque fois, avec un délai extrêmement long (plusieurs secondes) avant de passer du premier serveur au deuxième serveur.

Si votre centre de données principal est en panne, personne ne pourra accéder à ces serveurs de toute façon, mais souvent les erreurs qui en découlent sont plus intelligibles que les erreurs des serveurs DNS inaccessibles. «impossible de contacter le serveur» ou «délai de connexion dépassé» au lieu de «impossible de trouver le serveur» ou «aucun serveur de ce type». Par exemple, la plupart des serveurs SMTP mettront le courrier en file d'attente pendant une semaine s'ils voient le serveur dans DNS mais ne peuvent tout simplement pas l'atteindre; s'ils ne le trouvent pas du tout dans le DNS, ils peuvent immédiatement refuser d'essayer de le livrer à votre domaine.

Le DNS secondaire étant géographiquement et séparé du réseau est une bonne chose. Vous pouvez peut-être échanger des DNS secondaires avec une entreprise amicale, et il y a beaucoup de fournisseurs DNS que vous pouvez payer pour le faire pour vous. Certains bureaux d'enregistrement ont également un DNS secondaire en tant que service.

Thomas,

Après avoir lu votre mise à jour, j'ai révisé mon article (l'article précédent fait référence au logiciel Windows).

Il me semble presque que votre ou vos administrateurs système vous disent que votre emplacement secondaire n'a pas le matériel nécessaire pour gérer la CHARGE COMPLÈTE?

On dirait qu'il dit: "Hé mon pote, si notre emplacement principal (qui comprend le DNS principal) tombe en panne, le DNS est le MOINS de nos soucis car si COLO1 est en panne, alors COLO2 ne peut pas gérer la charge de toute façon."

Si c'est le cas, je vous suggère de regarder votre infrastructure et de trouver une meilleure conception. C'est plus facile à dire qu'à faire, surtout maintenant que vous vivez dans un environnement de production.

Tout cela mis à part, dans un monde parfait, COLO1 et COLO2 pourraient être autonomes et gérer votre charge.

Une fois que cela était en place ... le DNS n'est rien de plus que d'avoir suffisamment de serveurs DNS avec un rafraîchissement assez rapide et si un côté échoue, vous pouvez réécrire votre DNS pour pointer vers les serveurs qui sont UP.

J'ai utilisé cette méthode dans des environnements de taille petite à raisonnable et cela fonctionne très bien. Le basculement prend généralement moins de 10 minutes.

Il vous suffit de vous assurer que vos serveurs DNS peuvent gérer la charge supplémentaire d'un court TTL (durée de vie).

J'espère que cela t'aides.

Vos administrateurs système ont (généralement) tort.

Les serveurs récursifs qui interrogent vos serveurs faisant autorité remarqueront très rapidement si l'un des sites ne répond pas.

Oui, il y a une chance que les clients connaissent des délais de résolution DNS très modestes en cas de panne, mais ils ne dureront qu'une seconde ou deux, et une fois que les propres serveurs DNS du client auront appris qu'un des serveurs est en panne, ils utiliseront les serveurs restants de préférence à celui qui a échoué.

Si nécessaire (pour apaiser les administrateurs système), continuez d'exécuter deux serveurs dans votre centre de données principal, mais mettez-en au moins un de plus à l'extérieur.

Un serveur DNS secondaire ne fait jamais de mal, selon l'endroit où il est hébergé, il vous donnera plus ou moins de fonctionnalités.

Si votre hôte principal tombe en panne, un secondaire peut prendre le relais, qu'il soit installé à côté ou à distance. Si toutefois votre liaison montante de centre de données échoue, vous pouvez toujours obtenir des réponses DNS du serveur dans un autre centre de données, mais vous ne pourrez de toute façon pas atteindre vos serveurs. Ainsi, vos utilisateurs finaux ne bénéficieront pas directement du DNS secondaire dans l'emplacement distant.

Différents clients réagissent d'une autre manière au fait que les serveurs DNS ne sont pas disponibles, il y a donc une part de vérité dans le délai d'attente des clients, mais pas tous.

Un DNS secondaire dans un centre de données distant sera cependant toujours en mesure de résoudre l'adresse IP du serveur que vous souhaitez atteindre afin que vous puissiez déboguer le routage et voir quand ils réapparaissent. Et si vous avez correctement configuré les serveurs MX secondaires, vous ne perdrez même aucun courrier.