Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
The operating system my web server runs on is (include version):
Apache 2.6
My hosting provider, if applicable, is:
Myself
I can login to a root shell on my machine (yes or no, or I don't know):
Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
1.30.0
Does ProWeb DNS have a firewall or maybe DoS protection for your DNS? If so, they may be blocking the Let's Encrypt Server IP addresses.
I say this because I also see your DNS records from my own test server. And, so does the unboundtest.com site that looks up DNS similar to how Let's Encrypt Servers do it.
The Let's Debug test site debug info shows this same pattern. The Debug site's own tests for your DNS are fine. But, it's test using the Let's Encrypt staging system fails to lookup your DNS.
I did see that dnsviz.net reported some UDP issues but I am not sure what impact that has.
You may need to wait for better DNS expert to respond. It's worth checking security settings at Pro Web though just in case.
I just repeated the Let's Debug test and the Let's Encrypt staging servers got a SERVFAIL for the AAAA record. You don't need an AAAA record (IPv6) but the DNS servers should respond with "not found" and not a SERVFAIL.
I can't reproduce that myself but this more strongly points to an issue with your DNS service provider.
I've also noticed that the authoritative DNS servers don't support 0x20-case-randomization (a query in mixed case always returns a response in lowercase). My understanding is that doing so doesn't technically break any "rules", but Unbound (or at least the way Let's Encrypt configures it) prefers random-case queries and the case echoed back in the response in order to help prevent some types of spoofing. I think that Unbound should be understanding pretty quickly that the server only returns in lowercase, so I don't think it's actually the cause of the problem you're seeing, but it may be something that is helping compound some other issue.