Logo Zéphyrnet

Les grandes entreprises devraient-elles héberger elles-mêmes leur DNS faisant autorité ? –Blog IBM

Date :


Les grandes entreprises devraient-elles héberger elles-mêmes leur DNS faisant autorité ? –Blog IBM



jeune chantant avec des écouteurs tout en travaillant sur un ordinateur portable à la maison

Dans un post récent, nous avons décrit les pièges du système de noms de domaine (DNS) auto-hébergé du point de vue d'une start-up ou d'une entreprise de taille moyenne qui assemblait un système DIY utilisant LIER DNS ou d'autres outils open source. L’idée principale était que chaque entreprise arrive à un point où elle devient trop grande pour ses systèmes DNS auto-hébergés et faisant autorité. Quelle que soit la raison (qu'il s'agisse de fonctionnalité, de coût, de fiabilité ou de ressources), la plupart des entreprises se tournent naturellement vers le besoin d'un DNS géré service rendu par un tiers.

Néanmoins, il existe une certaine classe de grandes entreprises dans lesquelles le DNS faisant autorité auto-hébergé fonctionne selon un type de logique différent. Avec une présence mondiale et une échelle suffisante pour résoudre des projets techniques même complexes en interne, ces types d'entreprises choisissent souvent par défaut d'élaborer des solutions au lieu d'acheter le produit d'une autre entreprise.

Les avantages de l’auto-hébergement pour les grandes entreprises

Il existe plusieurs raisons pour lesquelles une grande entreprise souhaiterait créer et héberger elle-même un service DNS faisant autorité :

Exigences fonctionnelles spécifiques: Les grandes entreprises souhaitent souvent proposer leurs applications, services et contenus de manière personnalisée. Cela peut aller du routage hyper-spécifique des requêtes DNS à la prise en charge au niveau du système d'architectures d'applications distinctes, en passant par les exigences de conformité.

Utiliser les ressources existantes: Lorsque les entreprises disposent déjà de serveurs et de ressources techniques déployés à grande échelle dans le monde entier, utiliser cette empreinte pour fournir un DNS faisant autorité semble souvent être la prochaine étape logique.

Control: Certaines entreprises ne veulent tout simplement pas dépendre d'un fournisseur, en particulier pour quelque chose d'aussi critique que le DNS faisant autorité. D’autres entreprises ont une culture du « build it » qui valorise le développement d’approches internes favorisant les compétences techniques.

Théorie contre réalité

Ce sont toutes des raisons valables pour auto-héberger votre DNS à grande échelle, du moins en théorie. Ce que nous avons constaté en discutant avec de grandes entreprises de divers secteurs, c'est que les avantages perçus du DNS faisant autorité auto-hébergé restent souvent inexploités. La logique derrière l'auto-hébergement semble bonne sur un PowerPoint, mais n'apporte pas de valeur commerciale réelle.

Voici quelques domaines dans lesquels la réalité du DNS faisant autorité auto-hébergé ne correspond pas à la théorie :

et la résilience: Toute grande entreprise est probablement suffisamment importante pour que tout temps d'arrêt ait un impact dévastateur sur ses résultats. C'est pourquoi la plupart des administrateurs DNS faisant autorité insistent sur une option secondaire ou de basculement en cas de catastrophe. Les DNS faisant autorité auto-hébergés incluent rarement cela : la construction et la maintenance d'un système secondaire comme forme d'assurance nécessitent trop de ressources.

Architectures fragiles: La plupart des infrastructures DNS faisant autorité sont construites sur BIND, qui nécessite généralement une machine de scripts Rube Goldberg pour fonctionner. Au fil du temps, la complexité de ces scripts peut devenir difficile à maintenir à mesure que vous tenez compte de nouvelles fonctionnalités et exigences opérationnelles. Un faux mouvement, comme une seule erreur de codage, pourrait facilement faire tomber l’ensemble de votre infrastructure DNS faisant autorité et mettre hors ligne vos sites destinés aux clients. Pour une grande entreprise complexe, les architectures et scripts BIND fragiles peuvent être particulièrement périlleux.

Dette technique: Lorsque vous exécutez votre propre DNS faisant autorité, il est facile d'accumuler un retard important de demandes de fonctionnalités. Cela est particulièrement vrai si votre équipe DevOps, NetOps ou CloudOps travaille dans le respect d'un délai. Soyons réalistes : la plupart de ces fonctionnalités DNS seront fournies dans un délai beaucoup plus long que celui requis par n'importe quelle équipe de développement d'applications.

Prix: Une grande entreprise auto-hébergée a peut-être fait le calcul et conclu que la création, le déploiement et la maintenance d'un système DNS faisant autorité en valaient la peine. Cependant, la réalité est que ces décisions sont généralement prises sans une analyse coûts-avantages délibérée. À long terme, le coût de la dépense ainsi que les coûts d’opportunité cachés d’un DNS faisant autorité auto-hébergé ont tendance à dépasser tout avantage financier perçu.

Roulement de personnel: Les architectures DIY ne fonctionnent que tant que la personne (ou l'équipe) qui les a construites reste dans l'entreprise. Si cette personne quitte l’entreprise pour une raison quelconque, ses connaissances institutionnelles sur la façon dont les architectures DIY ont été construites partent avec elle. Certaines entreprises en arrivent au point où elles ont peur de changer quoi que ce soit, car cela pourrait facilement entraîner un incident de temps d'arrêt dont il serait difficile de se remettre.

Automation: BIND n'a pas d'interface de programmation d'application (API) et n'a pas été conçu pour prendre en charge aucune forme d'automatisation. Les architectures DIY ne sont généralement pas conçues pour prendre en charge les plates-formes d'automatisation standard comme Ansible ou Terraform. Il est presque impossible d'orchestrer des architectures DIY à l'aide d'outils tiers. Si vous disposez d'un DNS faisant autorité, vous êtes probablement confronté à des modifications manuelles qui ralentissent considérablement les efforts de développement d'applications.

Le DNS géré est tout simplement logique

En tant que fournisseur de solutions DNS gérées, nous sommes certainement partiaux. Cependant, de notre point de vue, les inconvénients d’un DNS faisant autorité auto-hébergé l’emportent clairement sur les avantages, même (ou surtout) pour les grandes entreprises qui construisent généralement par défaut leurs propres systèmes. Lorsque vous pesez le coût à long terme du maintien d’un système DNS faisant autorité (à la fois le matériel CapEx et le personnel OpEx), une solution DNS gérée est tout simplement logique sur le plan économique.

Solutions DNS gérées aident également les équipes informatiques à faire plus avec moins. Si l’on considère les heures d’administration nécessaires pour exploiter un réseau DNS faisant autorité à grande échelle, il est bien plus utile de diriger ces ressources vers d’autres priorités stratégiques. Ayant nous-mêmes exploité un DNS faisant autorité pour le compte d’une bonne partie d’Internet pendant 10 ans, nous savons à quel point cela peut être une tâche coûteuse et ardue.

Gérer le risque de migration DNS

Nous avons compris. C'est difficile de changer. Même lorsque les grandes entreprises sont prêtes à abandonner leurs architectures DNS auto-hébergées faisant autorité, elles rechignent souvent face aux risques importants liés à la migration vers un service DNS géré. Lorsque les outils DNS existants sont ancrés dans l’ADN technique d’une entreprise, il peut être difficile de penser au réseau complexe de dépendances qui devraient changer.

C’est là que le DNS secondaire offre une bouée de sauvetage. Tout service DNS géré (comme NS1) peut fonctionner aux côtés d'un système DNS faisant autorité auto-hébergé, soit en tant que plate-forme indépendante, soit en tant qu'option de basculement. Avec une couche DNS secondaire en place, les administrateurs peuvent migrer les charges de travail des applications au fil du temps, tester les capacités du système géré et dénouer progressivement les connexions complexes aux systèmes internes.

L'exploitation d'un DNS secondaire comme environnement de test renforce également la confiance dans les fonctionnalités avancées qu'offre un service DNS géré, par exemple direction du trafic, Apis, l'analyse des données DNS et d'autres éléments qui offrent une valeur claire mais ne sont pas disponibles dans la plupart des services auto-hébergés.

Prêt à abandonner le DNS faisant autorité auto-hébergé ?

Obtenez un DNS qui en fait plus : IBM NS1 Connect

Cet article a-t-il été utile?

OuiNon


Plus de Cloud




ManagePlus : votre parcours avant, avec et au-delà de RISE avec SAP

5 min lire - RISE with SAP n'est pas seulement un acteur majeur du cloud ces dernières années, il est également devenu l'offre cloud standard de SAP pour différents produits. Mais lors de l’évaluation de ce qu’il faut pour intégrer RISE avec SAP, plusieurs points doivent être pris en compte. Il est particulièrement important d’avoir une bonne compréhension de la répartition RACI autour des services standard, supplémentaires et facultatifs, ainsi que des packages CAS (Cloud Application Service) pertinents. Si vous vous demandez si RISE avec SAP est la bonne solution…




La densité fait la différence avec Intel Xeon de 4e génération sur les serveurs IBM Cloud Bare Metal

4 min lire - Lorsqu’il s’agit de serveurs nus, être denses est une bonne chose. En fait, plus le stockage et les cœurs sont denses, mieux c’est. Cette semaine, nous avons introduit les serveurs IBM Cloud Bare Metal équipés de processeurs Intel® Xeon® de 4e génération dans davantage de centres de données IBM Cloud clés à travers le monde. Pour tous ceux qui souhaitent rattraper leur retard, les processeurs Intel Xeon de 4e génération sont les processeurs Intel les plus récents et les plus performants que nous avons annoncés pour la première fois en janvier 2023 sur notre flotte de serveurs principaux. Déballons où est le noyau…




8 étapes pour construire une stratégie multicloud réussie

6 min lire - De plus en plus, les entreprises adoptent une approche multicloud (utilisation de services cloud de plusieurs fournisseurs cloud) pour optimiser les performances, contrôler les coûts et éviter la dépendance vis-à-vis d'un fournisseur. Selon une prévision récente de Gartner (le lien réside en dehors d'ibm.com), les dépenses mondiales des utilisateurs finaux en services de cloud public devraient augmenter de 20.4 % pour atteindre 678.8 milliards de dollars en 2024, contre 563.6 milliards de dollars en 2023. L'architecture multicloud ne donne pas seulement du pouvoir aux entreprises. choisir une combinaison des meilleurs produits et services cloud pour correspondre à leur…




Comment fonctionne la déduplication des données ?

6 min lire - Ces dernières années ont vu une explosion de la prolifération des unités de self-stockage. Ces grandes unités d’entrepôt sont devenues une industrie en plein essor à l’échelle nationale pour une raison : l’individu moyen possède désormais plus de biens qu’il ne sait quoi en faire. La même situation fondamentale afflige également le monde de l’informatique. Nous sommes au milieu d’une explosion de données. Même les objets quotidiens relativement simples génèrent désormais systématiquement des données par eux-mêmes grâce à la fonctionnalité de l'Internet des objets (IoT). Jamais…

Bulletins d'information IBM

Recevez nos newsletters et nos mises à jour thématiques qui fournissent les dernières idées en matière de leadership éclairé et d'informations sur les tendances émergentes.

S'abonner

Plus de newsletters

spot_img

Dernières informations

spot_img