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?

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.

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.

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.

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.

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.

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.

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."

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.

Ç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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

Ç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. .