Il s'agit d'une question canonique sur la géo-redondance DNS.

Il est extrêmement connu que les serveurs DNS géo-redondants situés à des emplacements physiques distincts sont hautement souhaitables lors de la fourniture de services Web résilients. Ceci est couvert en profondeur par le document BCP 16 , mais certaines des raisons les plus fréquemment mentionnées incluent:

• Protection contre les catastrophes du centre de données. Des tremblements de terre se produisent. Des incendies se produisent dans les racks et suppriment les serveurs et équipements réseau à proximité. Plusieurs serveurs DNS ne vous serviront à rien si des problèmes physiques au niveau du centre de données désactivent les deux serveurs DNS en même temps, même s'ils ne sont pas sur la même ligne.

• Protection contre les problèmes de pairs en amont. Plusieurs serveurs DNS n'empêcheront pas les problèmes si un homologue de réseau en amont partagé fait une sieste. Que le problème en amont vous mette complètement hors ligne ou isole simplement tous vos serveurs DNS d'une fraction de votre base d'utilisateurs, le résultat final est que les gens ne peuvent pas accéder à votre domaine même si les services eux-mêmes sont situés dans un centre de données complètement différent.

C'est bien beau, mais les serveurs DNS redondants sont-ils vraiment nécessaires si j'exécute tous mes services à partir de la même adresse IP? Je ne vois pas comment avoir un deuxième serveur DNS me procurerait un avantage si personne ne pouvait accéder à quoi que ce soit de mon domaine.

Je comprends que cela est considéré comme une meilleure pratique, mais cela semble vraiment inutile!

Remarque: Contenu en litige, reportez-vous aux commentaires pour les deux réponses. Des erreurs ont été trouvées et cette Q&R a besoin d'une refonte.

Je retire l'acceptation de cette réponse pour le moment jusqu'à ce que l'état de cette Q&A canonique soit correctement traité. (la suppression de cette réponse entraînerait également la suppression des commentaires joints, ce qui n'est pas la voie à suivre pour l'OMI. Je vais probablement en faire une réponse wiki communautaire après une édition approfondie.)

Je pourrais citer ici les RFC et utiliser des termes techniques, mais c'est un concept qui manque à beaucoup de gens aux deux extrémités du spectre des connaissances et je vais essayer de répondre à un public plus large.

Je comprends que cela est considéré comme une meilleure pratique, mais cela semble vraiment inutile!

Cela peut sembler inutile ... mais ce n'est pas le cas!

Les serveurs récursifs se souviennent très bien lorsque les serveurs distants ne répondent pas à une requête, en particulier lorsqu'ils réessayent et ne voient toujours pas de réponse. Beaucoup implémentent la mise en cache négative de ces échecs de communication et placent temporairement les serveurs de noms qui ne répondent pas dans la zone de pénalité pendant une période ne dépassant pas cinq minutes. Finalement, cette période de «pénalité» expire et ils reprendront la communication. Si la mauvaise requête échoue à nouveau, elle revient directement dans la boîte, sinon elle reprend ses activités habituelles.

C'est là que nous rencontrons le problème du serveur de noms unique:

• La période de pénalité est par nature de mise en œuvre toujours supérieure ou égale à la durée du problème de réseau. Dans presque tous les cas, elle sera plus longue, jusqu'à un maximum de cinq minutes supplémentaires.
• Si votre serveur DNS unique entre dans la zone de pénalité, la requête associée à l'échec sera complètement morte pendant toute la durée.
• De brèves interruptions de routage se produisent sur Internet plus que la plupart des gens ne le pensent. Les retransmissions TCP / IP et les protections d'application similaires font un bon travail de cacher cela à l'utilisateur, mais c'est quelque peu inévitable. Internet fait un bon travail pour contourner ces dommages en grande partie grâce aux protections intégrées dans les différentes normes qui prennent en charge la pile réseau ... mais cela inclut également celles intégrées dans DNS, et avoir des serveurs DNS géo-redondants est un une partie de cela.

Pour faire court, si vous optez pour un seul serveur DNS (cela inclut l'utilisation de la même adresse IP plusieurs fois dans les NSenregistrements), cela va se produire. Cela va également se produire beaucoup plus que vous ne le pensez, mais le problème sera tellement sporadique que les chances de l'échec 1) vous sont signalées, 2) sont reproduites et 3) liées à ce problème spécifique sont extrêmement proches de zéro. Ils étaient à peu près nuls si vous interveniez dans ce Q&R sans savoir comment ce processus fonctionnait, mais heureusement, cela ne devrait pas être le cas maintenant!

Cela devrait-il vous déranger? Ce n'est pas vraiment ma place pour le dire. Certaines personnes ne se soucient pas du tout de ce problème d'interruption de cinq minutes, et je ne suis pas ici pour vous en convaincre. Ce que je suis ici pour vous convaincre, c'est que vous sacrifiez en fait quelque chose en n'exécutant qu'un seul serveur DNS, et dans tous les scénarios.

OP demande:

C'est bien beau, mais les serveurs DNS redondants sont-ils vraiment nécessaires si j'exécute tous mes services à partir de la même adresse IP? Je ne vois pas comment avoir un deuxième serveur DNS me procurerait un avantage si personne ne pouvait accéder à quoi que ce soit de mon domaine.

Grande question!

La meilleure réponse est fournie par le professeur Daniel J.Bernstein, PhD Berkeley , qui est non seulement un chercheur, scientifique et cryptologue de renommée mondiale, mais qui a également écrit une suite DNS très populaire et bien reçue connue sous le nom de DJBDNS ( dernière publication en 2001- 02-11 , toujours populaire à ce jour).

http://cr.yp.to/djbdns/third-party.html (2003-01-11)

Coûts et avantages du service DNS tiers

Faites attention à cette partie courte et succincte:

Arguments erronés pour le service DNS tiers

…

La deuxième tactique consiste à affirmer que les clients DNS répandus feront quelque chose de particulièrement mauvais lorsqu'ils ne pourront pas atteindre tous les serveurs DNS. Le problème avec cet argument est que la déclaration est fausse. Un tel client est clairement bogué et ne pourra pas survivre sur le marché: réfléchissez à ce qui se passe si les routeurs du client tombent brièvement en panne ou si le réseau du client est temporairement inondé.

En tant que tel, la réponse originale à cette question ne pourrait pas être plus fausse.

Oui, de courtes pannes de réseau temporaires de quelques secondes se produisent de temps en temps. Non, un échec à résoudre un nom pendant une telle panne ne serait pas mis en cache pendant un certain nombre de minutes (sinon, même avoir la meilleure configuration de serveurs de noms faisant autorité et hautement disponibles dans le monde n'aidera pas).

Tout logiciel qui implémente généreusement la directive conservatrice des 5 minutes maximum du RFC 1998-03 pour mettre en cache les pannes est simplement cassé par conception, et avoir un serveur géo-redondant supplémentaire ne fera pas de bosse.

En fait, selon combien de temps un délai d'attente DNS est mis en cache? , dans BIND, la SERVFAILcondition n'était traditionnellement PAS du tout mise en cache avant 2014, et depuis 2015, elle est mise en cache par défaut pendant seulement 1 seconde , moins que ce qu'il faudrait à un utilisateur moyen pour atteindre un délai de résolution et appuyer à nouveau sur ce bouton Actualiser .

(Et même avant d'arriver au point ci-dessus de savoir si une tentative de résolution doit être mise en cache ou non, il faut plus de quelques paquets abandonnés, même pour que le premier SERVFAIL se produise en premier lieu.)

De plus, les développeurs de BIND ont même mis en place un plafond pour la fonctionnalité, de seulement 30 secondes, qui, même en tant que plafond (par exemple, la valeur maximale que la fonctionnalité acceptera jamais), est déjà 10 fois inférieur à la suggestion de 5 minutes (300 secondes) du RFC, garantissant que même les administrateurs les plus bien intentionnés (des utilisateurs du globe oculaire) ne pourront pas tirer sur leurs propres utilisateurs dans le pied.

En outre, il existe de nombreuses raisons pour lesquelles vous ne souhaiterez peut-être pas exécuter un service DNS tiers - lisez l'ensemble djbdns/third-party.htmlpour tous les détails , et la location d'un minuscule serveur supplémentaire juste pour que DNS administre par vous-même n'est guère garantie lorsqu'il n'est pas nécessaire autre que BCP 16 existe pour une telle entreprise.

Dans mon expérience "anecdotique" personnelle de possession et de configuration de noms de domaine depuis au moins 2002, je peux vous dire avec certitude et honnêteté que j'ai effectivement eu au total un temps d'arrêt important de mes différents domaines en raison de la gestion professionnelle. Les serveurs tiers de mes bureaux d'enregistrement et fournisseurs d'hébergement , qui, un fournisseur à la fois et au fil des ans, ont tous eu leurs incidents, n'étaient pas disponibles, ont indûment interrompu mes domaines, au même moment exact que ma propre adresse IP (où le HTTP et le SMTP pour un domaine donné ont été hébergés à partir de) était entièrement accessible autrement. Veuillez noter que ces pannes se sont produites avec plusieurs fournisseurs indépendants, respectés et gérés par des professionnels, et ne sont en aucun cas des incidents isolés, et se produisent sur une base annuelle, et, en tant que service tiers,sont entièrement hors de votre contrôle ; il se trouve que peu de gens en parlent à long terme.

En bref:

Le DNS géo-redondant n'est PAS du tout nécessaire pour les petits sites.

Si vous exécutez tous vos services à partir de la même adresse IP , l'ajout d'un deuxième DNS est très susceptible d'entraîner un point de défaillance supplémentaire et nuit à la disponibilité continue de votre domaine. La «sagesse» de devoir toujours le faire dans n'importe quelle situation imaginable est en effet un mythe très populaire; BUSTED.

Bien sûr, les conseils seraient totalement différents si certains des services du domaine, que le Web (HTTP / HTTPS), le courrier (SMTP / IMAP) ou la voix / texte (SIP / XMPP), étaient déjà desservis par des tiers fournisseurs, auquel cas l'élimination de votre propre IP en tant que point de défaillance unique serait en effet une approche très sage, et la géo-redondance serait en effet très utile.

De même, si vous avez un site particulièrement populaire avec des millions de visiteurs, et que vous avez sciemment besoin de la flexibilité et des protections supplémentaires du DNS géo-redondant selon BCP 16, alors… Vous n'utilisez probablement pas un seul serveur / site pour le web / mail / voix / texte déjà, donc cette question et réponse ne s'appliquent évidemment pas. Bonne chance!