Devrions-nous héberger nos propres serveurs de noms?
Il s'agit d'une question canonique sur l'opportunité d'externaliser la résolution DNS pour ses propres domaines
Mon FAI fournit actuellement un DNS pour mon domaine, mais ils imposent des limitations sur l'ajout d'enregistrements. Par conséquent, je pense à exécuter mon propre DNS.
Préférez-vous héberger votre propre DNS ou est-il préférable que votre FAI le fasse?
Existe-t-il des alternatives que je peux étudier?
Je ne dirigerais pas mon propre serveur DNS - dans mon cas, la société d'hébergement qui héberge mon site Web fournit un service DNS gratuit. Il existe également des alternatives, des entreprises qui ne font que l'hébergement DNS ( DNS Made Easy vient à l'esprit, mais il y en a beaucoup d'autres) qui sont le genre de chose que vous devriez probablement examiner.
La raison pour laquelle je ne le ferais pas moi-même est que le DNS est censé être assez fiable, et à moins d'avoir un réseau de serveurs géographiquement distribué, 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 d'en démarrer un nouveau.
Nous hébergeons toujours notre propre DNS (DNS inverse préférable également). Cela nous permet d'apporter des modifications d'urgence sans dépendre d'un tiers. Si vous disposez de plusieurs emplacements, il est facile de configurer un niveau de redondance accessible pour vos serveurs DNS.
Si vous n'avez pas plusieurs sites, je considérerais quelqu'un qui fait spécifiquement l'hébergement DNS (PAS votre FAI) avec une interface Web pour les changements. Recherchez également une prise en charge 24h/24 et 7j/7 et des SLA décents.
Pour une bonne configuration DNS fiable pour votre (vos) domaine (s), vous devriez avoir ...
- Un minimum de deux serveurs DNS autorisés pour votre domaine;
- Les serveurs DNS doivent être connectés à différents réseaux physiques et alimentations;
- Les serveurs DNS doivent se trouver dans différentes zones géographiques.
Comme il est peu probable que vous ayez accès à l'infrastructure réseau ci-dessus, il vaut mieux choisir un fournisseur d'hébergement DNS réputé (comme d'autres l'ont recommandé) qui possède l'infrastructure réseau ci-dessus.
Pendant de nombreuses années, j'ai géré mes propres serveurs DNS en utilisant BIND (versions 8 et 9) sans tracas 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 ont extrait les fichiers de zone à intervalles réguliers. Le problème était toujours de s'assurer que le numéro de série SOA était mis à jour avec chaque commit qui était expulsé, sinon 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 SOA numéro de série que j'ai dû gérer avec BIND. Il l'a fait cependant ont leurs propres problèmes avec le formatage de certains jeux d'enregistrements de ressources pour les faire accepter.
Comme j'ai découvert qu'une grande partie de mon trafic était DNS et que je devais maintenir un serveur DNS principal et secondaire pour satisfaire les bureaux d'enregistrement, j'ai depuis utilisé 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 RR. J'ai également trouvé qu'il était facile de travailler avec ceux fournis par certains fournisseurs d'hébergement comme 1 & 1 qui limitent les ensembles de RR disponibles que vous pouvez entrer, ou même les registraires de domaine comme Network Solutions qui ne fonctionne que si vous utilisez Windows pour gérer votre DNS.
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 changements sont très peu fréquents; 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 place; si le réseau local est en panne, peu importe si le DNS est en panne. De plus, nous avons une classe B (/ 16) complète avec environ 25 000 enregistrements DNS (plus 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 très rapides.
J'ai fait les deux. L'hébergement du vôtre peut présenter des avantages: vous en apprendrez certainement beaucoup sur le fonctionnement du DNS lorsque votre patron vous demande pourquoi cela prend autant de temps. De plus, vous contrôlez beaucoup plus vos zones. Ce n'est pas toujours aussi puissant qu'il devrait l'être, en grande partie en raison de la nature distribuée hiérarchique du DNS - mais de temps en temps, cela s'avère utile. Doublement donc si vous pouvez demander à votre fournisseur de vous allouer en tant que SOA pour le DNS inverse 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és ci-dessus sont frappants. Les serveurs de différents centres de données dans différentes zones géographiques sont importants. Après avoir réussi à traverser la panne de courant massive dans le Nord-Est en 2003 - nous avons tous appris qu'avoir un boîtier dans deux centres de données différents dans la même ville, ou même province ou état - n'est pas nécessairement une protection suffisante. L'exaltation qui se déclenche lorsque vous réalisez vos batteries, puis les générateurs diesel ont sauvé vos fesses est rapidement remplacée par l'effroi causé par la prise de conscience que vous conduisez maintenant avec votre roue de secours.
Cependant, je gère toujours notre serveur DNS interne pour le LAN. Il peut être très pratique d'avoir un contrôle total sur le DNS que votre réseau utilise en interne - et si le courant se coupe dans votre bureau, votre serveur DNS interne du fait qu'il est dans le rack de serveur est probablement sur batterie ou batterie et diesel, alors que votre PC ne le fera pas - vos clients seront donc hors ligne bien avant que le serveur ne le soit.
Je lis toutes ces solutions avec un certain amusement parce que nous avons réussi à nous adapter accidentellement à toutes ces "exigences" en hébergeant notre DNS principal sur une ligne DSL statique et en demandant au registraire (qui était sur un autre continent) de fournir un DNS secondaire sur un connexion beaucoup plus sérieuse et fiable. De cette façon, nous obtenons toute la flexibilité de l'utilisation de la liaison et de la définition de tous les enregistrements tout en étant raisonnablement assurés que le secondaire est mis à jour pour refléter ces changements et sera disponible en cas de trou d'homme prenant feu, pour citer un événement.
Cela remplit efficacement:
"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 se trouver dans différentes zones géographiques."
Jetez un 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 ai trouvés fiables et les utilise depuis probablement 5 ans.
Ça dépend.
J'ai exécuté 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 fait du DNS secondaire pour un autre .EDU (ils étaient dans le MN, nous sommes en Californie), et ils ont fait la même chose pour nous. Diversité géographique et réseau.
Ou, dans mon travail actuel, nous avons nos propres centres de données sur la côte est et ouest (É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.) qui pourraient ne pas être pris en charge par certains services DNS GUI. Et, nous pouvons changer les TTL à tout moment; nous avons à peu près la flexibilité ultime, au prix de le faire nous-mêmes.
Pour les trucs maison, je l'ai fait dans les deux sens. Pour certains domaines où je fais des choses inhabituelles ou qui ont besoin de beaucoup de flexibilité, je gère toujours mes propres serveurs DNS maîtres "cachés" et échange des services DNS publics avec d'autres qui font de même. J'utilise RCS pour contrôler les versions des fichiers de zone de zone pour la gestion de la configuration, afin que je puisse voir l'historique complet des changements de zone depuis le début des 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 lorsqu'il est disponible et vous inquiétez maintenant pour CM.
C'est un compromis. Le contrôle et la flexibilité ultimes se font au détriment de la gestion de la diversité par vous-même, de l'exécution de plusieurs serveurs, de la gestion 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.
Comme déjà mentionné dans ce fil, il existe plusieurs cas particuliers avec DNS, la différence la plus significative est entre les déploiements de serveur de noms faisant autorité et la mise en cache.
Si vous avez besoin d'un serveur DNS uniquement pour résoudre les ressources Internet, un résolveur DNS d'encaissement gratuit est un choix judicieux. J'utilise personnellement le récurseur PowerDNS (pdns-recursor) sous Linux.
Pour l'entretien de votre infrastructure externe, comme les sites Web ou les MX, je n'utiliserais pas de NS internes (si nous parlons de SOHO ici). Utilisez un bon service fiable et à l'épreuve des balles comme DNSmadeasy . J'utilise leur forfait professionnel, et ça marche tout en étant très abordable.
Devrions-nous héberger nos propres serveurs de noms?
Oui, et vous devez également utiliser un ou plusieurs des plus grands fournisseurs DNS tiers. Une solution hybride est probablement l'approche à long terme la plus sûre pour plusieurs raisons, surtout si vous êtes une entreprise qui a un manoir de SLA ou des exigences contractuelles pour vos clients. Encore plus si vous êtes B2B.
Si vos serveurs DNS maîtres (cachés ou publics) sont votre source de vérité, vous vous protégez opérationnellement de ne pas être enfermé dans des capacités spécifiques au fournisseur. Une fois que vous commencez à utiliser leurs fonctionnalités astucieuses qui vont au-delà du DNS de base, vous pouvez constater que le passage à un autre fournisseur ou l'hébergement de votre propre DNS est problématique, car vous devez maintenant répliquer ces capacités. Les exemples seraient les vérifications de l'état du site et le basculement DNS fournis par Dyn et UltraDNS. Ces fonctionnalités sont excellentes, mais doivent être considérées comme ponctuelles et non comme une dépendance. Ces fonctionnalités ne se répliquent pas non plus correctement d'un fournisseur à l'autre.
Si vous n'avez que des fournisseurs tiers, votre disponibilité peut être affectée lorsqu'ils font l'objet d'une attaque DDoS ciblée. Si vous ne disposez que de vos propres serveurs DNS, votre disponibilité peut être affectée lorsque vous êtes la cible d'une attaque DDoS.
Si vous avez un ou plusieurs fournisseurs DNS et vos propres serveurs DNS distribués qui asservissent aux serveurs DNS maîtres cachés que vous contrôlez, vous vous assurerez que vous n'êtes pas enfermé dans un fournisseur particulier et que vous gardez le contrôle de vos zones à tout moment et que les attaques doivent détruire à la fois vos serveurs et le ou les principaux fournisseurs esclaves de vos serveurs. Tout ce qui est inférieur à cela sera une dégradation du service par rapport à une panne critique.
Un autre avantage d'avoir 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 dans le manoir qui convient aux besoins de votre entreprise. Avec les fournisseurs DNS tiers, vous devrez vous adapter à leur API. Chaque vendeur a le sien; ou dans certains cas, a juste une interface utilisateur Web.
De plus, si votre maître est sous votre contrôle et qu'un vendeur a un problème, alors n'importe lequel de vos serveurs esclaves qui peuvent encore atteindre votre maître recevra les mises à jour. C'est quelque chose que vous souhaiteriez avoir après avoir réalisé que le fait d'avoir un tiers comme maître était une erreur lors d'un gros incident DDoS et que vous ne pouvez pas changer les serveurs des fournisseurs qui ne sont pas attaqués.
D'un point de vue juridique, la prévention du blocage des fournisseurs peut également être importante pour votre entreprise. Par exemple, Dyn est potentiellement acheté par Oracle. Cela les place dans une position unique pour recueillir des statistiques DNS sur tous les clients de Dyn. Il existe des aspects concurrentiels qui peuvent introduire un risque juridique. Cela dit, je ne suis pas avocat, vous devriez donc consulter vos équipes juridiques et RP à ce sujet.
Il y a beaucoup d'autres aspects à ce sujet si nous voulions creuser dans les mauvaises herbes.
[Modifier] Si cela est juste pour un petit domaine personnel/hobby, alors 2 machines virtuelles qui ne sont pas dans le même centre de données que l'autre, exécuter un petit démon DNS est plus que 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 le hobby. Quelle que soit la plus petite machine virtuelle que vous pouvez obtenir, c'est plus que suffisant. J'utilise rbldnsd pour mes domaines; en utilisant un très haut TTL sur mes enregistrements, car il prend 900 Ko de RAM et peut gérer tout abus que les gens lui jettent.
Nous avons récemment apporté notre DNS public en interne lorsque nous avons apporté tous nos services 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 pour le moment car les serveurs Web sont tous dans le même site.
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 satisfait de la valeur.
Mais à la maison, je gère mon propre serveur DNS de mise en cache plutôt que de compter sur mon FAI. Mon FAI a l'habitude de perdre le DNS, d'avoir un DNS lent, un DNS invalide, et parfois il veut pervertir le DNS pour que les pannes se rendent à des endroits qui pourraient m'intéresser. Je ne suis pas intéressé à utiliser le DNS de mon FAI. J'ai donc mes propres serveurs DNS de mise en cache et je le fais moi-même. C'était un peu d'effort à mettre en place au début (peut-être 2 heures), mais c'est propre et j'ai un DNS fiable. Une fois par mois, une tâche cron interroge les serveurs racine et actualise la table des indices. Peut-être qu'une fois par an je dois jouer avec, comme envoyer doubleclick.com à 127.0.0.1 ou similaire. En dehors de cela, cela ne nécessite aucune intervention et cela fonctionne très bien.
Si vous décidez d'héberger votre propre DNS pour l'amour de Dieu, ayez DEUX serveurs DNS par site. Un pour votre DNS externe, directement connecté à votre pare-feu pour que le monde vous trouve. Et un autre dans votre réseau pour votre DNS interne.
J'exécute mon propre DNS en utilisant BIND sur des serveurs Linux. J'en ai actuellement quatre à Londres au Royaume-Uni, à Miami FL, à San Jose CA 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 exécuter les serveurs (ne dépendant pas du FAI 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 solide comme le roc est essentiel pour les services de messagerie et Web que j'exécute.
Je ne peux pas encore commenter, mais je fais la même chose que freiheit. Nous exécutons notre DNS principal ici dans notre DMZ, et notre FAI dispose de plusieurs serveurs DNS esclaves dans tout le pays qui sont mis à jour immédiatement après avoir effectué une modification sur le DNS principal.
Il donne le meilleur des deux mondes; contrôle immédiat plus redondance.
Il y a des avantages et des inconvénients à chaque approche, mais je préfère vraiment héberger votre DNS interne en interne. La liste des choses dont vous dépendez pour les services réseau de base si vous l'hébergez en externe est ahurissante. Le PDG pourrait penser qu'il est judicieux d'économiser de l'argent sur les serveurs DNS en hébergeant en externe, mais que pensera-t-il lorsqu'il ne pourra pas recevoir ses e-mails si le lien Internet tombe en panne?
Par expérience, si vous souhaitez attirer une attaque par déni de service, hébergez votre propre DNS. Et votre propre site Web.
Je crois 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'apprécieriez toujours pas la résilience même des plus petites sociétés d'hébergement.
Le plus grand avantage de l'hébergement de votre propre DNS est que des modifications peuvent être apportées immédiatement. Besoin de raccourcir vos TTL pour une prochaine migration? Vous pourriez probablement écrire un script qui fait cela sur vos propres serveurs; pour le DNS hébergé, 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 quelqu'un qui peut épeler DNS, juste pour qu'ils vous disent qu'ils soumettront le change en 2-3 jours.
J'ai utilisé Zonedit ou des années. Son bon marché (ou gratuit) et j'ai ajouté beaucoup de CNAME, A, MX, TXT, SRV et d'autres enregistrements.
Considérez l'hébergement DNS comme la base de vos services publics. Dans mon cas, le courrier électronique est essentiel pour notre entreprise. Si vous hébergez votre DNS en interne et que votre connexion Internet est défaillante, 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, l'e-mail 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 à faire la queue sur les serveurs essayant d'envoyer des courriels à notre domaine.
Cela dépend. ™
J'exécute 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 IP était disponible, mais pas mon DNS, était un peu trop.
Voici mes histoires de guerre:
Un énorme fournisseur à Moscou (l'un des premiers basés sur VZ) avait mon VPS dans un DC "value" bon marché, mais leur DNS était dans un état de l'art premium DC avec un trafic coûteux, dans deux sous-réseaux différents/24, comme cela était requis par certains TLD à l'époque . À un moment donné, une catastrophe a frappé (peut-être la panne de courant de 2005? ), et leur cher DC est hors ligne, et mon site (toujours à Moscou, mais dans une "valeur" DC) était accessible uniquement par son adresse IP.
Fait intéressant, même avant tout incident, je me souviens clairement d'avoir fait
tracerouteet d'avoir remarqué la même chose DC pour les deuxns1etns2de mon FAI, en leur demandant d'en déplacer un aussi sur "mon" DC pour la géo-redondance; ils ont rejeté l'idée de la géo-redondance, car les serveurs étaient déjà dans le plus haut de gamme DC possible.J'ai eu un autre fournisseur (l'un des premiers basés sur ISPsystem), où ils avaient un ns sur place et un autre à l'étranger. Pour faire court, toute la configuration était ridiculement boguée et le serveur "à l'étranger" échouait souvent à maintenir ses zones, donc mon domaine avait effectivement un point de défaillance supplémentaire et ne serait pas accessible même si mon serveur entier fonctionnait toujours correctement.
J'ai eu un registraire qui dirigeait son propre réseau. Il a baissé 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 dirigerais moi-même un maître caché. Les deux fournisseurs ont modifié leur configuration au moins une fois; jamais avec des annonces publiques; certains de mes domaines ont cessé de se résoudre. C'est arrivé à un ami à moi aussi, avec l'un des mêmes fournisseurs. Cela se produit plus souvent avec des services tiers que les gens ne veulent l'admettre en public.
En bref, http://cr.yp.to/djbdns/third-party.html est absolument correct sur le sujet.
Les coûts liés à l'utilisation de DNS tiers ne valent souvent pas les avantages.
Les inconvénients d'avoir un DNS tiers sont souvent injustement négligés.
Je dirais qu'à moins que votre domaine utilise déjà des services tiers (par exemple, pour le Web, la messagerie, la voix ou le texte), l'ajout d'un DNS tiers serait presque toujours contre-productif et n'est en aucun cas la meilleure pratique en toutes circonstances. .