2 décembre 2022

Examen de l'hébergement Aruba. 3 raisons de ne pas enregistrer un domaine avec Aruba.

Liste de certains des problÚmes fréquents dans la gestion des domaines Aruba SpA pour une utilisation efficace et efficiente des noms de domaine.

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.

Statistiques d'Aruba SpA

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.

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.

 

Vous avez des doutes ? Vous ne savez pas par oĂč commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modÚle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

Retour en haut de page