Table of contents of the article:
Although this post may seem like a mere denigrating attempt by one of our competitors in order to add grist to our mill, we need to start with and clarify our position on the matter, from the point of view that working with our customers also means unfortunately have to do with Aruba SpA
It's a bit commonplace for all insiders after all, considering that Aruba manages as many as 2,6 million domains and it is inevitable to come across their services.
In order to avoid various inferences, it is good to remember that our company Managed Server srl is not accredited (it has requested accreditation) as a Registrar for internet domains, neither through NIC nor through ICANN, considering domain registration an irrelevant business unlike our Core Main business of high performance hosting.
Having made the due premise and admitted and granted that each company manages the technical procedures and services offered in the most suitable and appropriate way for it, it must be specified that for a hosting provider, a systems integrator, a systems analyst or a simple web developer, Aruba Hosting can prove to be very problematic when dealing with the management of nameservers and DNS.
We have deliberately left out other technical aspects concerning speed and performance or technologies in use, wanting to examine and weigh the problem only and exclusively from the point of view of domain and DNS management.
What will be exposed has obviously been disclosed to Aruba SpA also with a certain fervor, but despite the repeated complaints it seems that the company is completely disinterested in filling the gaps it makes DNS management certainly not compliant with what can be expected at the dawn of 2023, and very different from what are now the de facto standards of the most important players on the national and international scene.
Difference between DNS Zone and Nameserver
There is often confusion among insiders when they say "Let's change the DNS", where in some cases it is understood as changing the DNS zone, from changing the Authoritative DNS for the domain.
For nameserver we can imagine a server running the DNS service (such as, for example, Bind or PowerDNS) which manages the DNS zone of the domain in question, and for DNS zone we can imagine a series of records for the domain in question.
If we wanted to make a parallelism in the world of DBMS (DataBase Management System), we can imagine a DNS server as a MySQL Server instance, a DNS zone as a Database inside the SQL instance, and a DNS record as a line inside internal to the database.
This concept must be kept in mind to understand how many mistakes Aruba makes to the detriment of its users. If you want to better understand how DNS works, read this post.
List of Aruba Spa domain management issues
Here are what, in our opinion, are emasculating and limiting problems of Aruba SpA's DNS management. All problems, which could be easily solved by changing default settings, company policies, or a few lines of application code to the DNS interface).
1. TTL Too high by default.
The TTL stands for Time To Live and is the time imposed and expressed by the authoritative DNS for the domain, for which the information delivered remains valid. Simply put, with a 24-hour TTL, I instruct other nameservers that query the authoritative nameserver that the record I return will be valid for 24 hours.
Until then, if I make a change, (perhaps to migrate the domain to another supplier, or perhaps because the data center has burned down), it will not be implemented worldwide by the other nameservers who will continue to reach the old IP indicated, perhaps 24 hours before.
In simple terms as we explained in the post on DNS TTL, there is no reason to have a high TTL, considering that you might need to make the change within minutes, and a peaceful and reasonable time should never be more than 15 minutes, so that you can wait a reasonable time (15 minutes of downtime may be reasonable for example) for DNS propagation.
It's a pity that Aruba SpA sets the TTL to 6 hours by default (a few years ago even 24 hours) and therefore if we needed, for example, to target a backup replica webserver, we would have to wait 6 hours for the whole world to receive the new settings and the new modified IP.
This applies to any operation that takes place on the DNS zone, such as for example the change of the @ record and the www record of a domain registered on Aruba, if the customer decides, for example, to change the IP, server, supplier and point it to a different IP than the one before.
From our point of view, for example, we are unable to operate efficiently in an emergency with domains registered on Aruba because we first need to lower the TTL value to the minimum possible value (30 minutes on Aruba), and then go back after 6 hours and switch to the new IP of our hosting, however waiting for another 30 minutes before the propagation takes place.
2. Aruba deletes the DNS zone when replacing the authoritative Nameservers.
This is the most serious mistake that Aruba Hosting has been carrying around for years now. It is a serious error mainly because it causes serious consequences, sometimes very serious, with very important losses in turnover, positioning, indexing, in some rare cases there is even the risk of being kicked out of Google News.
Let's imagine that for whatever reason you decide not to use Aruba's nameservers that have these limits illustrated in this post, but that for example we wanted to use third-party nameservers, either for performance and speed reasons and lower the Time To First Byte, either because we need to use services like CloudFlare that bind us and force us to replace authoritative nameservers with theirs.
It is logical and undisputed that once the zone has been recreated on the new nameservers (Cloudflare has a fairly functional feature that allows you to auto-import the most well-known and widespread standard records) you will proceed to replace the standard Aruba nameservers with those of the new supplier.
For example, we could change the standard 4 records as:
Nameservers dns.technorail.com dns2.technorail.com dns3.arubadns.net dns4.arubadns.cz
With those that CloudFlare will indicate, for example with pippo.cs.cloudflare.com and pluto.cs.cloudflare.com or other domain names as we see in the following example screenshot.
It is good to know that changing the nameserver is not immediate at all and as Aruba teaches and indicates in all its handbooks (and it is academic practice, recognized and consolidated by any self-respecting system administrator or network engineer), nameserver propagation can take up to 48 hours.
In simple terms, it means that for a theoretical time of up to 48 hours, the nameservers of the whole world, the web clients, the browsers of all the visitors of the world, could continue to query the DNS zone of the old Aruba nameservers, which should answer with the DNS information of the DNS zone they still have in memory.
In fact, nameserver propagation is never immediate, but always wildfire and propagation is normally planned keeping in mind the worst case, i.e. the maximum TTL indicated.
If we take the example of this DNS zone in BIND9 format for the EXAMPLE.TLD domain we can see that the indicated expire time is 8 hours. Therefore, when we enter the new CloudFlare nameservers, we can expect that many users will continue to query the old nameserver which will return the information it has in the associated DNS zone.
The very serious problem in managing Aruba's domains and DNS is that when you click on "Save settings" in their panel to change nameservers, Aruba's automated system thinks it has the right to delete the DNS zone under their management , probably assuming that since the authoritative nameservers will be other from that moment on, it may be superfluous to have in memory the DNS zone that will never be called.
This creates a problem of epic proportions, with damages that can be as serious as a domain's online presence is important and profitable.
To make it clear that querying a nameserver with a deleted DNS zone is equivalent to receiving no record in response and therefore being unable to resolve the DNS query and therefore unable to be routed to a corresponding IP.
The corresponding error on a Google Chrome browser is the very famous and well-known DNS_PROBE_FINISHED_NXDOMAIN
This practice that Aruba applies, i.e. deleting the DNS zone when the nameserver changes, does not find any functional logic, if not a design error that still today, after many years, reaps victims among their customers.
It would be logical and sensible if you really want to delete the DNS zone no longer in use on the Aruba server, wait for the propagation of the nameservers, and only after at least a couple of days, preferably a week, proceed with a cron task to delete all those DNS zones that are no longer in use in which the change of nameservers has been made for a sufficient time (the canonical two days at least) for the propagation of the new nameservers.
Deep down, even a monkey knows that before letting go of a branch, he must grab another so as not to fall.
This problem documented above is very serious and has an impact, as well as it is not reflected in any best practice or in any standard or RFC currently known and approved at an international level.
Precisely because of its absurdity and a totally incorrect design, no system administrator or developer can imagine such an absurdity until he slams his face in the first person, however forcing you to necessarily plan a downtime if you want to change nameservers.
3. If you have a third level managed by them with Hosting associated with them, you cannot change the DNS pointer.
Let's imagine that this morning, one of our customers decided to outsource the hosting service of a company intranet with related management software, of the type gestionale.nomedominio.it, and let's imagine that once the PHP application and the MySQL database have been migrated to the new server, we modified the type A DNS record gestionale.nomedominio.it to point it to the new, more performing machine.
Imagine now that after a couple of hours nothing has changed and by dig querying their dns zone and their nameservers, the change has had no effect.
We call the technical support of Aruba SpA and looking for clarifications on the matter, they answer us that if the third level is associated with a hosting plan managed by them, it is IMPOSSIBLE (IMPOSSIBLE in textual words) to change the DNS for the corresponding record.
In 2023 being told that it is impossible, it is a literal joke, it would have been more correct to admit the technological limitations and a pioneering and obsolete DNS management system to understand that the only possible solution is to change the nameservers with those by CloudFlare.
A problem that unfortunately refers us to point two of this short list, with all the annexed and connected problems of an infinite loop with no way out other than to schedule the nameserver change starting from 24 hours and notify the customer of a downtime of approx. 6 hours.
This solution is acceptable for SME-type situations but unlikely for companies that need total business continuity.
Conclusion
In conclusion, frustration can only emerge in having to interface with a company like Aruba SpA which, at least in theory, with turnover and budgets in hand, should be and represent the non plus ultra of internet solutions in Italy.
We find it difficult to believe that the problems mentioned above, the subject of almost constant complaints among insiders, have not yet found an effective solution over the years, instead preferring the discontent of consumers and insiders who certainly have more than one valid reason to prefer other domain name registration providers that comply with the needs and expectations that a user requires at the threshold of 2023.
For our part, we always invite you to choose any other supplier for the registration of domain names, avoiding the problems described above right from the start, which makes the profession of web developer and system administrator truly mortifying and humiliating, with continuous and useless expectations that could be solved if the ownership of Aruba SpA decides to modernize their services for the joy of all, themselves in the first place.
We hope that Aruba SpA will take action on the above, solving these problems that have become no longer tolerable by insiders who unfortunately come across these absurdities on a daily basis.
For our part, we will do everything possible by involving sector operators and bodies in charge such as NIC CNR of Pisa, Corecom, Codacons and AGCOM, so that light is shed on the company's working methods and the problems that are anecdotally documented and very limiting.
