Devrions-nous héberger nos propres serveurs de noms?


93

Ceci est une question canonique sur l'opportunité d'impartir la résolution DNS pour ses propres domaines

Mon fournisseur de services Internet fournit actuellement le DNS pour mon domaine, mais ils imposent des limites à l'ajout d'enregistrements. Par conséquent, je pense utiliser mon propre DNS.

Préférez-vous héberger votre propre DNS ou vaut-il mieux que votre FAI le fasse?

Existe-t-il des alternatives que je peux examiner?


En ajoutant aux réponses ci-dessous, l'expérience est également importante. Il y a de nombreuses erreurs que vous allez faire en tant qu'administrateur DNS jeune sauf bon mentorat ou un oeil d' aigle pour la documentation. (les livres et les RFC, pas les HOWTO) Les erreurs commises au niveau de la couche DNS faisant autorité provoquent des pannes, même lorsque le reste de votre réseau fonctionne correctement .
Andrew B

Lisez également les questions et réponses associées. Pourquoi un DNS redondant géo est-il nécessaire, même pour les petits sites?
HBruijn

Réponses:


64

Je ne voudrais pas utiliser mon propre serveur DNS. Dans mon cas, la société d'hébergement hébergeant mon site Web fournit un service DNS gratuit. Il existe également des alternatives, des entreprises ne proposant que l'hébergement DNS (on pense notamment à DNS Made Easy , mais il en existe bien d'autres), qui sont le genre de choses sur lesquelles vous devriez probablement vous pencher.

La raison pour laquelle je ne le ferais pas moi-même, c'est que le DNS est censé être assez fiable, et à moins que vous n'ayez un réseau de serveurs réparti géographiquement, vous mettriez tous vos œufs dans le même panier, pour ainsi dire. En outre, il existe de nombreux serveurs DNS dédiés, suffisamment pour que vous n’ayez pas besoin de démarrer un nouveau serveur.


7
+1 à DNS Made Easy. Ils ont un enregistrement vérifié, 100,0% des mises à jour au cours des 7 dernières années.
Portman

Je pensais que je laisserais tomber une note. Aujourd’hui, nous en avons enfin marre du DNS de merde de notre fournisseur actuel. Nous sommes passés à DNS Made Easy sur la base de la recommandation proposée, et c’est fan-bloody-tastic. Aimer. J'aurais aimé l'avoir fait il y a des années.
Mark Henderson

1
N'est-ce pas pour cela qu'il existe un serveur principal et un serveur secondaire pour chaque entrée? Je n'ai jamais eu un problème de primaire, et le secondaire étant mon registraire; Je veux dire que j'ai eu un petit problème sur le primaire, mais personne n'a remarqué parce qu'il y avait un secondaire fiable.
dlamblin

Bien sûr, rien de mal à cela si vous voulez vraiment exécuter votre propre serveur DNS pour une raison quelconque. Mais sinon, tant que vous paierez quand même une tierce partie pour l'hébergement DNS (pour être la deuxième), vous pouvez aussi bien la laisser gérer tout. Je pense que pour la plupart des gens, faire tourner un serveur DNS est plus ennuyant que ça en vaut la peine.
David Z

DNS Made Easy dispose en réalité d'un réseau de serveurs couvrant plusieurs continents. Et ils utilisent le routage anycast. Leur redondance est donc ridicule, bien au-delà de la configuration classique à deux serveurs (primaire et secondaire). Mais en théorie, cela signifie également que les ordinateurs du monde entier auront une résolution DNS rapide.
Steve Wortham

27

Nous hébergeons toujours notre propre DNS (DNS inversé préférable). Cela nous permet d'apporter des modifications urgentes sans faire appel à une tierce partie. Si vous avez plusieurs sites, il est facile de configurer un niveau de redondance acceptable pour vos serveurs DNS.

Si vous n'avez pas plusieurs sites, alors je considérerais quelqu'un qui héberge spécifiquement DNS (PAS votre FAI) avec une interface Web pour les modifications. Recherchez également un support 24x7 et des contrats de niveau de service décents.


4
Lorsque vous envisagez d'externaliser, demandez également quel type de protection ou d'atténuation des attaques DDoS est en place. Les fournisseurs de DNS sont attaqués tout le temps et certains sont capables de continuer à fonctionner sans crainte, d'autres s'effondrent au moindre pic de trafic, alors soyez las de la sous-traitance, à moins que ce ne soit un fournisseur de bonne réputation ayant de nombreux serveurs déployés anycast routage activé.
Justin Scott

J'étais sur le point de passer (avec beaucoup d'enthousiasme!) Sur la base de votre expérience personnelle dans la première phrase, mais vous suggérez ensuite d'utiliser un service tiers dans la seconde, ce qui signifie essentiellement qu'un point de défaillance supplémentaire est ajouté pour peu ou pas d'avantage. :/ Triste.
cnst le

19

Pour une configuration DNS correcte et fiable pour votre (vos) domaine (s), vous devriez avoir ...

  • Un minimum de deux serveurs DNS faisant autorité pour votre domaine;
  • Les serveurs DNS doivent être connectés à différents réseaux physiques et alimentations;
  • Les serveurs DNS doivent être situés dans différentes zones géographiques.

Comme il est peu probable que vous ayez accès à l'infrastructure réseau ci-dessus, vous feriez mieux de choisir un fournisseur d'hébergement DNS de bonne réputation (comme d'autres l'ont recommandé) disposant de l'infrastructure réseau ci-dessus.


Difficile de ne pas être convaincu quand vous le dites de cette façon.
Filip Dupanović

C’est un excellent résumé du consensus de l’industrie, sans exception. (Vous savez, le secteur qui tire son argent de solutions coûteuses sur-conçues, qui risquent même de ne pas donner les résultats
escomptés

À quoi sert d'avoir des serveurs DNS hautement redondants si votre hébergement est toujours non redondant?
Chris Smith

13

Pendant de nombreuses années, j'ai exploité mes propres serveurs DNS avec BIND (versions 8 et 9) sans souci majeur. J'ai stocké mes configurations dans le contrôle de version avec des vérifications post-validation qui valideraient les fichiers de zone, puis mes serveurs DNS auraient extrait les fichiers de zone à intervalles réguliers. Le problème consistait toujours à s'assurer que le numéro de série SOA était mis à jour avec chaque validation validée, sans quoi les serveurs de mise en cache ne seraient pas mis à jour.

Des années plus tard, j’ai travaillé avec djbdns car le format était idéal pour avoir des scripts automatisés pour gérer les zones et ne souffrait pas du même problème de numéro de série SOA que je n’avais à traiter avec BIND. Cependant, le fait de devoir formater certains jeux d'enregistrements de ressources pour les accepter est un problème.

Comme je trouvais que la majeure partie de mon trafic était de type DNS et que je devais maintenir un serveur DNS principal et secondaire pour satisfaire les registraires que je suis depuis passé à utiliser EasyDNS pour mes besoins DNS. Leur interface Web est facile à gérer et me donne la flexibilité dont j'ai besoin pour gérer mes ensembles de RR. J'ai également trouvé qu'il était plus facile de travailler avec ceux fournis par certains fournisseurs d'hébergement, tels que 1 & 1, qui limitent les ensembles de RR disponibles que vous pouvez entrer, ou même des bureaux d'enregistrement de domaines, tels que Network Solutions, qui ne fonctionne que si vous utilisez Windows pour gérer votre DNS.


C’est une bonne réponse honnête, mais il semble que vous vous trompiez peut-être quant au bien-fondé de votre solution: en utilisant EasyDNS, vous en faites votre seul point d’échec; votre site est peut-être déjà opérationnel, mais vos noms risquent de ne pas être résolus si votre fournisseur tiers subit une panne ou une attaque DDoS dirigée contre l'un de ses clients.
cnst le

8

Pour mes domaines personnels (et les domaines de certains amis avec lesquels j'aide), nous hébergeons notre propre DNS et mon registraire (Gandi) fournit un DNS secondaire. Ou un ami sur un autre réseau fournit secondaire. Gandi ne met pas à jour les zones immédiatement, elles semblent vérifier environ toutes les 24 heures environ, mais les modifications sont très rares. fonctionne assez bien pour nous, et leur serveur est probablement beaucoup plus fiable que le nôtre.

Dans mon travail, nous faisons notre propre DNS et notre fournisseur de réseau en amont fournit un DNS secondaire. Cependant, nous sommes une université et 99% de nos utilisateurs sont sur site; si le réseau local est en panne, peu importe si le DNS est en panne. En outre, nous avons une classe B complète (/ 16) avec environ 25 000 enregistrements DNS (plus de 25 000 enregistrements DNS inversés, bien sûr), ce qui semble un peu difficile à gérer via une interface Web. Nos serveurs DNS locaux sont hautement disponibles et rapides.


3
Nous faisons la même chose ici. Nous avons deux machines Linux exécutant BIND (une pri l'autre seconde) et notre "fournisseur de services Internet" utilise également un DNS secondaire.
l0c0b0x

1
Idem. Également avec une classe B, exécutant également nos propres serveurs DNS BIND. Et quand nous avons des problèmes de DNS, c'est généralement avec notre site
externe

Très bonne réponse; C’est ma réponse préférée à cette question jusqu’à présent, car elle repose à la fois sur de saines pratiques d’ingénierie et sur une estimation réaliste de la redondance et de la disponibilité disponibles, ainsi que sur l’expérience personnelle; Tandis que de nombreuses autres réponses énumèrent simplement leur fournisseur de DNS tiers préféré ou copient à l'aveuglette les notes rédigées par des personnes qui sont clairement en conflit d'intérêts et qui souhaitent gagner de l'argent supplémentaire grâce aux solutions trop élaborées qu'ils proposent.
cnst le

5

J'ai fait les deux. Il peut y avoir des avantages à héberger le vôtre: vous en apprendrez certainement beaucoup sur le fonctionnement du DNS lorsque votre patron vous demandera pourquoi cela prend si longtemps. De plus, vous maîtrisez mieux vos zones. Ce n'est pas toujours aussi puissant qu'il devrait l'être, en grande partie à cause de la nature distribuée hiérarchique du DNS - mais de temps en temps, cela s'avère pratique. En double donc, si vous pouvez obtenir que votre fournisseur vous alloue en tant que SOA pour le DNS inversé de votre bloc IP, en supposant que vous en ayez un.

Cependant, tous les commentaires ci-dessus sur la façon dont vous devriez vraiment avoir beaucoup de résistance aux défaillances intégrées ci-dessus vont bon train. Les serveurs dans différents centres de données dans différentes zones géographiques sont importants. Après avoir subi la coupure de courant massive dans le nord-est en 2003 - nous avons tous appris qu’avoir une boîte dans deux centres de données différents dans la même ville, ou même une province ou un État - n’était pas nécessairement suffisant. L'exaltation qui se déclenche lorsque vous réalisez vos batteries, puis les générateurs diesel sauvés de vos fesses, est rapidement remplacée par l'effroi causé par la prise de conscience que vous conduisez maintenant avec votre roue de secours.

Toutefois, j’exécute toujours notre serveur DNS interne pour le réseau local. Il peut être très utile d’avoir un contrôle complet sur le DNS que votre réseau utilise en interne - et en cas de coupure de courant dans votre bureau, votre serveur DNS interne, du fait qu’il se trouve dans le rack du serveur, est probablement alimenté par batterie ou par batterie, alors que votre PC ne le fera pas - vos clients seront donc hors ligne bien avant le serveur.


4

Je lis toutes ces solutions avec un certain amusement car nous avons réussi à nous conformer accidentellement à toutes ces "exigences" en hébergeant notre DNS primaire sur une ligne DSL statique et en demandant au bureau d'enregistrement (situé sur un autre continent) de fournir un DNS secondaire sur un serveur distant. connexion beaucoup plus sérieuse et fiable. De cette manière, nous bénéficions de toute la souplesse voulue pour utiliser bind et définir tous les enregistrements, tout en étant raisonnablement assurés que le secondaire est mis à jour pour refléter ces modifications et sera disponible en cas d'incendie, signalant un événement.

Cela remplit effectivement:
"Un minimum de deux serveurs DNS faisant autorité pour votre domaine;"
"Les serveurs DNS doivent être connectés à différents réseaux physiques et alimentations;"
"Les serveurs DNS doivent être situés dans différentes zones géographiques."


C'est certainement une approche de bien-être; mais si un trou d'homme prend feu et que toute votre infrastructure tombe en panne, sans DNS, à quoi sert-il que le DNS soit toujours disponible, alors qu'aucun des serveurs ne peut être contacté? :-) Je pense que l’embarras du DNS secondaire tiers n’a de sens que si vous sous-traitez vous-même certains autres services à d’autres tiers.
cnst le

@ cmst Le problème, c’est que lorsque DNS est en panne, tous ceux qui vous envoient un e-mail voient un problème immédiat (clients, partenaires, très mauvaise publicité). Si le DNS fonctionne et que le serveur de messagerie est en panne pendant quelques heures, la plupart du temps, ils ne remarquent rien.
Kubanczyk

@cmst DNS ne se limite pas à pointer vers les serveurs de mon réseau personnel. Je peux nommer des IP n'importe où. Par exemple, j'ai peut-être un nom pour chacune des boîtes NAT du réseau domestique de mes employés / amis. Ou je pourrais utiliser d'autres types d'enregistrement et identifier / vérifier publiquement quelque chose.
Dlamblin

4

Jetez un coup d'oeil à Dyn.com ; ils ont toutes sortes de services liés au DNS tels que l'hébergement DNS, le DNS dynamique, MailHop, etc., etc. Je les trouve fiables et les utilise depuis probablement 5 ans.


2
+1, j'utilise DynDNS depuis environ 2 ans maintenant et je suis entièrement satisfait de leur service.
cdmckay

Dyn.com était dynDNS avant environ 2013.
Knox

3

Ça dépend.

J'ai exploité mon propre DNS pour mes différents travaux depuis la fin des années 80 (BSD 4.3c). Pour le travail, j'ai toujours hébergé mon propre DNS, mais j'ai toujours eu plusieurs emplacements de centre de données ou j'ai pu échanger un DNS secondaire avec un partenaire. Par exemple, lors de mon dernier emploi, nous avons utilisé un DNS secondaire pour une autre .EDU (ils étaient situés dans le MN, nous sommes en CA) et ils ont fait de même pour nous. Diversité géographique et réseau.

Ou, à mon poste actuel, nous avons nos propres centres de données de la côte est et ouest des États-Unis. L'hébergement de notre propre DNS nous permet de mettre en place tous les enregistrements DNS inhabituels dont nous pourrions avoir besoin (SVR, TXT, etc.) et qui pourraient ne pas être pris en charge par certains services DNS de l'interface graphique. Et nous pouvons changer les TTL quand bon nous semble; nous avons pratiquement la flexibilité ultime, au prix de le faire nous-mêmes.

Pour les affaires à la maison, je l'ai fait dans les deux sens. Pour certains domaines dans lesquels je fais des choses inhabituelles ou qui nécessitent beaucoup de flexibilité, je gère toujours mes propres serveurs DNS «cachés» et échange des services DNS publics avec d'autres personnes qui font de même. J'utilise RCS pour contrôler la version des fichiers de zone pour la gestion de la configuration, afin de pouvoir consulter l'historique complet des modifications de zone au début du temps. Pour des choses simples comme un domaine avec un seul blog ou des serveurs Web génériques (un enregistrement A ou un CNAME), il est tout simplement plus facile d'utiliser un service DNS de registraire de domaine, le cas échéant, et de vous soucier de la CM.

C'est un compromis. Le contrôle et la flexibilité ultimes se font au détriment de la diversité, des serveurs multiples, des pannes matérielles / logicielles, etc. Si vous n'avez pas besoin de la flexibilité ou du contrôle total, alors l'un des fournisseurs DNS de premier plan résoudre votre problème, probablement à un coût total inférieur.


S'il est vrai qu'il est plus facile d'utiliser simplement le DNS du registrar, il n'est pas rare que le DNS d'un registrar soit en panne, alors que le registre de domaine et votre propre hôte sont opérationnels, mais que votre site n'est pas disponible, parce que vous avez ajouté un point de défaillance supplémentaire à votre configuration pour plus de facilité. Ce n'est vraiment pas difficile de faire fonctionner son propre DNS; surtout de nos jours avec la pléthore de serveurs légers et faciles à utiliser.
cnst le

3

Comme déjà mentionné dans ce fil de discussion, il existe plusieurs cas particuliers avec DNS. La différence la plus significative concerne les déploiements de serveurs de noms faisant autorité et en cache.

  1. Si vous avez besoin d'un serveur DNS uniquement pour résoudre les ressources Internet, un résolveur DNS à encaissement gratuit est un bon choix. Personnellement, j'utilise PowerDNS recursor (pdns-recursor) sous Linux.

  2. Pour desservir votre infrastructure externe, telle que les sites Web ou les MX, je n’utiliserais pas les NS internes (si nous parlons de SOHO ici). Utilisez un bon service fiable, à l’épreuve des balles, comme DNSmadeasy . J'utilise leur forfait entreprise, et il est tout à fait abordable.


De nombreuses personnes souscrivent également à l'idée d'un DJB de ne jamais exécuter un cache DNS (le résolveur récursif) sur le même système qu'un serveur DNS (le stockage de fichiers de zone). C'est pour des raisons de sécurité, afin que les trous dans l'un n'affectent pas l'autre et vice versa.
Kubanczyk

2

J'ai utilisé Zonedit ou des années. C'est bon marché (ou gratuit) et j'ai ajouté beaucoup de disques CNAME, A, MX, TXT, SRV et autres.


2

Nous avons récemment fait appel à notre DNS public en interne, alors que tous nos services étaient fournis en interne. Cela nous permet de tout mettre à jour aussi rapidement que nécessaire. Avoir un DNS géographiquement distribué n'est pas une exigence pour nous à l'heure actuelle car les serveurs Web sont tous sur le même site.


2
Votre courrier électronique est-il également hébergé sur ce site? N'oubliez pas que si vous perdez la connectivité là-bas et que le courrier électronique se trouve en dehors de ce réseau, vos enregistrements MX disparaîtront et le courrier électronique cessera de fonctionner même s'il est hébergé ailleurs. Si c'est sur le même site également, ce n'est pas un problème, mais j'ai déjà vu cet argument s'effondrer pour cette raison plusieurs fois dans le passé.
Justin Scott

1
Oui, ces gars-là utilisent leur email sur le même site (je ne suis plus dans cette entreprise).
mrdenny

2

J'ai le meilleur des deux mondes.

J'héberge mon DNS public pour mes sites Web et mes enregistrements MX "ailleurs". C'est fiable, c'est sûr, ça marche, je peux le modifier à volonté. Je paie pour le service et je suis content de la valeur.

Mais à la maison, je lance mon propre serveur DNS de mise en cache plutôt que de compter sur mon fournisseur de services Internet. Mon FAI a l'habitude de perdre le DNS, d'avoir un DNS lent, un DNS invalide et parfois, il veut pervertir le DNS afin que les échecs se produisent à des endroits qui, selon moi, pourraient m'intéresser. Je ne suis pas intéressé par l'utilisation du DNS de mon FAI. J'ai donc mes propres serveurs de mise en cache DNS et le fais moi-même. La mise en place a pris un peu d’effort au début (peut-être 2 heures), mais c’est propre et j’ai un DNS fiable. Une fois par mois, un travail cron interroge les serveurs racine et actualise la table des astuces. Peut-être une fois par an je dois le manipuler, comme envoyer doubleclick.com à 127.0.0.1 ou similaire. Autre que cela, il ne nécessite aucune intervention et cela fonctionne très bien.


Le problème avec les DNS tiers est que, même s'il est en panne, même si votre site est actif, les utilisateurs ne peuvent pas accéder à votre domaine. (Tant
pis

2

Si vous décidez d’héberger votre propre DNS pour l’amour de Dieu, vous aurez deux serveurs DNS par site. Un pour votre DNS externe, directement attaché à votre pare-feu pour que le monde vous trouve. Et un autre dans votre réseau pour votre DNS interne.


Cette pratique s'appelle split-horizon. Franchement, il ne s’applique probablement pas à la plupart des configurations, il est plutôt dépassé depuis longtemps, en dehors de la grande entreprise.
cnst

@cnst Split-horizon (ou split-view) sert différentes zones sous le même nom de domaine et XTZ n'a pas indiqué qu'il le recommandait. Un serveur interne sert généralement un nom de domaine différent (peut-être un sous-domaine).
kubanczyk

2

Je ne peux pas encore commenter, mais je fais la même chose que freiheit. Nous exploitons notre DNS principal ici dans notre zone démilitarisée et notre FAI dispose de plusieurs serveurs DNS esclaves à travers le pays qui sont mis à jour immédiatement après avoir apporté une modification au DNS primaire.

Il donne le meilleur des deux mondes. contrôle immédiat plus redondance.


2

Chaque approche présente des avantages et des inconvénients, mais je suis tout à fait en faveur de l’hébergement interne de votre DNS interne. La liste des choses sur lesquelles vous comptez pour les services réseau de base si vous l'hébergez en externe est ahurissante. Le PDG pourrait penser qu’il est judicieux de faire des économies sur les serveurs DNS en hébergeant à l’extérieur, mais que pensera-t-il s’il ne peut pas recevoir son courrier électronique si le lien Internet tombe en panne?


Super réponse, +1! Avance rapide jusqu'en 2017, pensez-vous toujours que le DNS interne est la voie à suivre? :-)
Cnst

1
@cnst ffwd to 2017 Je n'ai plus suffisamment d'expérience pour faire une recommandation.
Maximus Minimus

2

Par expérience, si vous souhaitez provoquer une attaque par déni de service, hébergez votre propre DNS. Et votre propre site web.

Je suis convaincu qu'il y a certaines choses que vous ne devriez pas faire vous-même. L'hébergement DNS en fait partie. Comme beaucoup de gens l’ont dit, vous auriez besoin de serveurs, de connexions et d’emplacements physiques redondants et vous n’auriez toujours pas besoin de la résilience même des plus petites sociétés d’hébergement.

Le principal avantage de l'hébergement de votre propre DNS est que des modifications peuvent être apportées immédiatement. Besoin de raccourcir votre durée de vie pour une prochaine migration? Vous pourriez probablement écrire un script qui le fait sur vos propres serveurs; pour les DNS hébergés, vous devrez peut-être vous connecter et modifier manuellement les enregistrements, ou pire encore, appeler le fournisseur, passer par 3 niveaux de support jusqu'à ce que vous atteigniez enfin un nom pouvant épeler DNS, juste pour leur dire qu'ils enverront le message. changements dans 2-3 jours.


2

J'exécute mon propre DNS en utilisant BIND sur des serveurs Linux. J'en ai actuellement quatre situés à Londres (Royaume-Uni), à Miami (Floride), à ​​San Jose (Californie) et à Singapour. Fonctionne très bien et j'ai un contrôle complet. La stabilité du centre de données est très importante, c'est pourquoi j'ai sélectionné de bons contrôleurs de domaine pour faire fonctionner les serveurs (qui ne dépendent pas du fournisseur de services Internet ou d'une autre infrastructure «inconnue»). Je peux configurer des serveurs DNS et d'autres services partout dans le monde en utilisant les contrôleurs de domaine de classe mondiale que je sélectionne en fonction de critères stricts. Un DNS à toute épreuve est essentiel pour les services Web et de messagerie que je gère.


LOL, super pub, puis-je avoir le numéro de votre service marketing et de son éditeur? Je suis considéré comme un candidat anti-spam évident, mais en même temps, je ne serai pas du tout surpris si ce drapeau est également refusé!
cnst le

2

Devrions-nous héberger nos propres serveurs de noms?

Oui, et vous devriez également utiliser un ou plusieurs des gros fournisseurs DNS tiers. Une solution hybride est probablement l'approche la plus sûre à long terme pour plusieurs raisons, en particulier si vous êtes une entreprise soumise à des contrats de niveau de service ou à des exigences contractuelles pour vos clients. Encore plus si vous êtes b2b.

Si vos serveurs DNS maîtres (cachés ou publics) constituent votre source de vérité, vous vous protégez de manière opérationnelle contre le verrouillage des fonctionnalités propres au fournisseur. Une fois que vous commencez à utiliser leurs fonctionnalités astucieuses qui vont au-delà du DNS de base, vous constaterez peut-être qu’il est problématique de passer à un autre fournisseur ou d’héberger votre propre DNS, car vous devez maintenant répliquer ces fonctionnalités. Des exemples sont les vérifications de l'état du site et le basculement DNS fourni par Dyn et UltraDNS. Ces fonctionnalités sont excellentes, mais doivent être considérées comme des éléments uniques et non comme une dépendance. De plus, ces fonctionnalités ne se répliquent pas bien d'un fournisseur à l'autre.

Si vous n'avez que des fournisseurs tiers, votre temps de disponibilité peut être affecté par une attaque par DDoS ciblée. Si vous ne possédez que vos propres serveurs DNS, votre temps de disponibilité peut être affecté lorsque vous êtes la cible d'une attaque DDoS.

Si vous avez un ou plusieurs fournisseurs DNS et vos propres serveurs DNS distribués asservis à des serveurs DNS maîtres cachés que vous contrôlez, vous vous assurez alors que vous n'êtes pas verrouillé par un fournisseur particulier et que vous gardez le contrôle de vos zones à tout moment. les attaques doivent détruire à la fois vos serveurs et le ou les principaux fournisseurs esclaves de vos serveurs. En deçà de cela, il y aura une dégradation du service par rapport à une panne critique.

Un autre avantage de disposer de vos propres serveurs maîtres (idéalement cachés, non publiés) est que vous pouvez créer votre propre API et les mettre à jour de la manière qui vous convient le mieux. Avec les fournisseurs DNS tiers, vous devrez vous adapter à leur API. Chaque fournisseur a son propre; ou dans certains cas, a juste une interface Web.

De plus, si votre maître est sous votre contrôle et qu'un fournisseur a un problème, alors l'un de vos serveurs esclaves pouvant toujours atteindre votre maître obtiendra les mises à jour. C’est quelque chose que vous souhaiteriez avoir après avoir réalisé qu’avoir une tierce partie en tant que maître était une erreur lors d’un incident majeur avec DDoS et que vous ne parveniez pas à changer les serveurs des fournisseurs qui ne sont pas attaqués.

D'un point de vue juridique, empêcher le blocage du fournisseur peut également être important pour votre entreprise. Par exemple, Dyn est potentiellement acheté par Oracle. Cela les place dans une position unique pour collecter des statistiques DNS sur tous les clients de Dyn. Cela présente des aspects concurrentiels susceptibles d’introduire un risque juridique. Cela dit, je ne suis pas avocat, vous devriez donc consulter vos équipes juridiques et de relations publiques à ce sujet.

Il existe de nombreux autres aspects de ce sujet si nous voulons creuser dans les mauvaises herbes.

[Éditer] S'il ne s'agit que d'un petit domaine personnel / hobby, alors 2 ordinateurs virtuels qui ne sont pas dans le même centre de données que l'autre, exécuter un petit démon DNS est largement suffisant. Je le fais pour mes propres domaines personnels. Il n'était pas clair pour moi si votre domaine signifiait une entreprise ou juste pour un passe-temps. Quelle que soit la plus petite machine virtuelle que vous puissiez obtenir, elle est plus que suffisante. J'utilise rbldnsd pour mes domaines; en utilisant un TTL très élevé sur mes disques, car il prend 900 Ko de RAM et peut gérer tous les abus que les gens lui infligent.


Bien que trop centré sur l'entreprise, c'est une bonne réponse raisonnable, celui qui a donné le -1 peut-il s'expliquer?
cnst le

Deux points nouveaux sur l’API et les fusions de fournisseurs. Deux contrôleurs de domaine sont acceptables, mais notez également que chaque fournisseur de services Internet est distinct, et non le même.
Kubanczyk

Bon point @kubanczyk muiltiple ingres des liens sûrs et des contrôles de basculement et d’intégrité automatisés.
Aaron

1

Pensez à l'hébergement DNS comme base de vos services publics. Dans mon cas, le courrier électronique est essentiel à notre activité. Si vous hébergez votre DNS en interne et que votre connexion Internet ralentit, vos enregistrements DNS peuvent devenir obsolètes, forçant votre domaine à être indisponible.

Donc, dans mon cas, si un enregistrement MX ne peut pas être trouvé pour notre domaine, le courrier électronique est immédiatement rejeté.

Donc, j'ai notre DNS hébergé en externe.

Si l'enregistrement MX est disponible, mais que notre connexion Internet est en panne, le courrier continuera à être mis en file d'attente sur les serveurs tentant d'envoyer un courrier électronique à notre domaine.


Je ne pense pas que cela soit vrai en ce qui concerne les MXenregistrements; En fait, c'est l'une des idées fausses documentées à l' adresse cr.yp.to/djbdns/third-party.html .
cnst le

0

Ça dépend. ™

Je gère mes propres serveurs et gère des domaines depuis au moins 2002.

J'ai souvent utilisé le serveur DNS de mon fournisseur.

Le nombre de fois où mon serveur sur mon adresse IP était disponible, mais pas mon DNS, était un peu trop.

Voici mes histoires de guerre:

  • Un grand fournisseur à Moscou (l'un des premiers basés sur VZ) avait mon VPS dans un centre de distribution "économique" pas cher, mais ses DNS étaient dans un centre de distribution haut de gamme avec un trafic coûteux, en deux différents / 24 sous-réseaux, comme le demandaient certains TLD à l’époque . À un moment donné, un désastre a frappé (peut-être la coupure de courant de 2005? ), Et leur coûteux DC a été mis hors ligne, et mon site (toujours à Moscou, mais dans un "valeur" DC) n'est accessible que par son adresse IP.

    Il est intéressant de noter que, même avant tout incident, je me souviens clairement de ce que je faisais tracerouteet, remarquant le même contrôleur de domaine pour mon fournisseur d’accès ns1et celui ns2de mon fournisseur d’accès Internet, leur demandant d’en changer un pour «mon» contrôleur de domaine, également, pour géo-redondance; ils ont rejeté l'idée de la géo-redondance, car les serveurs étaient déjà dans le centre de distribution le plus haut de gamme possible.

  • J'ai eu un autre fournisseur (l'un des premiers fournisseurs ISPsystem), où il y en avait un sur site et un autre à l'étranger. Bref, toute l’installation était ridiculement boguée et le serveur "étranger" échouait souvent à maintenir ses zones. Mon domaine avait donc un point de défaillance supplémentaire et ne serait pas accessible même si tout mon serveur fonctionnait sans problème.

  • J'ai eu un registraire qui exploitait son propre réseau. Il a diminué de temps en temps, même si mes serveurs hors site étaient en hausse. Mon DNS était en panne.

  • J'ai récemment utilisé plusieurs grands fournisseurs de cloud pour le secondaire, où je dirigeais moi-même un maître caché. Les deux fournisseurs ont changé leur configuration au moins une fois. jamais avec des annonces publiques; certains de mes domaines ont cessé de se résoudre. Arrivé chez un de mes amis aussi avec l'un des mêmes fournisseurs. Cela se produit plus souvent avec des services tiers que les gens ne veulent admettre en public.

En bref, http://cr.yp.to/djbdns/third-party.html est tout à fait correct sur le sujet.

Les coûts liés aux DNS tiers ne valent souvent pas les avantages.

Les inconvénients d'avoir un tiers DNS sont souvent injustement négligés.

Je dirais que, sauf si votre domaine utilise déjà des services tiers (par exemple, pour le Web, la messagerie, la voix ou le texte), ajouter un DNS tiers serait presque toujours contre-productif et ne constituerait en aucun cas la meilleure pratique. .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.