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
In the field of information technology and networks, it is common for confusion to arise between seemingly similar terms but which refer to different concepts or elements. This is especially true when it comes to DNS, or Domain Name System. In particular, the expressions "DNS Zone" and "Nameserver" are often used interchangeably, generating ambiguity. However, there is a clear distinction between these two definitions.
To start, the nameserver is a server where the DNS service runs. The main job of a nameserver is to answer queries about Internet addresses, transforming domain names into IP addresses. To do this, use specific software, such as Bind or PowerDNS. Thus, a nameserver could be likened to a "book" or database that contains all the information needed to translate domain names into IP addresses.
A DNS Zone, on the other hand, is a part of a DNS global name space domain. More specifically, it is a collection of DNS records that together define information about a particular domain or subdomain. These records provide instructions on how to handle requests for that domain, and may include information such as the web server's IP address, mail server, and other specific information.
To better understand, we could draw a parallel with the world of Database Management Systems (DBMS). In this case, a DNS server would be equivalent to an instance of a MySQL server, while the DNS zone would correspond to a specific database within that instance. Each DNS record, then, would represent a single row within that database.
This distinction is critical to understanding some of the issues that can arise when working with DNS service providers. For example, without a clear understanding of these differences, vendors like Aruba can make significant mistakes, leading to problems for their users. It may happen, for example, that a user wants to change only the records within a specific DNS Zone, but due to unclear communication or insufficient understanding, the provider may change the entire nameserver, causing unnecessary interruptions of the service or other problems.
If you want to better understand how DNS works, read this post.
List of Aruba Spa domain management issues
In this analysis, we want to highlight some of the more evident problems in the management of the DNS by Aruba SpA, which we consider limiting and restrictive. These problems, while serious, could be resolved with relatively simple actions, such as changing the default settings, updating company policies or changing a few lines of code in the DNS interface.
1. TTL Too high by default.
Time to Live, or TTL, is a fundamental concept in the world of DNS. This is the period of time during which the information provided by an authoritative DNS remains valid. This period is expressed in seconds and is set by the authoritative DNS for a given domain.
To put it simply, if we set a TTL of 24 hours (86400 seconds), we are telling all nameservers querying our authoritative DNS that the information they provide (for example, an A record mapping a domain name to an address IP) will remain valid for the next 24 hours.
The problem arises when there is a need to make changes to these records, for example, to migrate a domain to another provider or to change the IP address of a web server due to a data center problem. Until the TTL expires, these changes will not be visible to nameservers worldwide, which will continue to use the old information.
So, in an ideal world, the TTL should be kept as low as possible. This would allow changes to be propagated within minutes, minimizing downtime. A reasonable TTL value should never exceed 15 minutes.
However, some DNS service providers, such as Aruba SpA, set the default TTL to 6 hours (or even 24 hours in the past). This means that, if we needed to change the IP address of a web server, we would have to wait 6 hours for the change to be propagated worldwide. This delay can significantly impact your ability to respond quickly to emergencies or implement planned changes efficiently.
For example, if we needed to change the "@" record or the "www" record for a domain registered on Aruba, we would have to wait at least 6 hours to do so. This makes it difficult to implement changes quickly, as might be necessary in case of a change of provider or if you decide to point the domain to a new IP.
From our point of view, working with domains registered on Aruba can be complicated, as you cannot operate efficiently in emergency situations. In fact, in order to change the IP of one of our hosting on an Aruba domain, we should first lower the TTL value to the minimum value allowed (30 minutes), then wait 6 hours and finally switch to the IP of our hosting, waiting additional 30 minutes for the change to propagate. This long wait can have a significant impact on our ability to respond effectively and promptly to our customers' needs.
2. Aruba deletes the DNS zone when replacing the authoritative Nameservers.
One of the most serious errors encountered with Aruba Hosting concerns the management of the DNS zone during the replacement of authoritative nameservers. This behavior, which has been present for many years, can have significant consequences, including loss of ranking, indexing of websites and, in some rare cases, exclusion from Google News. It can even lead to significant revenue losses, especially for businesses that rely on their online presence.
To understand the extent of the problem, let's imagine that we want to switch from using Aruba's nameservers, with the limits described above, to third-party nameservers. This can be motivated by different needs, such as the search for better performance, the need to reduce the Time To First Byte or the obligation to use services such as CloudFlare, which require the use of their authoritative nameservers.
Once we've recreated the DNS zone on the new nameservers (for example, using CloudFlare's auto-import feature), we can proceed with replacing the standard Aruba nameservers with those from the new vendor. For example, we could switch from Aruba's standard nameservers (dns.technorail.com, dns2.technorail.com, dns3.arubadns.net, dns4.arubadns.cz) to those provided by CloudFlare, such as foo.cs.cloudflare.com and pluto.cs.cloudflare.com.
Important to note is that the change of nameservers does not happen in real time, but can take up to 48 hours. During this time, worldwide nameservers, web clients, and all visitors' browsers can continue to query the DNS zone on Aruba's old nameservers, which should respond with the DNS information they have in memory.
Herein lies the main problem with Aruba's DNS management: when you change nameservers in their control panel, Aruba's system deletes the DNS zone they manage. This action appears to be based on the assumption that since the authoritative nameservers will be different, it is no longer necessary to keep the old DNS zone 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 behavior creates a potentially catastrophic situation, since querying a nameserver whose DNS zone has been deleted is equivalent to receiving no records in response. This means that it will not be possible to resolve the DNS query, and as a result, customers will not be able to reach the corresponding IP address.
The typical error that a Google Chrome browser displays in this scenario is 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.
Actually, a more reasonable practice would be to keep the DNS zone in memory on Aruba for some time after the nameservers change, for example, at least as long as it takes for new nameservers to propagate. This time should be at least 48 hours, but it may be better to wait up to a week to be safe. Only then could the unused DNS zone be removed.
Deep down, even a monkey knows that before letting go of a branch, he must grab another so as not to fall.
This way, you would avoid the “missing DNS zone” problem, which is not covered by any internationally recognized best practice or standard. Also, it would avoid imposing on customers the need to schedule downtime when they decide to change their nameservers. This current situation is unacceptable and needs to be reviewed to ensure a more reliable and uninterrupted service.
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.
If you manage a third-level domain with hosting provided and managed by Aruba, you will encounter a significant problem: you cannot change the DNS pointing. This limitation can become a considerable problem, especially when it comes to performing migrations or improvements of hosting services.
Imagine, for example, that your customer decides to move a corporate intranet hosting service, including a management platform, from Aruba to another service provider. Let's assume that the migration of the PHP application and the MySQL database went smoothly on the new, more performing server and that you modified the DNS type A record for the subdomain (for example, gestionale.nomedominio.it) so that it points to the new car.
After a couple of hours, however, you realize that nothing has changed. By querying Aruba's DNS zone and nameservers with the "dig" command, you discover that your change has had no effect. When you contact Aruba SpA technical support to seek an explanation, you are told that if the third level domain is associated with a hosting plan managed by them, it is impossible (textual words) to make changes to the DNS for the corresponding record.
Being told in 2023 that such changes are “impossible” may seem like a joke, as if Aruba is denying technological advances and adhering to an outdated and primitive DNS management system. The reality is that the only possible solution would be to change the nameservers to use those of CloudFlare.
However, this approach leads again to the problem of deleting the Aruba DNS zone when changing nameservers, as already discussed above, creating an infinite loop of problems with no apparent solution, unless you schedule the nameserver change starting at 24 hours and communicate to the customer a period of inactivity of approximately 6 hours.
This solution may be acceptable for small and medium-sized businesses, but it is completely inadequate for companies that need uninterrupted business continuity. This underlines the importance of having a more flexible and modern DNS management system, which allows changes and updates without creating service interruptions or unnecessary constraints.
Conclusion
To conclude, it is inevitable to underline the dissatisfaction that arises from having to interact with a company like Aruba SpA This company, at least judging by its turnover and financial statements, should represent the point of reference for Internet solutions in Italy. Despite this, the experience of users and insiders seems to contradict this leadership role.
It is disconcerting to note how the problems mentioned above, which are the subject of continuous complaints from operators in the sector, have not yet found an effective solution over the years. It almost seems that Aruba prefers to tolerate the discontent of consumers and professionals, who undoubtedly have valid reasons for choosing other domain name registration providers, more responsive to the needs and expectations that a user may have in 2023.
For our part, we always recommend choosing another provider for registering domain names, in order to avoid the problems described above right from the start. These issues can make the profession of web developer and system administrator frustrating and humiliating, with constant and unnecessary expectations that could easily be avoided if the owners of Aruba SpA decide to modernize their services.
We sincerely hope that Aruba SpA takes steps to resolve these problems, which have become unsustainable for the professionals who come up against these absurdities every day. This is a call for innovation and improvement, so that Aruba can once again become a point of reference in the Italian web panorama.
In response to these concerns, we intend to do everything possible to involve sector operators and bodies in charge such as NIC CNR of Pisa, Corecom, Codacons and AGCOM. The goal is to shed light on the company's working practices and on the issues that, as we have documented, can be limiting. We want to ensure that users and professionals can take advantage of efficient, modern domain name registration services that meet the needs of the 2023 market.
