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

Il y a souvent confusion parmi les initiés quand ils disent "Changeons le DNS", où dans certains cas, cela est compris comme un changement de zone DNS, de changer le DNS faisant autorité pour le domaine.

Pour le serveur de noms, nous pouvons imaginer un serveur exécutant le service DNS (comme, par exemple, Bind ou PowerDNS) qui gère la zone DNS du domaine en question, et pour la zone DNS, nous pouvons imaginer une série d'enregistrements pour le domaine en question.

Si nous voulions faire un parallélisme dans le monde des SGBD (DataBase Management System), nous pouvons imaginer un serveur DNS comme une instance de serveur MySQL, une zone DNS comme une base de données à l'intérieur de l'instance SQL et un enregistrement DNS comme une ligne à l'intérieur à la base de données.

Ce concept doit être gardé à l'esprit pour comprendre combien d'erreurs Aruba commet au détriment de ses utilisateurs. Si vous voulez mieux comprendre le fonctionnement du DNS, lisez ce post.

Liste des problèmes de gestion de domaine Aruba Spa

Voici ce qui, à notre avis, sont des problèmes émasculants et limitants de la gestion DNS d'Aruba SpA. Tous les problèmes, qui pourraient être facilement résolus en modifiant les paramètres par défaut, les politiques de l'entreprise ou quelques lignes de code d'application à l'interface DNS).

1. TTL Trop élevé par défaut.

Le TTL signifie Time To Live et est le temps imposé et exprimé par le DNS faisant autorité pour le domaine, pour lequel les informations délivrées restent valables. En termes simples, avec un TTL de 24 heures, j'informe les autres serveurs de noms qui interrogent le serveur de noms faisant autorité que l'enregistrement que je renvoie sera valide pendant 24 heures.

Jusque-là, si je fais un changement, (peut-être pour migrer le domaine vers un autre fournisseur, ou peut-être parce que le centre de données a brûlé), il ne sera pas implémenté dans le monde entier par les autres serveurs de noms qui continueront à atteindre l'ancienne IP indiquée, peut-être 24 heures avant.

En d'autres termes comme nous l'avons expliqué dans le post sur DNS TTL, il n'y a aucune raison d'avoir un TTL élevé, étant donné que vous devrez peut-être effectuer le changement en quelques minutes, et un temps paisible et raisonnable ne devrait jamais dépasser 15 minutes, afin que vous puissiez attendre un temps raisonnable (15 minutes d'arrêt peut être raisonnable par exemple) pour la propagation DNS.

Dommage que Aruba SpA définit le TTL à 6 heures par défaut (il y a quelques années même 24h) et donc si on avait besoin, par exemple, de cibler un serveur web réplique de secours, il faudrait attendre 6h pour que le monde entier reçoive les nouveaux paramètres et la nouvelle IP modifiée.

Ceci s'applique à toute opération qui a lieu sur la zone DNS, comme par exemple le changement de l'enregistrement @ et de l'enregistrement www d'un domaine enregistré sur Aruba, si le client décide, par exemple, de changer d'IP, de serveur, de fournisseur et faites-le pointer vers une adresse IP différente de la précédente.

De notre point de vue, par exemple, nous ne sommes pas en mesure de fonctionner efficacement en cas d'urgence avec des domaines enregistrés sur Aruba car nous devons d'abord abaisser la valeur TTL à la valeur minimale possible (30 minutes sur Aruba), puis revenir après 6 heures et basculer sur la nouvelle IP de notre hébergement, en attendant cependant encore 30 minutes avant que la propagation ait lieu.

2. Aruba supprime la zone DNS lors du remplacement des serveurs de noms faisant autorité.

C'est l'erreur la plus grave commise par Aruba Hosting depuis des années maintenant. C'est une erreur grave principalement parce qu'elle entraîne des conséquences graves, parfois très graves, avec des pertes très importantes en chiffre d'affaires, en positionnement, en indexation, dans certains cas rares il y a même le risque d'être viré de Google News.

Imaginons que pour une raison quelconque vous décidiez de ne pas utiliser les serveurs de noms d'Aruba qui ont ces limites illustrées dans ce post, mais que par exemple nous voulions utiliser des serveurs de noms tiers, soit pour des raisons de performances et de vitesse et réduire le Time To First Byte, soit parce que nous devons utiliser des services comme CloudFlare qui nous lient et nous obligent à remplacer les serveurs de noms faisant autorité par les leurs.

Il est logique et incontesté qu'une fois la zone recréée sur les nouveaux serveurs de noms (Cloudflare a une fonctionnalité assez fonctionnelle qui vous permet d'importer automatiquement les enregistrements standard les plus connus et les plus répandus), vous procéderez au remplacement des serveurs de noms Aruba standard par ceux du nouveau fournisseur.

Par exemple, nous pourrions modifier les 4 enregistrements standard comme suit :

Serveurs de noms dns.technorail.com dns2.technorail.com dns3.arubadns.net dns4.arubadns.cz

Avec ceux que CloudFlare indiquera, par exemple avec pippo.cs.cloudflare.com et pluto.cs.cloudflare.com ou d'autres noms de domaine comme nous le voyons dans l'exemple de capture d'écran suivant.

Il est bon de savoir que le changement de serveur de noms n'est pas du tout immédiat et comme Aruba l'enseigne et l'indique dans tous ses manuels (et c'est une pratique académique, reconnue et consolidée par tout administrateur système ou ingénieur réseau qui se respecte), La propagation du serveur de noms peut prendre jusqu'à 48 heures. 

En termes simples, cela signifie que pendant un temps théorique allant jusqu'à 48 heures, les serveurs de noms du monde entier, les clients Web, les navigateurs de tous les visiteurs du monde, pourraient continuer à interroger la zone DNS des anciens serveurs de noms Aruba. , qui devrait répondre avec les informations DNS de la zone DNS qu'ils ont encore 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.

Cela crée un problème aux proportions épiques, avec des dommages qui peuvent être aussi graves que la présence en ligne d'un domaine est importante et rentable.

Pour préciser qu'interroger un serveur de noms avec une zone DNS supprimée équivaut à ne recevoir aucun enregistrement en réponse et donc à ne pas pouvoir résoudre la requête DNS et donc à ne pas pouvoir être routé vers une IP correspondante.

L'erreur correspondante sur un navigateur Google Chrome est le très célèbre et bien connu 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.

Ce serait logique et judicieux si vous voulez vraiment supprimer la zone DNS qui n'est plus utilisée sur le serveur Aruba, attendez la propagation des serveurs de noms, et seulement après au moins quelques jours, de préférence une semaine, effectuez une tâche cron pour supprimer toutes les zones DNS qui ne sont plus utilisées dans lequel le changement de serveurs de noms a été effectué depuis un temps suffisant (le canonique deux jours au moins) pour la propagation des nouveaux serveurs de noms.

Au fond, même un singe sait qu'avant de lâcher une branche, il doit en saisir une autre pour ne pas tomber.

Ce problème documenté ci-dessus est très grave et a un impact, ainsi qu'il n'est reflété dans aucune bonne pratique ou dans aucune norme ou RFC actuellement connue et approuvée au niveau international.

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.

Imaginons que ce matin, un de nos clients décide d'externaliser le service d'hébergement d'un intranet d'entreprise avec un logiciel de gestion associé, du type gestionale.nomedominio.it, et imaginons qu'une fois l'application PHP et la base de données MySQL migrées vers le nouveau serveur, nous avons modifié l'enregistrement DNS de type A gestionale.nomedominio.it pour le faire pointer vers la nouvelle machine plus performante.

Imaginez maintenant qu'après quelques heures, rien n'a changé et qu'en interrogeant leur zone DNS et leurs serveurs de noms, le changement n'a eu aucun effet.

Nous appelons le support technique d'Aruba SpA et recherchons des éclaircissements à ce sujet, ils nous répondent que si le troisième niveau est associé à un plan d'hébergement géré par eux, il est IMPOSSIBLE (IMPOSSIBLE en termes textuels) de changer le DNS pour le correspondant enregistrement.

En 2023 se faire dire que c'est impossible, c'est une blague littérale, il aurait été plus correct d'admettre les limitations technologiques et un système de gestion DNS pionnier et obsolète pour comprendre que la seule solution possible est de changer les serveurs de noms avec ceux de CloudFlare .

Problème qui nous renvoie malheureusement au point deux de cette courte liste, avec tous les problèmes annexes et connexes d'une boucle infinie sans issue autre que de programmer le changement de serveur de noms à partir de 24 heures et de communiquer au client un temps d'arrêt d'environ 6 heures .

Cette solution est acceptable pour les situations de type PME mais peu probable pour les entreprises qui ont besoin d'une continuité totale des activités.

conclusion

En conclusion, la frustration ne peut qu'émerger de devoir s'interfacer avec une entreprise comme Aruba SpA qui, du moins en théorie, avec un chiffre d'affaires et des budgets en main, devrait être et représenter le non plus ultra des solutions internet en Italie.

Nous avons du mal à croire que les problèmes évoqués ci-dessus, objet de plaintes quasi constantes des initiés, n'aient pas encore trouvé de solution efficace au fil des années, préférant le mécontentement des consommateurs et des initiés qui ont certainement plus d'une raison valable de préférer d'autres fournisseurs d'enregistrement de noms de domaine qui répondent aux besoins et aux attentes d'un utilisateur au seuil de 2023.

Pour notre part, nous vous invitons toujours à choisir n'importe quel autre fournisseur pour l'enregistrement de noms de domaine, en évitant dès le départ les problèmes décrits ci-dessus, ce qui rend le métier de développeur web et d'administrateur système vraiment mortifiant et humiliant, avec des attentes continues et inutiles. cela pourrait être résolu si la propriété d'Aruba SpA décidait de moderniser ses services pour le plaisir de tous, eux-mêmes en premier lieu.

Nous espérons qu'Aruba SpA agira sur ce qui précède, en résolvant ces problèmes devenus insupportables pour les initiés qui, malheureusement, rencontrent quotidiennement ces absurdités.

De notre côté, nous ferons tout notre possible en impliquant les opérateurs du secteur et les organismes en charge tels que NIC CNR de Pise, Corecom, Codacons et AGCOM, afin que la lumière soit faite sur les méthodes de travail de l'entreprise et les problèmes anecdotiques documentés et très contraignants .

 

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.

Remonter en haut