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

Managed Server Srl est un acteur italien leader dans la fourniture de solutions syst√®me GNU/Linux avanc√©es orient√©es vers la haute performance. Avec un mod√®le d'abonnement peu co√Ľteux et pr√©visible, nous garantissons que nos clients ont acc√®s √† des technologies avanc√©es en mati√®re d'h√©bergement, de serveurs d√©di√©s et de services cloud. En plus de cela, nous proposons des conseils syst√®me sur les syst√®mes Linux et une maintenance sp√©cialis√©e en SGBD, s√©curit√© informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'h√©bergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapt√© aux administrations publiques, aux PME et √† toutes tailles.

Red Hat, Inc. d√©tient les droits de Red Hat¬ģ, RHEL¬ģ, RedHat Linux¬ģ et CentOS¬ģ ; AlmaLinux‚ĄĘ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux¬ģ est une marque d√©pos√©e de la Rocky Linux Foundation ; SUSE¬ģ est une marque d√©pos√©e de SUSE LLC ; Canonical Ltd. d√©tient les droits sur Ubuntu¬ģ ; Software in the Public Interest, Inc. d√©tient les droits sur Debian¬ģ ; Linus Torvalds d√©tient les droits sur Linux¬ģ ; FreeBSD¬ģ est une marque d√©pos√©e de la FreeBSD Foundation ; NetBSD¬ģ est une marque d√©pos√©e de la Fondation NetBSD ; OpenBSD¬ģ est une marque d√©pos√©e de Theo de Raadt. Oracle Corporation d√©tient les droits sur Oracle¬ģ, MySQL¬ģ et MyRocks¬ģ ; Percona¬ģ est une marque d√©pos√©e de Percona LLC ; MariaDB¬ģ est une marque d√©pos√©e de MariaDB Corporation Ab ; REDIS¬ģ est une marque d√©pos√©e de Redis Labs Ltd. F5 Networks, Inc. d√©tient les droits sur NGINX¬ģ et NGINX Plus¬ģ ; Varnish¬ģ est une marque d√©pos√©e de Varnish Software AB. Adobe Inc. d√©tient les droits sur Magento¬ģ ; PrestaShop¬ģ est une marque d√©pos√©e de PrestaShop SA ; OpenCart¬ģ est une marque d√©pos√©e d'OpenCart Limited. Automattic Inc. d√©tient les droits sur WordPress¬ģ, WooCommerce¬ģ et JetPack¬ģ ; Open Source Matters, Inc. d√©tient les droits sur Joomla¬ģ ; Dries Buytaert d√©tient les droits sur Drupal¬ģ. Amazon Web Services, Inc. d√©tient les droits sur AWS¬ģ ; Google LLC d√©tient les droits sur Google Cloud‚ĄĘ et Chrome‚ĄĘ ; Facebook, Inc. d√©tient les droits sur Facebook¬ģ ; Microsoft Corporation d√©tient les droits sur Microsoft¬ģ, Azure¬ģ et Internet Explorer¬ģ ; La Fondation Mozilla d√©tient les droits sur Firefox¬ģ. Apache¬ģ est une marque d√©pos√©e de The Apache Software Foundation ; PHP¬ģ est une marque d√©pos√©e du groupe PHP. CloudFlare¬ģ est une marque d√©pos√©e de Cloudflare, Inc. ; NETSCOUT¬ģ est une marque d√©pos√©e de NETSCOUT Systems Inc. ; ElasticSearch¬ģ, LogStash¬ģ et Kibana¬ģ sont des marques d√©pos√©es d'Elastic NV. Ce site n'est affili√©, sponsoris√© ou autrement associ√© √† aucune des entit√©s mentionn√©es ci-dessus et ne repr√©sente aucune de ces entit√©s de quelque mani√®re que ce soit. Tous les droits sur les marques et noms de produits mentionn√©s sont la propri√©t√© de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionn√©es appartiennent √† leurs titulaires. MANAGED SERVER¬ģ est une marque d√©pos√©e au niveau europ√©en par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

Retour en haut de page