Il s'agit d'un Question canonique sur l'opportunité d'externaliser la résolution DNS de ses propres domaines.
Mon FAI fournit actuellement les DNS pour mon domaine, mais il impose des limites à l'ajout d'enregistrements. J'envisage donc de gérer mes propres DNS.
Préférez-vous héberger vos propres DNS, ou est-il préférable que votre fournisseur d'accès le fasse ?
Existe-t-il des alternatives que je peux examiner ?
Devrions-nous héberger nos propres serveurs de noms ?
はい。 y vous devriez également utiliser un ou plusieurs des grands fournisseurs DNS tiers. Une solution hybride est probablement l'approche la plus sûre à long terme pour de multiples raisons, en particulier si vous êtes une entreprise qui a un certain type de SLA ou d'exigences contractuelles envers vos clients. C'est encore plus vrai si vous êtes une entreprise B2B.
Si vos serveurs DNS maîtres (cachés ou publics) sont votre source de vérité, vous vous protégez sur le plan opérationnel en évitant de vous enfermer dans les capacités spécifiques d'un fournisseur. Une fois que vous commencez à utiliser leurs fonctions astucieuses qui vont au-delà du DNS de base, vous pouvez trouver que le passage à un autre fournisseur ou l'hébergement de votre propre DNS est problématique, car vous devez maintenant reproduire ces capacités. Par exemple, les contrôles de santé du site et le basculement DNS que Dyn et UltraDNS proposent. Ces fonctionnalités sont excellentes, mais elles doivent être considérées comme uniques et non comme une dépendance. De plus, ces fonctionnalités ne sont pas bien reproduites d'un fournisseur à l'autre.
Si vous n'avez que des fournisseurs tiers, votre temps de fonctionnement peut être affecté lorsqu'ils subissent une attaque DDoS ciblée. Si vous n'avez que vos propres serveurs DNS, votre temps de fonctionnement peut être affecté si vous êtes la cible d'une attaque DDoS.
Si vous disposez d'un ou de plusieurs fournisseurs DNS et de vos propres serveurs DNS distribués qui s'asservissent à des serveurs DNS maîtres cachés que vous contrôlez, vous vous assurez de ne pas être lié à un fournisseur particulier, de garder le contrôle de vos zones à tout moment et de faire en sorte que les attaques mettent hors service à la fois vos serveurs et le ou les principaux fournisseurs qui s'asservissent à vos serveurs. Dans le cas contraire, il s'agira d'une dégradation du service plutôt que d'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 construire votre propre API et les mettre à jour de la manière qui convient le mieux à vos besoins commerciaux. Avec les fournisseurs de DNS tiers, vous devrez vous adapter à leur API. Chaque fournisseur dispose de sa propre API ou, dans certains cas, d'une simple interface utilisateur Web.
En outre, si votre maître est sous votre contrôle et qu'un fournisseur a un problème, tous vos serveurs esclaves qui peuvent encore atteindre votre maître recevront les mises à jour. C'est quelque chose que vous souhaiterez avoir après avoir réalisé que le fait d'avoir un tiers comme maître était une erreur lors d'un important incident DDoS et que vous ne pouvez modifier aucun des serveurs des fournisseurs qui ne sont pas attaqués.
D'un point de vue juridique, il peut également être important pour votre entreprise d'empêcher le verrouillage du fournisseur. Par exemple, Dyn est en passe d'être racheté par Oracle. Ce dernier se trouve donc dans une position unique pour recueillir les statistiques DNS de tous les clients de Dyn. Il y a des aspects concurrentiels de cette situation qui peuvent introduire un risque juridique. Cela dit, je ne suis pas juriste, vous devez donc consulter vos équipes juridiques et de relations publiques à ce sujet.
Il y a beaucoup d'autres aspects à ce sujet si nous voulions creuser dans les mauvaises herbes.
[Edit] S'il ne s'agit que d'un petit domaine personnel ou de loisir, deux machines virtuelles qui ne se trouvent pas dans le même centre de données et qui exécutent un petit démon DNS sont plus que suffisantes. C'est ce que je fais pour mes domaines personnels. Je n'ai pas compris si votre domaine était destiné à une entreprise ou à un simple hobby. Les plus petites VM que vous pouvez obtenir sont plus que suffisantes. J'utilise rbldnsd pour mes domaines ; j'utilise un TTL très élevé sur mes enregistrements, car il prend 900 KB de ram et peut supporter tous les abus que les gens lui font subir.
Nous avons récemment internalisé notre DNS public lorsque nous avons internalisé tous nos services. Cela nous permet de tout mettre à jour aussi rapidement que nécessaire. Pour l'instant, nous n'avons pas besoin d'avoir des DNS géographiquement distribués, car les serveurs Web se trouvent tous sur le même site.
J'ai le meilleur des deux mondes.
J'héberge mes DNS publics pour mes sites web et mes enregistrements MX "ailleurs". C'est fiable, c'est sûr, ça fonctionne, je peux le modifier à volonté. Je paie pour ce service et je suis satisfait de sa valeur.
Mais à la maison, je gère mon propre serveur DNS de mise en cache plutôt que de dépendre de mon FAI. Mon FAI a l'habitude de perdre des DNS, d'avoir des DNS lents, des DNS invalides, et parfois ils veulent pervertir les DNS pour que les échecs aillent à des endroits qu'ils pensent pouvoir m'intéresser. Je n'ai pas envie d'utiliser les DNS de mon FAI. J'ai donc mes propres serveurs DNS de mise en cache et je le fais moi-même. La mise en place a demandé un peu d'effort au début (peut-être 2 heures), mais c'est propre et j'ai des DNS fiables. Une fois par mois, une tâche cron interroge les serveurs racine et rafraîchit la table des hints. Une fois par an peut-être, je dois faire des manipulations, comme envoyer doubleclick.com vers 127.0.0.1 ou autre. En dehors de cela, cela ne nécessite aucune intervention et cela fonctionne très bien.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
