So cloudways says I have to remove the AAAA in my DNS
so I went to DNS of Cloudflare but didnt see any AAAA,
went to my old server, still no AAAA,
asked my domain registrar and redirect me back to clouflare.
So can someone help me remove the AAAA in my DNS?
Thanks for the help
its not Cloudflare asking for that, its cloudways.
this is the reply to me of cloudways:
I can see that the AAAA records are not present in the Cloudflare, but they are present in the DNS , that is why they are showing on the tool You would be needing to contact the DNS Registar of yours for the removal of these records from the DNS of yours, so that the SSL could be installed for you.
I dont know what Cloudways is but their response does not make too much sense.
Your domain is associated with two IPv6 records and these records are properly in place and there is no need to remove them. You need to clarify this with Cloudways I am afraid.
Certificates have nothing to do with IP addresses. I am sorry, it seems Cloudways is either confused about the setup or does not really know what they are talking about. What you can do is temporarily pause Cloudflare and have all DNS records point straight to your server.
Do you mean by “validation” an HTTP based certificate validation? Would that mean they have an issue to validate a certificate when there are IPv6 address in addition to IPv4 ones?
So do I get this right, even though there are (for them) perfectly fine A records available they (despite not being able to handle IPv6 records) still query AAAA records and then freak out.
Cloudways offer Managed Cloud Hosting on popular providers like Amazon, Digital Ocean , Google etc By default the server’s don’t come with IPv6, if anyone has a server directly from one of the providers then they can purchase an IPv6 at an extra cost but on Cloudways (the server bought via them) this option is not available.
They offer Free SSL via Let’s Encrypt Service, Let’s Encrypt Services require that to get SSL the domain should be pointed to the Server IP as the process verify whether the request is authentic or not for the domain to issue the SSL as it’s not like that I can just issue SSL for any domain like facebook(dot)com because I initiated a request so that’s where the authentication process comes in, it’s called acme_challenge.
Since by default the servers don’t have IPv6 there is no need to set AAAA records in your DNS settings so if we don’t have Cloudflare enabled and we don’t set AAAA the request is authenticated and the SSL is issued. as the request is sent at A (IPv4) only while there are no records for AAAA(IPv6) the request isn’t sent for authentication.
But if we add Cloudflare on our domain then Cloudflare adds IPv6 although we don’t have any AAAA (IPv6) instead of showing a red checkbox here https://www.whatsmydns.net/ it starts to show AAAA records, so once Cloudflare is enabled and someone try to issue the SSL the authentication request sent on A (IPv4) records is verified while the AAAA (IPv6) never reaches the server and hence the SSL authentication is failed with an error msg like “AuthorizationError: Some challenges have failed.”
This issue might not just be related to Cloudways but all other users as well who are directly hosting the site on any of the providers or any provider with having servers only IPv4 enabled.
The similar case has been discussed here as well SSL at Weebly Not Working due to Hidden AAAA Record Here the solution was to disable IPv6 via API but that should not be the case a simple option should be available in Cloudflare Dashboard to disable IPv6 as not every user is technical and shouldn’t have to deal with this.
So what Cloudflare needs to do in my opinion is that they should not simply enable AAAA records if the records are not present in the domain DNS settings or provide an option to its users to disable IPv6.
I am afraid it does not. The IPv6 addresses issued by Cloudflare have nothing to do with Cloudways. If they really charge for IPv6 that is up to them of course, but that does not affect the proxy, the addresses issued by Cloudflare or how requests end up at the origin.
It still is not clear what the actual issue of Cloudways is but it would appear their system simply is broken.
Totally understand what you’re saying, but I think ultimately we will have to agree to disagree. When Cloudflare rolled out IPv6 we literally doubled the number of websites accessible via IPv6 on the internet within the course of a few weeks. We see it as a positive forcing function (in much the same way as Apple now requiring app sites to support IPv6 for it’s app store).
Until a year or so ago there was a button to disable IPv6 (there actually still is on our ENT plans) but we looked at the reasons IPv6 was being disabled by folks and there were very few legitimate ones… so we made the decision to remove the option from the UI (the option to disable it still exists, but it is API only now for self serve plans).
I get that Cloudways has an issue in their code with IPv6 addresses and I’m not really blaming them… everyone has issues in their code. But the issue isn’t that the address (IPv6) being advertised isn’t associated with the server/site. Because when a site is the IPv4 address isn’t the one associated with the site either… it’s the IPv4 address of Cloudflare’s proxy.
This can be worked around by a non-technical user by simply the record during validation or if they want to disable IPv6 and loose the performance and other benefits they can figure out the API call. That may not be the most user friendly approach on our part, but we think IPv6 is so important to the future of the internet that we made the conscious decision to remove the “easy button”.
In the same way Weebly and Cloudways have made the business decision not to fix their scripts for SSL issuance we’ve made the decision to do what we can to encourage IPv6 support as the default on our platform.