Cloudatcost, the canadian cheap & flat cloud VPS provider (partner of @Fibernetics) seems to have really serious problems on the devops side. I already talked here about their infamous backdoor user (“wikus”) on their Debian 8 x64 VPS images (this seems to be solved by now).

Today I found out that they also seem to have a faulty Reverse DNS update call that they either don’t want or are unable to fix.

TL;DR: You want your IP to have a proper Reverse DNS entry pointing to your Flly Qualified Domain Name. You make this change in your Panel. The function is buggy, RDNS won’t work. You open a ticket. The ticket is already 6 days old, but is still not assigned.

Step to reproduce:

  1. Login to your panel page (

  2. Click on “Modify”, then on “Reverse DNS”. screengrab cac01

  3. Use the popup frame to set the DNS PTR entry for the IP that Clouadatcost assigned to your VPS to point to your FQDN (say

  4. Wait the given 10 minutes for the update to take place (you may also wait a day, ten days or so… it probably won’t change EVER).

  5. Open your terminal and perform a reverse lookup for your given IP Address and check if it gives you back the requested FQDN entered on step #3. One of my servers points to a cloudpro internal ID hostname. Another VPS I have points to someone else’s mailserver FQDN (!).

Further investigations (DOM inspection of the function call) led me to suspect they may have made a mess with VPS root passwords and then the function fails because of mismatching passwords.

screengrab cac02

I will update this post when (and if) they will care to fix the issue (or consider my tickets).

#20160218 UPDATE: They finally managed to work on my ticket: “this should be fixed today, there is an issue with the panel setting. thanks for your patience.”. Then, after a couple of hours, ticket was closed by Cloudatcost Co-Founder Gerald Camacho (what an honor!):

screengrab cac03

Now the IP are correctly resolved to the names I entered in the panel, BUT… as I was trying to set properly one of them (I made some tests, so in one case it was not the actual FQDN I’d intend to use in production), it turned out that the “fix” didn’t fix: no frther changes really take place anymore (already waited for the whole weekend). They probably set the DNS PTR by hand.

Going to open another ticket now…