Question Méthode correcte pour configurer DNS primaire / secondaire /… pour la réduction de la redondance et de la latence?


Je pensais que le DNS primaire / secondaire à des fins de redondance était simple. Je crois comprendre 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 https://serverfault.com/questions/48087/why-are-there-several-nameservers-for-my-domain)

Actuellement, nous avons deux serveurs de noms dans notre centre de données principal. Récemment, nous avons connu des pannes dues à diverses causes pour lesquelles nous avons éliminé les deux serveurs de noms et laissé nos clients et nous-mêmes sans système DNS pendant quelques heures. J'ai demandé à mon équipe administrateur système de terminer la configuration d'un serveur DNS dans un autre centre de données et de le configurer en tant que serveur de noms secondaire.

Cependant, nos administrateurs système affirment que cela n’aidera pas beaucoup si l’autre centre de données n’est pas aussi fiable que le centre de données principal. Ils affirment que la plupart des clients ne parviendront toujours pas à rechercher correctement ou à attendre 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 type de problème et que ce problème est probablement déjà résolu. Je ne peux pas imaginer que toutes ces sociétés Internet soient affectées par notre type 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 résoudre.

Quels arguments puis-je utiliser pour faire des trous dans le raisonnement de nos administrateurs système? 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 la lecture des réponses:

  • nous sommes sur Linux
  • nous avons d'autres besoins compliqués en matière de DNS; nos entrées DNS sont gérées par un logiciel personnalisé, BIND étant actuellement asservi à une implémentation de Twisted DNS, ainsi que certaines vues du mélange. Cependant, nous sommes tout à fait capables de configurer nos propres serveurs DNS dans un autre centre de données.
  • Je parle de DNS faisant autorité pour que les étrangers recherchent nos serveurs, et non de serveurs DNS récursifs pour nos clients locaux.

12
2017-08-10 17:16


origine




Réponses:


Il existe un très bon document, bien que très technique, sur les "meilleures pratiques" qui peut s'avérer utile pour combattre 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 écrits par Cisco, arrêtez de vous disputer avec l'administrateur système et augmentez votre niveau de gestion.

De nombreux autres documents "Meilleures pratiques" recommandent de séparer vos serveurs de noms primaire et secondaire, non seulement par bloc IP, mais par emplacement physique. En fait, la RFC 2182 recommande de séparer géographiquement les services DNS secondaires. 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.


4
2017-08-10 17:30





Cependant, nos administrateurs système affirment que cela   n'aide pas beaucoup si les autres données   centre n'est pas au moins aussi sûr   en tant que centre de données principal. Ils prétendent   que la plupart des clients ne parviendront toujours pas à   regarder correctement, ou expirer aussi   long, lorsque le centre de données principal est   vers le bas.

Ah, l'objectif est sûr. On dirait qu'ils s'en prennent à votre lien vers l'extérieur, plutôt que de configurer un DNS secondaire. Néanmoins, configurez le DNS secondaire et procédez à partir de là. Cela aidera avec la charge et facilitera les choses dans un pincement ... mais ne demandez pas pourquoi ils pensent que l'autre endroit n'est pas sûr.

Personnellement, je suis convaincu que nous ne sommes pas   la seule entreprise avec ce genre de   problème et qu'il est le plus probable   déjà un problème résolu. Je ne peux pas   imaginez toutes ces sociétés Internet   être affecté 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   cela explique ce qui se passe en cas d'échec   des cas (par exemple, délais d'expiration du client)   et comment les contourner.

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

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

Vous pouvez faire toutes sortes de choses, y compris la configuration d'un service DNS externe enregistré en tant qu'autorité de votre zone, mais en rendant secrètement les serveurs (extérieurs) faisant autorité secondaires par rapport à vos propres serveurs DNS (intérieurs). Cette configuration est horrible, fausse, montre que je suis vraiment un SysAdmin diabolique, et un chaton meurt chaque fois que je le recommande.  Mais il fait deux choses:

  • Vous demandez à votre service DNS de gérer le poids de la charge, ce qui pose des questions sur la capacité de votre propre DNS (interne) comme étant théorique.
  • Votre service DNS reste actif alors que vos serveurs DNS internes sont peut-être en panne. La fiabilité de votre lien importe donc peu importe; ce qui compte, c'est de savoir dans quelle mesure votre fiabilité est fiable. Fournisseur de service DNS est.

Les raisons pour lesquelles c'est le faux chose à faire:

  • Vous seriez en train de configurer ce qu'on appelle un "serveur de noms furtif", car même s'il apparaît dans vos enregistrements de zone et que vous pouvez interroger l'IP pour connaître le nom du serveur, il ne sera jamais touché par l'extérieur. Les requêtes des clients ne l'atteindront jamais.
  • Bien que votre DNS continue à fonctionner correctement (car votre service hébergé résoudrait le problème), cela ne signifie pas que vos sites Web fonctionneraient si votre connexion Internet était en panne, c’est-à-dire: il ne traite que de la moitié du problème. Cela ressemble vraiment à d’autres problèmes qui préoccupent les administrateurs.

3
2017-08-13 13:58



Peut-être que ma définition diffère, mais j'utilise une configuration "maître masqué", et comme le maître n'est jamais référencé dans les fichiers de zone, je pense qu'il s'agit d'une configuration légèrement plus sécurisée. Le serveur répond toujours avec autorité, fournit un point de mise à jour unique et n'est pas accessible aux demandes extérieures. - Greeblesnort
le commentaire est +1 sur pourquoi je le fais de cette façon. :) J'ai oublié de mentionner, avec un peu de magie iptables, vous pouvez faire en sorte que le port 53 ne réponde qu'aux demandes extérieures des secondaires, ce qui le rend très sûr. Pourtant, ce n'est pas entièrement "casher" et peut créer des problèmes. Essayez de lancer un domaine sur intodns.com de temps en temps et voyez ce qu'il rapporte ... - Avery Payne


Malheureusement, le résolveur DNS Linux ne semble pas prendre en charge directement la détection et la réalisation de basculements pour les serveurs DNS. Il conserve les requêtes envoyées à votre serveur de noms principal, attend un délai d'attente configuré, tente à nouveau, etc.

Cela signifie souvent des délais allant jusqu'à 30 secondes 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 travailleurs. Cela entraîne des retards importants dans nos processus et même des temps morts 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 en panne. Et retombez dès que possible, car dans ce cas, Amazon résoudra les noms d’hôte en adresses locales, le cas échéant, avec un temps de latence inférieur, pour une communication d’instance par exemple.

Mais quel que soit le cas d'utilisation, il est nécessaire d'améliorer le basculement. Je voulais résoudre ce problème. Je voulais rester à l’écart des démons par procuration, des services, etc. Single Point Of Failures. 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.


3
2018-03-27 13:41



trouvé via ddg linux first dns server is down second works but is slow - bgStack15


On dirait que le problème est que les clients—Qui peut être n'importe qui, n'importe où — voyez deux serveurs DNS et si l'un d'eux échoue, ils ne basculent pas sur le serveur secondaire ou leur délai d'attente est long.

Je conviens que les serveurs DNS primaire et secondaire devraient être situés dans des installations différentes, ce qui est une pratique exemplaire, mais je ne vois pas comment cela résoudrait ce problème particulier.

Si le client insiste pour interroger une adresse IP spécifique, en ignorant l'adresse IP du secondaire (ou prend un certain temps pour l'exécuter), vous devez simplement proposer une solution permettant à cette adresse IP de fonctionner, même si le le serveur principal est en panne.

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


1
2017-08-10 19:15



La plupart des clients linux ont un délai d'expiration de 5 secondes, ce qui est mortel. Deuxième serveur DNS ou non, une fois le serveur principal en panne, il sera si lent qu'il apparaîtra en panne. - Ryaner


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

Notre configuration est:

  • 2 datacenters physiques (séparés circuits, FAI et fournisseurs en amont)
  • 2 serveurs de requêtes physiques dans un cluster derrière un SLB dans chaque établissement
  • 2 dispositifs d'équilibrage de charge à desservir enregistrements spécifiques que 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 fermement aux configurations de maître cachées pour la sécurité)

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

En ce qui concerne 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é parce que votre panne va se produire quand vous le voulez le moins =)

Je prends la charge maximale de tous mes routeurs de périphérie, les ajoute tous ensemble, puis je divise par 0,65 ... ce qui correspond à 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 le justifiant que j'ai recueillis auprès de CCO et concernant Internet, et qui ne nous ont jamais manqué. Cependant, vous devez vérifier ces statistiques au moins trimestriel. Notre trafic a presque été multiplié par 3 entre novembre et février dernier et je n’étais pas préparé à cela. Ce bon côté des choses, c’est que la situation m’a permis de générer des données très claires qui indiquent qu’à une charge de 72% sur notre circuit de réseau étendu, nous commençons à rejeter des paquets. Aucune justification supplémentaire n'a jamais été exigée de moi pour plus de bande passante.


1
2017-08-10 21:58





En lisant votre description, je me suis rendu compte que vous ne compreniez pas clairement si vous voulez parler de DNS faisant autorité pour que des étrangers trouvent vos serveurs ou de serveurs DNS récursifs pour vos clients locaux. Le comportement de ces deux est très différent.

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

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

Si votre centre de données principal est en panne, personne ne pourra de toute façon accéder à ces serveurs, mais souvent les erreurs qui en découlent sont plus intelligibles que celles de serveurs DNS inaccessibles. "Impossible de contacter le serveur" ou "Connexion expirée" 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 le DNS mais ne peuvent tout simplement pas le joindre. S'ils ne peuvent pas le trouver dans le DNS, ils peuvent immédiatement refuser même d'essayer de le livrer à votre domaine.

Le DNS secondaire étant géographiquement et séparé du réseau est une bonne chose. Vous pourrez peut-être échanger des DNS secondaires avec une société amie et de nombreux fournisseurs de services DNS peuvent être payés pour le faire à votre place. Certains bureaux d'enregistrement ont également un DNS secondaire en tant que service.


0
2017-08-10 17:38





Thomas,

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

Il me semble presque que vos administrateurs système vous disent que votre emplacement secondaire ne dispose pas du matériel nécessaire pour gérer la charge complète?

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

Si CELA est le cas, je vous suggérerais alors de vérifier votre infrastructure et d’améliorer la conception. C'est plus facile à dire qu'à faire, surtout maintenant que vous êtes en direct dans un environnement de production.

Tout cela mis à part, dans un monde parfait, COLO1 et COLO2 seraient capables de rester seuls et de gérer votre charge de travail.

Une fois que cela était en place ... le DNS n’est vraiment rien de plus que d’avoir suffisamment de serveurs DNS avec une actualisation assez rapide et si l’un des côtés échoue, vous pouvez réécrire votre DNS pour qu'il pointe 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.

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

J'espère que cela t'aides.


0
2017-08-10 17:21



C'était un peu ma pensée aussi, mais je veux savoir comment ils le font :-) - Kyle Brandt♦


Vos administrateurs 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 est possible que les clients subissent des retards 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 serveurs DNS du client auront appris qu'un des serveurs est en panne, ils l'utiliseront. les serveurs restants de préférence à celui qui a échoué.

Si nécessaire (pour apaiser les administrateurs système), continuez à faire fonctionner deux serveurs sur votre centre de données principal, mais mettez au moins un autre à l'extérieur.


0
2017-08-10 20:34



Avez-vous une référence pour cela? - Teddy
La configuration par défaut de Linux ne met pas en cache les serveurs de noms. Cela s'applique également à quelques appareils basés sur Linux (tels que nos téléphones IP), ce qui signifie que lorsque la requête principale est en panne, les requêtes DNS prennent si longtemps, car chaque requête essaye la requête principale, attend 5 secondes, puis la seconde, que les choses essentiellement arrêter de travailler sous charge. - Ryaner


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

Si votre hôte principal échoue, un hôte secondaire peut prendre le relais, qu'il soit assis à 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 dossier. datacenter, 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 sur l'emplacement distant.

Différents clients réagissent différemment lorsque les serveurs DNS ne sont pas disponibles. Il est donc vrai que les clients arrivent à expiration, mais pas tous.

Cependant, un DNS secondaire dans un centre de données distant sera toujours capable de résoudre l'adresse IP du serveur que vous souhaitez atteindre afin que vous puissiez déboguer le routage et voir quand il sera rétabli. Et si vous avez configuré correctement les serveurs MX secondaires, vous ne perdrez aucun courrier.


0
2017-08-13 21:45