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.