2 Dicembre 2022

Recensione Aruba Hosting. 3 Motivi per non registrare un dominio con Aruba.

Lista di alcune delle problematiche frequenti nella gestione dei domini di Aruba S.p.A per un uso efficace ed efficiente dei nomi a dominio.

Sebbene questo post possa sembrare un mero tentativo denigratorio di un nostro competitor al fine di portare acqua al nostro mulino, bisogna premettere e chiarire la nostra posizione in merito, nell’ottica che anche lavorare con nostri clienti significa purtroppo avere a che fare con Aruba S.p.A.

È un po’ un luogo comune per tutti gli addetti ai lavori in fondo, considerando che Aruba gestisce ben 2,6 milioni di domini ed è inevitabile imbattersi nei loro servizi.

Statistiche Aruba SpA

Onde evitare illazioni varie, è bene ricordare che la nostra azienda Managed Server s.r.l. non è accreditata (ne ha fatto richiesta di accreditamento) come Registrar per domini internet, né tramite NIC né tramite ICANN, considerando la registrazione domini un business ininfluente diversamente al nostro Core Business principale di Hosting ad alte performance.

Fatta la dovuta premessa ed ammesso e concesso che ogni azienda gestisce nel modo a lei più consono ed opportuno le procedure tecniche ed i servizi offerti, bisogna specificare che per un fornitore di hosting, per un integratore di sistemi, per un sistemista o per un semplice sviluppatore web, Aruba Hosting può rivelarsi molto problematico quando si ha a che fare con la gestione dei nameserver e dei DNS.

Abbiamo volutamente tralasciato altri aspetti tecnici inerenti velocità e performance o tecnologie in uso, volendo vagliare e ponderare la problematica solo ed esclusivamente dal punto di vista della gestione del dominio e del DNS.

Quanto verrà esposto è stato ovviamente palesato ad Aruba S.p.A anche con un certo fervore, ma nonostante le ripetute lamentele sembra che l’azienda sia del tutto disinteressata a colmare quelle lacune che rende la gestione dei DNS sicuramente non conforme a quella che ci si può aspettare agli albori del 2023, e molto diversa di quelli che sono ormai degli standard de facto dei più importanti player sul panorama nazionale ed internazionale.

Differenza tra Zona DNS e Nameserver

Nel campo dell’informatica e delle reti, è comune che si crei confusione tra termini apparentemente simili ma che si riferiscono a concetti o elementi diversi. Questo è particolarmente vero quando si parla di DNS, o Domain Name System. In particolare, le espressioni “Zona DNS” e “Nameserver” sono spesso usate in modo intercambiabile, generando ambiguità. Tuttavia, esiste una netta distinzione tra queste due definizioni.

Per iniziare, il nameserver è un server dove viene eseguito il servizio DNS. Il compito principale di un nameserver è rispondere alle richieste su indirizzi Internet, trasformando i nomi dei domini in indirizzi IP. Per fare questo, utilizza software specifici, come Bind o PowerDNS. Quindi, un nameserver potrebbe essere paragonato a un “libro” o a un database che contiene tutte le informazioni necessarie per tradurre i nomi di dominio in indirizzi IP.

Una Zona DNS, d’altra parte, è una parte di un dominio di spazio di nome globale DNS. Più specificamente, è una raccolta di record DNS che, insieme, definiscono le informazioni relative a un particolare dominio o sotto dominio. Questi record forniscono istruzioni su come gestire le richieste per quel dominio, e possono includere informazioni come l’indirizzo IP del server web, il server di posta e altre informazioni specifiche.

Per comprendere meglio, potremmo fare un parallelo con il mondo dei DataBase Management System (DBMS). In questo caso, un server DNS sarebbe equivalente a un’istanza di un server MySQL, mentre la zona DNS corrisponderebbe a un database specifico all’interno di quella istanza. Ogni record DNS, quindi, rappresenterebbe una singola riga all’interno di quel database.

Questa distinzione è fondamentale per comprendere alcuni dei problemi che possono sorgere quando si lavora con fornitori di servizi DNS. Ad esempio, senza una chiara comprensione di queste differenze, fornitori come Aruba possono commettere errori significativi, portando a problemi per i loro utenti. Può succedere, ad esempio, che un utente voglia cambiare solo i records all’interno di una specifica Zona DNS, ma a causa di una comunicazione non chiara o di una comprensione insufficiente, il provider potrebbe cambiare l’intero nameserver, provocando interruzioni non necessarie del servizio o altri problemi.

Se volete comprendere meglio come funzionino i DNS leggete pure questo post.

Lista delle problematiche della gestione dei domini di Aruba S.p.a

In questa analisi, vogliamo evidenziare alcune delle problematiche più evidenti nella gestione del DNS da parte di Aruba S.p.A., che consideriamo limitanti e restrittive. Questi problemi, seppure gravi, potrebbero essere risolti con interventi relativamente semplici, come la modifica delle impostazioni predefinite, l’aggiornamento delle politiche aziendali o la modifica di poche linee di codice nell’interfaccia DNS.

1. TTL Troppo elevato di default.

Il Time to Live, o TTL, è un concetto fondamentale nel mondo dei DNS. Si tratta del periodo di tempo durante il quale le informazioni fornite da un DNS autoritativo rimangono valide. Questo periodo viene espresso in secondi e viene impostato dal DNS autoritativo per un determinato dominio.

Per metterlo in termini semplici, se impostiamo un TTL di 24 ore (86400 secondi), stiamo comunicando a tutti i nameserver che interrogano il nostro DNS autoritativo che le informazioni fornite (ad esempio, un record A che mappa un nome di dominio a un indirizzo IP) rimarranno valide per le prossime 24 ore.

Il problema sorge quando c’è la necessità di fare modifiche a questi record, ad esempio, per migrare un dominio a un altro provider o per modificare l’indirizzo IP di un server web a causa di un problema al datacenter. Fino alla scadenza del TTL, queste modifiche non saranno visibili ai nameserver in tutto il mondo, che continueranno a usare le vecchie informazioni.

Quindi, in un mondo ideale, il TTL dovrebbe essere mantenuto il più basso possibile. Questo permetterebbe di propagare le modifiche in pochi minuti, riducendo al minimo i tempi di inattività. Un valore di TTL ragionevole non dovrebbe mai superare i 15 minuti.

Tuttavia, alcuni provider di servizi DNS, come Aruba S.p.A., impostano il TTL di default a 6 ore (o addirittura a 24 ore in passato). Questo significa che, se avessimo bisogno di modificare l’indirizzo IP di un server web, dovremmo attendere 6 ore prima che la modifica sia propagata in tutto il mondo. Questo ritardo può avere un impatto significativo sulla capacità di rispondere rapidamente a emergenze o di implementare modifiche pianificate in modo efficiente.

Per esempio, se avessimo bisogno di modificare il record “@” o il record “www” per un dominio registrato su Aruba, dovremmo aspettare almeno 6 ore per farlo. Questo rende difficile l’implementazione di modifiche in tempi brevi, come potrebbe essere necessario in caso di un cambio di provider o se si decide di puntare il dominio a un nuovo IP.

Dal nostro punto di vista, lavorare con domini registrati su Aruba può essere complicato, dato che non si può operare in maniera efficiente in situazioni di emergenza. Infatti, per poter cambiare l’IP di un nostro hosting su un dominio Aruba, dovremmo prima abbassare il valore del TTL al valore minimo consentito (30 minuti), poi attendere 6 ore e infine effettuare lo switch all’IP del nostro hosting, aspettando ulteriori 30 minuti affinché la modifica si propaghi. Questa lunga attesa può avere un impatto significativo sulla nostra capacità di rispondere in modo efficace e tempestivo alle esigenze dei nostri clienti.

2. Aruba cancella la zona DNS durante la sostituzione dei Nameserver autoritativi.

Uno degli errori più gravi che si riscontrano con Aruba Hosting riguarda la gestione della zona DNS durante la sostituzione dei nameserver autoritativi. Questo comportamento, presente da molti anni, può avere conseguenze rilevanti, incluso la perdita di posizionamento, l’indicizzazione dei siti web e, in alcuni rari casi, l’esclusione da Google News. Può persino portare a perdite di fatturato significative, specialmente per le aziende che fanno affidamento sulla loro presenza online.

Per comprendere l’entità del problema, immaginiamo di voler passare da utilizzare i nameserver di Aruba, con i limiti precedentemente descritti, a nameserver di terze parti. Questo può essere motivato da diverse esigenze, come la ricerca di migliori performance, la necessità di ridurre il Time To First Byte o l’obbligo di utilizzare servizi come CloudFlare, che richiedono l’utilizzo dei loro nameserver autoritativi.

Una volta che abbiamo ricreato la zona DNS sui nuovi nameserver (ad esempio, utilizzando la funzione di auto-importazione di CloudFlare), possiamo procedere con la sostituzione dei nameserver standard di Aruba con quelli del nuovo fornitore. Ad esempio, potremmo passare dai nameserver standard di Aruba (dns.technorail.com, dns2.technorail.com, dns3.arubadns.net, dns4.arubadns.cz) a quelli forniti da CloudFlare, come pippo.cs.cloudflare.com e pluto.cs.cloudflare.com.

Importante da notare è che il cambio dei nameserver non avviene in tempo reale, ma può impiegare fino a 48 ore. Durante questo periodo, i nameserver di tutto il mondo, i clienti web e i browser di tutti i visitatori possono continuare a interrogare la zona DNS sui vecchi nameserver di Aruba, i quali dovrebbero rispondere con le informazioni DNS che hanno in memoria.

Qui sta il problema principale con la gestione DNS di Aruba: quando si effettua il cambio dei nameserver nel loro pannello di controllo, il sistema di Aruba cancella la zona DNS in loro gestione. Questa azione sembra essere basata sulla presunzione che, poiché i nameserver autoritativi saranno diversi, non sia più necessario mantenere la vecchia zona DNS in memoria.

La propagazione dei nameserver infatti non è mai immediata, ma sempre a macchia d’olio e normalmente si pianifica la propagazione tenendo a mente il caso peggiore ovvero il TTL massimo indicato.

Se prendiamo l’esempio di questa zona DNS in formato BIND9 per il  dominio EXAMPLE.TLD possiamo vedere che il tempo di expire indicato è di 8ore. Pertanto, quando inseriremo i nuovi nameserver di CloudFlare, possiamo aspettarci che molti utenti continueranno a interrogare il vecchio nameserver che restituirà le informazioni che ha nella zona DNS associata.

Il problema gravissimo nella gestione dei domini e del DNS di Aruba è che al momento in cui si clicca su “Salva impostazioni” nel loro pannello per cambiare nameserver, il sistema automatizzato di Aruba pensa che sia in diritto di cancellare la zona DNS in loro gestione, presumendo probabilmente che dato che i nameserver autoritativi saranno altri da quel momento in poi, possa risultare superfluo avere in memoria la zona DNS che non verrà mai chiamata.

Questo comportamento crea una situazione potenzialmente catastrofica, poiché interrogare un nameserver la cui zona DNS è stata cancellata equivale a non ricevere alcun record in risposta. Questo significa che non sarà possibile risolvere la query DNS, e di conseguenza, i clienti non saranno in grado di raggiungere l’indirizzo IP corrispondente.

L’errore tipico visualizzato da un browser Google Chrome in questo scenario è DNS_PROBE_FINISHED_NXDOMAIN.

NXDOMAIN

Questa pratica che Aruba applica, ovvero cancellare la zona DNS al cambio del nameserver non trova alcuna logica funzionale, se non un errore di progettazione che ancora oggi a distanza di anni miete vittime tra i loro clienti.

In realtà, una pratica più ragionevole sarebbe quella di mantenere la zona DNS in memoria su Aruba per un certo periodo dopo il cambio dei nameserver, per esempio, almeno per il tempo necessario alla propagazione dei nuovi nameserver. Questo tempo dovrebbe essere almeno di 48 ore, ma per sicurezza potrebbe essere preferibile attendere fino a una settimana. Solo a quel punto, la zona DNS non più utilizzata potrebbe essere rimossa.

Anche una scimmia in fondo sa che prima di mollare la presa di un ramo deve afferrarne un altro per non cadere.

In questo modo, si eviterebbe il problema della “zona DNS mancante”, che non è previsto da alcuna best practice o standard internazionalmente riconosciuti. Inoltre, si eviterebbe di imporre ai clienti il bisogno di pianificare un periodo di inattività quando decidono di cambiare i loro nameserver. Questa situazione attuale è inaccettabile e necessita di essere rivista per garantire un servizio più affidabile e senza interruzioni.

Proprio per la sua assurdità ed una progettazione totalmente errata, nessun sistemista o sviluppatore può immaginare un’assurdità del genere fino a quando non ci sbatte la faccia in prima persona, obbligandoti comunque a pianificare necessariamente un downtime qualora si voglia cambiare i nameserver.

3. Se hai in gestione da loro un terzo livello con Hosting associato sempre da loro non puoi modificare il puntamento DNS.

Se gestisci un dominio di terzo livello con un hosting fornito e gestito da Aruba, incontrerai un problema significativo: non puoi modificare il puntamento DNS. Questa limitazione può diventare un problema considerevole, specialmente quando si tratta di effettuare migrazioni o miglioramenti dei servizi di hosting.

Immagina, ad esempio, che un tuo cliente decida di spostare il servizio di hosting di una intranet aziendale, inclusa una piattaforma di gestione, da Aruba a un altro fornitore di servizi. Supponiamo che la migrazione dell’applicativo PHP e del database MySQL sia avvenuta senza intoppi sul nuovo server più performante e che tu abbia modificato il record DNS di tipo A per il sottodominio (ad esempio, gestionale.nomedominio.it) in modo che punti alla nuova macchina.

Dopo un paio d’ore, però, ti rendi conto che non è cambiato nulla. Interrogando la zona DNS e i nameserver di Aruba con il comando “dig”, scopri che la tua modifica non ha avuto alcun effetto. Quando contatti il supporto tecnico di Aruba S.p.A. per cercare una spiegazione, ti viene detto che se il dominio di terzo livello è associato a un piano di hosting gestito da loro, è impossibile (testuali parole) effettuare variazioni del DNS per il record corrispondente.

Sentirsi dire nel 2023 che è “impossibile” effettuare tali modifiche può sembrare come una beffa, come se Aruba stesse negando i progressi tecnologici e aderisse a un sistema di gestione dei DNS obsoleto e primitivo. La realtà è che l’unica soluzione possibile sarebbe quella di modificare i nameserver per utilizzare quelli di CloudFlare.

Tuttavia, questo approccio porta di nuovo al problema della cancellazione della zona DNS di Aruba al cambio dei nameserver, come già discusso in precedenza, creando un loop infinito di problemi senza apparente soluzione, a meno di programmare il cambio dei nameserver a partire dalle ore 24 e comunicare al cliente un periodo di inattività di circa 6 ore.

Questa soluzione potrebbe essere accettabile per le piccole e medie imprese, ma è del tutto inadeguata per le aziende che necessitano di una continuità operativa ininterrotta. Ciò sottolinea l’importanza di avere un sistema di gestione dei DNS più flessibile e moderno, che permetta modifiche e aggiornamenti senza creare interruzioni del servizio o vincoli non necessari.

Conclusione

Per concludere, è inevitabile sottolineare l’insoddisfazione che nasce nel dover interagire con un’azienda come Aruba S.p.A. Questa società, almeno a giudicare da fatturati e bilanci, dovrebbe rappresentare il punto di riferimento per le soluzioni Internet in Italia. Nonostante questo, l’esperienza degli utenti e degli addetti ai lavori sembra contraddire questo ruolo di leadership.

È sconcertante constatare come le problematiche sopra menzionate, che sono oggetto di continue lamentele da parte degli operatori del settore, non abbiano ancora trovato una soluzione efficace nel corso degli anni. Sembra quasi che Aruba preferisca tollerare il malcontento dei consumatori e degli addetti ai lavori, che senza dubbio hanno validi motivi per scegliere altri fornitori di registrazione dei nomi a dominio, più rispondenti alle esigenze e alle aspettative che un utente può avere nel 2023.

Da parte nostra, consigliamo sempre di scegliere un altro fornitore per la registrazione dei nomi a dominio, in modo da evitare fin dall’inizio le problematiche sopra descritte. Queste questioni possono rendere la professione dello sviluppatore web e del sistemista frustrante e umiliante, con continue e inutili attese che potrebbero essere facilmente evitate se la proprietà di Aruba S.p.A. decidesse di modernizzare i loro servizi.

Speriamo vivamente che Aruba S.p.A. prenda provvedimenti per risolvere queste problematiche, che sono diventate insostenibili per gli addetti ai lavori che ogni giorno si scontrano con queste assurdità. Questo è un appello per l’innovazione e il miglioramento, affinché Aruba possa tornare a essere un punto di riferimento nel panorama del web italiano.

In risposta a queste preoccupazioni, intendiamo fare il possibile per coinvolgere operatori del settore e organi preposti come NIC CNR di Pisa, Corecom, Codacons e AGCOM. L’obiettivo è di far luce sulle pratiche lavorative dell’azienda e sulle problematiche che, come abbiamo documentato, possono essere limitanti. Vogliamo garantire che gli utenti e gli addetti ai lavori possano usufruire di servizi di registrazione dei nomi a dominio efficienti, moderni e rispondenti alle esigenze del mercato del 2023.

 

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Facebook, Inc. detiene i diritti su Facebook®; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Questo sito non è affiliato, sponsorizzato, o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello Europeo da MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italia.

Torna in alto