Please fill out the fields below so we can help you better.
My domain is: thepartsbox.com
I ran this command: Trying to renew a 30day SSL Certificate
It produced this output: Cant remember the wording but said there was a CAA problem.
My web server is (include version): N/A
The operating system my web server runs on is (include version):N/A
My hosting provider, if applicable, is: Netregistry (Ezyreg)
I can login to a root shell on my machine (yes or no, or I don’t know): No
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): cPanel
I’ve used letsencrypt for a SSL script for a website I help manage about 90 days ago and it went through perfectly with no issues.
However; upon trying to renew it today I’m getting an error saying the servers are not CAA.
I’ve contacted netregistry support and they said the ezyreg domains don’t support CAA.
Is there a bypass or a way past this?
If you search "ezyreg" in this forum you will see several posts regarding these CAA issues. Seems ezyreg is not very worried about this even if this check is MANDATORY for all Certificate Authorities, not just LEt's Encrypt since 8th September.
Yes, if as a customer ezyreg ignores you and the problem, change your DNS provider, you have several free alternatives out there that supports CAA correctly like cloudflare.
I would switch DNS providers if they are unable to allow you to add a simple one line CAA record
@ IN CAA 0 issue "letsencrypt.org"
into your zone file. That’s just nonsense and sound to me like a company who has no idea about DNS whatsoever.
This is worst than you think, they don’t even need to allow to create CAA records, they just need to answer correctly that there is no CAA records, that’s all, if they answer correctly… they would say, ok, you are requesting a CAA record but we have nothing to you… that should be ok to Let’s Encrypt but they answer with a SERVFAIL which is not an appropiate answer.
Note: They don’t answer SERVFAIL directly, they just timeout for UDP CAA requests which means a SERVFAIL for the DNS client trying to get those records.
I’d be happy to change DNS provider but I’d essentially need to take off an entire sql database of client things, php shop and webfront etc.
It’s a huge amount of time and effort for something they should be doing anyways.
So realistically, best case scenario is going to be change DNS/hosting provider?
I'm not saying that you should change the hosting provider nor move your stuff to another site, you just need to change the Authoritative NS servers for your domains and recreate the same records you have currently with EzyReg NS servers which should be transparent (or almost) for your customers/services.
If EzyReg is your hosting provider maybe they have some kind of policy/requirement to use only their name servers, if that is the case then you are not a lucky guy but if that is not the case, you can change the DNS servers for your domain with no pain ;).
1.- The best scenario would be that EzyReg fix their CAA issues immediately.
2.- If there is no need to use their NS servers, then change the DNS provider right now.
3.- If 1 and 2 aren't options for your situation then you should move forward and change to another hosting provider.
I know, but unfortunately there are far too many people out there running DNS systems, selling domain names and they have absolutely little to no knowledge whatsoever on DNS. I come across mis-configured DNS systems on a daily basis but they have a guy with a piece of paper hanging on the wall above his desk which says he passed computer school and he knows everything
Firstly, the problem is NOT with NetRegistry.
Let’s take a sample domain (drumdigital.com.au).
As noted in: LetsEncrpyt & NetRegistry (Australia) - Resolved?
When you query DNS via TCP, (dig CAA drumdigital.com.au. @ns-1.ezyreg.com. +tcp), it works.
When you query DNS via UDP, (dig CAA drumdigital.com.au. @ns-1.ezyreg.com. +notcp), it fails.
There is something between the LetsEncrypt and NetRegistry data centres that cause the problem. Isolating what/where the issue is going to be difficult. In my testing, I have found that different data centres within Australia have issues as well. It sometimes works with UDP. But it ALWAYS works via TCP.
In fact for the Australia data centres where the query is actually reponded to, the data sent back is incorrect (An A record answer is returned rather than an empty response indicating no CAA record).
As noted here: DNS problem: query timed out looking up CAA (using Netregistry), another issue is that Unbound – used by the Boulder software – never falls back to using TCP.
There are a few ways to attack the problem:
- end-clients migrate the nameserver business elsewhere
- Have Boulder perform all CA related DNS queries over TCP.
- get the intermediate network operators to fix the root cause
For (2): Boulder could be configured to only perform DNS queries via TCP. RFC7766 suggests that all DNS servers must support this. In https://unbound.nlnetlabs.nl/pipermail/unbound-users/2017-April/004775.html, Paul Vixie, creator of DNS, thinks it is a good idea but does not believe it will work in practice.
If LetsEncrypt demanded TCP connectivity to DNS servers, it would have a significant first-mover advantage and likely change the Internet to require queries of DNS over TCP to function (which would be good).
For (3): I have done some debugging and raised issues with the NOC team at tpg.com.au (NetRegistry’s transit provider from what I can determine) and their own NOC.
Thanks for the additional information! In our tests against NetRegistry, sometimes using TCP helps, and sometimes it does not. It appears to depend on the day.
We have been discussing using TCP first for all lookup. Our tests have shown that TCP support in DNS servers is not yet widespread enough to do TCP-only, but if we did TCP first with UDP fallback it would potentially improve some issues of this sort, and improve resilience against DNS reply forgery. To do this, we would need to run a separate set of Unbound servers configured with
tcp-upstream: yes, and modify Boulder to check those first, with a timeout and fall back to a secondary set. It’s something we’d like to do, but given that our tests show that it wouldn’t conclusively fix the NetRegistry problems, it hasn’t been a top priority.
I’ve been running DNS systems for 28 years now. DNS must always respond on UDP and TCP Port 53 and it’s going to take years before that ever changes. The new age of poorly configured mass tech just does not gel with me, standards are there to be adhered to and major tech companies think they can just do their own thing. I come across major networks on a daly basis who cannot answer simple queries over 53 UDP. Sorry for them but their DNS is a mess plain and simple.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.