Table des matières de l'article :
Bien que ce billet puisse apparaître comme une simple tentative dénigrante de la part d'un de nos concurrents pour apporter de l'eau à notre moulin, il faut commencer par clarifier notre position sur le sujet, dans la perspective que travailler avec nos clients, c'est aussi ont malheureusement à voir avec Aruba SpA
C'est un peu banal pour tous les initiés après tout, étant donné qu'Aruba gère jusqu'à 2,6 millions de domaines et qu'il est inévitable de tomber sur leurs services.
Afin d'éviter diverses inférences, il est bon de rappeler que notre société Managed Server srl n'est pas accréditée (elle a demandé l'accréditation) en tant que registraire pour les domaines Internet, ni via NIC ni via ICANN, considérant l'enregistrement de domaine comme une activité non pertinente contrairement à notre Core Activité principale de l'hébergement haute performance.
Ayant fait le constat dû et admis et accordé que chaque entreprise gère les procédures techniques et les services proposés de la manière la plus appropriée et appropriée pour elle, il convient de préciser que pour un hébergeur, un intégrateur de systèmes, un analyste de systèmes ou un simple web développeur, Aruba Hosting peut s'avérer très problématique lorsqu'il s'agit de la gestion des serveurs de noms et du DNS.
Nous avons délibérément laissé de côté d'autres aspects techniques concernant la vitesse et les performances ou les technologies utilisées, voulant examiner et peser le problème uniquement et exclusivement du point de vue de la gestion des domaines et du DNS.
Ce qui sera exposé a évidemment été divulgué à Aruba SpA également avec une certaine ferveur, mais malgré les plaintes répétées, il semble que l'entreprise se désintéresse complètement de combler les lacunes qu'elle fait Gestion DNS certainement pas conforme à ce que l'on peut attendre à l'aube de 2023, et très différent de ce qui sont désormais les standards de facto des acteurs les plus importants de la scène nationale et internationale.
Différence entre la zone DNS et le serveur de noms
Dans le domaine des technologies de l'information et des réseaux, il est fréquent que des confusions surviennent entre des termes apparemment similaires mais qui font référence à des concepts ou à des éléments différents. Cela est particulièrement vrai en ce qui concerne le DNS ou le système de noms de domaine. En particulier, les expressions "Zone DNS" et "Serveur de noms" sont souvent utilisées de manière interchangeable, générant une ambiguïté. Cependant, il existe une distinction claire entre ces deux définitions.
Pour commencer, le serveur de noms est un serveur sur lequel s'exécute le service DNS. Le travail principal d'un serveur de noms est de répondre aux requêtes sur les adresses Internet, en transformant les noms de domaine en adresses IP. Pour cela, utilisez des logiciels spécifiques, comme Bind ou PowerDNS. Ainsi, un serveur de noms pourrait être assimilé à un "livre" ou à une base de données contenant toutes les informations nécessaires pour traduire les noms de domaine en adresses IP.
Une zone DNS, en revanche, fait partie d'un domaine d'espace de noms global DNS. Plus précisément, il s'agit d'un ensemble d'enregistrements DNS qui définissent ensemble des informations sur un domaine ou sous-domaine particulier. Ces enregistrements fournissent des instructions sur la façon de gérer les demandes pour ce domaine et peuvent inclure des informations telles que l'adresse IP du serveur Web, le serveur de messagerie et d'autres informations spécifiques.
Pour mieux comprendre, on pourrait faire un parallèle avec le monde des systèmes de gestion de bases de données (SGBD). Dans ce cas, un serveur DNS serait équivalent à une instance d'un serveur MySQL, tandis que la zone DNS correspondrait à une base de données spécifique au sein de cette instance. Chaque enregistrement DNS représenterait alors une seule ligne dans cette base de données.
Cette distinction est essentielle pour comprendre certains des problèmes qui peuvent survenir lorsque vous travaillez avec des fournisseurs de services DNS. Par exemple, sans une compréhension claire de ces différences, des fournisseurs comme Aruba peuvent commettre des erreurs importantes, entraînant des problèmes pour leurs utilisateurs. Il peut arriver, par exemple, qu'un utilisateur souhaite modifier uniquement les enregistrements d'une zone DNS spécifique, mais en raison d'une communication peu claire ou d'une compréhension insuffisante, le fournisseur peut modifier l'intégralité du serveur de noms, provoquant des interruptions inutiles du service ou d'autres problèmes.
Si vous voulez mieux comprendre le fonctionnement du DNS, lisez ce post.
Liste des problèmes de gestion de domaine Aruba Spa
Dans cette analyse, nous voulons mettre en évidence certains des problèmes les plus évidents dans la gestion du DNS par Aruba SpA, que nous considérons comme limitants et restrictifs. Ces problèmes, bien que graves, pourraient être résolus par des actions relativement simples, telles que la modification des paramètres par défaut, la mise à jour des politiques de l'entreprise ou la modification de quelques lignes de code dans l'interface DNS.
1. TTL Trop élevé par défaut.
Time to Live, ou TTL, est un concept fondamental dans le monde du DNS. Il s'agit de la période de temps pendant laquelle les informations fournies par un DNS faisant autorité restent valides. Cette période est exprimée en secondes et est définie par le DNS faisant autorité pour un domaine particulier.
Pour le dire simplement, si nous fixons un TTL de 24 heures (86400 secondes), nous disons à tous les serveurs de noms interrogeant notre DNS faisant autorité que les informations qu'ils fournissent (par exemple, un enregistrement A mappant un nom de domaine à une adresse IP) resteront valable pour les prochaines 24 heures.
Le problème survient lorsqu'il est nécessaire d'apporter des modifications à ces enregistrements, par exemple pour migrer un domaine vers un autre fournisseur ou pour modifier l'adresse IP d'un serveur Web en raison d'un problème de centre de données. Jusqu'à l'expiration de la durée de vie, ces modifications ne seront pas visibles pour les serveurs de noms du monde entier, qui continueront à utiliser les anciennes informations.
Ainsi, dans un monde idéal, le TTL doit être maintenu aussi bas que possible. Cela permettrait aux modifications d'être propagées en quelques minutes, minimisant ainsi les temps d'arrêt. Une valeur TTL raisonnable ne doit jamais dépasser 15 minutes.
Cependant, certains fournisseurs de services DNS, tels qu'Aruba SpA, définissent le TTL par défaut sur 6 heures (ou même 24 heures dans le passé). Cela signifie que, si nous devions changer l'adresse IP d'un serveur Web, nous devions attendre 6 heures pour que le changement se propage dans le monde entier. Ce retard peut avoir un impact significatif sur votre capacité à répondre rapidement aux urgences ou à mettre en œuvre efficacement les changements prévus.
Par exemple, si nous devions modifier l'enregistrement "@" ou l'enregistrement "www" pour un domaine enregistré sur Aruba, nous devions attendre au moins 6 heures pour le faire. Cela rend difficile la mise en œuvre rapide des changements, comme cela pourrait être nécessaire en cas de changement de fournisseur ou si vous décidez de faire pointer le domaine vers une nouvelle adresse IP.
De notre point de vue, travailler avec des domaines enregistrés sur Aruba peut être compliqué, car vous ne pouvez pas fonctionner efficacement dans des situations d'urgence.. En effet, pour changer l'IP d'un de nos hébergements sur un domaine Aruba, il faut d'abord baisser la valeur TTL à la valeur minimale autorisée (30 minutes), puis attendre 6 heures et enfin basculer sur l'IP de notre hébergement, attendre 30 minutes supplémentaires pour que le changement se propage. Cette longue attente peut avoir un impact significatif sur notre capacité à répondre efficacement et rapidement aux besoins de nos clients.
2. Aruba supprime la zone DNS lors du remplacement des serveurs de noms faisant autorité.
L'une des erreurs les plus graves rencontrées avec les problèmes d'hébergement Aruba la gestion de la zone DNS lors du remplacement des serveurs de noms faisant autorité. Ce comportement, présent depuis de nombreuses années, peut avoir des conséquences importantes, notamment la perte de classement, l'indexation des sites Web et, dans de rares cas, l'exclusion de Google News. Cela peut même entraîner des pertes de revenus importantes, en particulier pour les entreprises qui dépendent de leur présence en ligne.
Pour comprendre l'étendue du problème, imaginons que nous voulions passer de l'utilisation des serveurs de noms d'Aruba, avec les limites décrites ci-dessus, à des serveurs de noms tiers. Cela peut être motivé par différents besoins, comme la recherche de meilleures performances, la nécessité de réduire le Time To First Byte ou l'obligation d'utiliser des services tels que CloudFlare, qui nécessitent l'utilisation de leurs serveurs de noms faisant autorité.
Une fois que nous avons recréé la zone DNS sur les nouveaux serveurs de noms (par exemple, en utilisant la fonction d'importation automatique de CloudFlare), nous pouvons procéder au remplacement des serveurs de noms Aruba standard par ceux du nouveau fournisseur. Par exemple, nous pourrions passer des serveurs de noms standard d'Aruba (dns.technorail.com, dns2.technorail.com, dns3.arubadns.net, dns4.arubadns.cz) à ceux fournis par CloudFlare, tels que foo.cs.cloudflare.com et pluto.cs.cloudflare.com.
Il est important de noter que le changement de serveurs de noms ne se produit pas en temps réel, mais peut prendre jusqu'à 48 heures. Pendant ce temps, les serveurs de noms mondiaux, les clients Web et tous les navigateurs des visiteurs peuvent continuer à interroger la zone DNS sur les anciens serveurs de noms d'Aruba, qui devraient répondre avec les informations DNS qu'ils ont en mémoire.
C'est là que réside le principal problème de la gestion DNS d'Aruba : lorsque vous modifiez les serveurs de noms dans leur panneau de contrôle, le système d'Aruba supprime la zone DNS qu'ils gèrent. Cette action semble être basée sur l'hypothèse que puisque les serveurs de noms faisant autorité seront différents, il n'est plus nécessaire de garder l'ancienne zone DNS en mémoire.
En fait, la propagation du serveur de noms n'est jamais immédiate, mais toujours une traînée de poudre et la propagation est normalement planifiée en gardant à l'esprit le pire des cas, c'est-à-dire le TTL maximum indiqué.
Si nous prenons l'exemple de cette zone DNS au format BIND9 pour le domaine EXAMPLE.TLD nous pouvons voir que le délai d'expiration indiqué est de 8 heures. Par conséquent, lorsque nous entrons dans les nouveaux serveurs de noms CloudFlare, nous pouvons nous attendre à ce que de nombreux utilisateurs continuent à interroger l'ancien serveur de noms qui renverra les informations dont il dispose dans la zone DNS associée.
Le problème très sérieux dans la gestion des domaines et du DNS d'Aruba est que lorsque vous cliquez sur "Enregistrer les paramètres" dans leur panneau pour changer de serveur de noms, le système automatisé d'Aruba pense qu'il a le droit de supprimer la zone DNS sous leur gestion, en supposant probablement que depuis l'autorité les serveurs de noms seront autres à partir de ce moment là, il peut être superflu d'avoir en mémoire la zone DNS qui ne sera jamais appelée.
Ce comportement crée une situation potentiellement catastrophique, car interroger un serveur de noms dont la zone DNS a été supprimée équivaut à ne recevoir aucun enregistrement en réponse. Cela signifie qu'il ne sera pas possible de résoudre la requête DNS et que, par conséquent, les clients ne pourront pas atteindre l'adresse IP correspondante.
L'erreur typique qu'un navigateur Google Chrome affiche dans ce scénario est DNS_PROBE_FINISHED_NXDOMAIN.
Cette pratique qu'applique Aruba, c'est-à-dire supprimer la zone DNS lorsque le serveur de noms change, ne trouve aucune logique fonctionnelle, sinon une erreur de conception qui encore aujourd'hui, après de nombreuses années, fait des victimes parmi ses clients.
En fait, une pratique plus raisonnable serait de garder la zone DNS en mémoire sur Aruba pendant un certain temps après le changement des serveurs de noms, par exemple, au moins aussi longtemps qu'il faut pour que les nouveaux serveurs de noms se propagent. Ce délai devrait être d'au moins 48 heures, mais il peut être préférable d'attendre jusqu'à une semaine pour être en sécurité. Ce n'est qu'alors que la zone DNS inutilisée pourra être supprimée.
Au fond, même un singe sait qu'avant de lâcher une branche, il doit en saisir une autre pour ne pas tomber.
De cette façon, vous éviterez le problème de la "zone DNS manquante", qui n'est couvert par aucune bonne pratique ou norme internationalement reconnue. De plus, cela éviterait d'imposer aux clients la nécessité de planifier des temps d'arrêt lorsqu'ils décident de changer leurs serveurs de noms. Cette situation actuelle est inacceptable et doit être revue pour assurer un service plus fiable et ininterrompu.
Précisément à cause de son absurdité et d'une conception totalement incorrecte, aucun administrateur système ou développeur ne peut imaginer une telle absurdité jusqu'à ce qu'il se claque la gueule à la première personne, vous obligeant cependant à nécessairement prévoir un temps d'arrêt si vous souhaitez changer de serveurs de noms.
3. Si vous avez un troisième niveau géré par eux avec un hébergement qui leur est associé, vous ne pouvez pas modifier le pointeur DNS.
Si vous gérez un domaine de troisième niveau avec un hébergement fourni et géré par Aruba, vous rencontrerez un problème non négligeable : vous ne pourrez pas modifier le pointage DNS. Cette limitation peut devenir un problème considérable, notamment lorsqu'il s'agit d'effectuer des migrations ou des améliorations des services d'hébergement.
Imaginez, par exemple, que votre client décide de déplacer un service d'hébergement d'intranet d'entreprise, y compris une plate-forme de gestion, d'Aruba vers un autre fournisseur de services. Supposons que la migration de l'application PHP et de la base de données MySQL se soit bien déroulée sur le nouveau serveur plus performant et que vous ayez modifié l'enregistrement DNS de type A du sous-domaine (par exemple, gestionale.nomedominio.it) pour qu'il pointe vers le nouvelle voiture.
Après quelques heures, cependant, vous vous rendez compte que rien n'a changé. En interrogeant la zone DNS et les serveurs de noms d'Aruba avec la commande "dig", vous découvrez que votre modification n'a eu aucun effet. Lorsque vous contactez le support technique d'Aruba SpA pour demander une explication, on vous dit que si le domaine de troisième niveau est associé à un plan d'hébergement géré par eux, il est impossible (mots textuels) d'apporter des modifications au DNS pour l'enregistrement correspondant.
Se faire dire en 2023 que de tels changements sont "impossibles" peut sembler une blague, comme si Aruba reniait les avancées technologiques et adhérait à un système de gestion DNS obsolète et primitif. La réalité est que la seule solution possible serait de changer les serveurs de noms pour utiliser ceux de CloudFlare.
Cependant, cette approche conduit à nouveau au problème de la suppression de la zone DNS Aruba lors du changement de serveurs de noms, comme déjà évoqué ci-dessus, créant une boucle infinie de problèmes sans solution apparente, à moins que vous ne programmiez le changement de serveur de noms à partir de 24h6 et que vous communiquiez à au client une période d'inactivité d'environ XNUMX heures.
Cette solution peut être acceptable pour les petites et moyennes entreprises, mais elle est totalement inadéquate pour les entreprises qui ont besoin d'une continuité d'activité ininterrompue. Cela souligne l'importance d'avoir un système de gestion DNS plus flexible et moderne, qui permet des changements et des mises à jour sans créer d'interruptions de service ou de contraintes inutiles.
conclusion
Pour conclure, il est inévitable de souligner l'insatisfaction qui découle d'avoir à interagir avec une entreprise comme Aruba SpA Cette entreprise, au moins à en juger par son chiffre d'affaires et ses états financiers, devrait représenter le point de référence des solutions Internet en Italie. Malgré cela, l'expérience des utilisateurs et des initiés semble contredire ce rôle de leader.
Il est déconcertant de constater que les problèmes évoqués ci-dessus, qui font l'objet de plaintes continues des opérateurs du secteur, n'ont pas encore trouvé de solution efficace au fil des années. Il semble presque qu'Aruba préfère tolérer le mécontentement des consommateurs et des professionnels, qui ont sans doute des raisons valables de choisir d'autres fournisseurs d'enregistrement de noms de domaine, plus réactifs aux besoins et aux attentes que peut avoir un utilisateur en 2023.
Pour notre part, nous recommandons toujours de choisir un autre fournisseur pour l'enregistrement des noms de domaine, afin d'éviter dès le départ les problèmes décrits ci-dessus. Ces problèmes peuvent rendre la profession de développeur Web et d'administrateur système frustrante et humiliante, avec des attentes constantes et inutiles qui pourraient facilement être évitées si les propriétaires d'Aruba SpA décidaient de moderniser leurs services.
Nous espérons sincèrement qu'Aruba SpA prendra des mesures pour résoudre ces problèmes, devenus insoutenables pour les professionnels qui se heurtent chaque jour à ces absurdités. Il s'agit d'un appel à l'innovation et à l'amélioration, afin qu'Aruba puisse redevenir un point de référence dans le panorama du web italien.
En réponse à ces préoccupations, nous entendons tout mettre en œuvre pour impliquer les opérateurs du secteur et les organismes en charge tels que NIC CNR de Pise, Corecom, Codacons et AGCOM. L'objectif est de faire la lumière sur les pratiques de travail de l'entreprise et sur les problèmes qui, comme nous l'avons documenté, peuvent être contraignants. Nous voulons nous assurer que les utilisateurs et les professionnels puissent profiter de services d'enregistrement de noms de domaine efficaces et modernes qui répondent aux besoins du marché 2023.
