I'm using cert-manager to request DNS-01 wildcard authorization for rq.fo, *.rq.fo, and *.jp.rq.fo in one certificate. It's notably trying *.jp.rq.fo first.
It seems to pass the DNS-01 TXT _acme-response checking successfully, then times out on CAA validation. There is no CAA records for these domains nor has there ever been. Here is the exact error from cert-manager:
acme: authorization error for jp.rq.fo: 400 urn:ietf:params:acme:error:dns: While processing CAA for *.jp.rq.fo: DNS problem: query timed out looking up CAA for jp.rq.fo
I tried all 3 authoritative nameservers specifically for CAA and am getting the expected NOERROR with empty response. DNS propagation checker tool reports no timeouts anywhere. I see requests in the DNS server log for CAA corresponding to the timestamps, with valid response:
[2026-01-15T15:55:53Z INFO adns_server::server::respond] [::ffff:23.178.112.106]-A538 CAA jp.RQ.fo -> []
[2026-01-15T15:55:53Z INFO adns_server::server::respond] [::ffff:23.178.112.103]-A56F CAA RQ.fO -> []
[2026-01-15T15:56:04Z INFO adns_server::server::respond] [::ffff:23.178.112.105]-37AC CAA Jp.RQ.Fo -> []
[2026-01-15T15:56:13Z INFO adns_server::server::respond] [::ffff:23.178.112.108]-C9F2 CAA jp.rQ.fO -> []
That subnet is also consistent with other tests, so I can see the DNS server responding to the CAA requests from letsencrypt.
I had a similar issue in the past that was solved by blanket disabling IPv6 for all of my authoritative DNS servers, and that remains gone, IPv4 only.
This has been happening since they expired on 2026-01-11T02:55:24Z, but possibly since the cert-manager recorded renewal time: 2025-12-11T11:06:56Z.
Given that nowhere has been able to replicate the CAA timeout (or any timeout/nonresponse issues from my DNS servers), I'm left to believe the issue must be somewhere in LetsEncrypt network. Happy to provide any other needed details.
This is happening with several other domains I control as well.
It might not really be CAA specifically. If the DNS lookups are slow enough, then there's an overall timeout that can get hit. And the point in the process where that happens is during CAA lookups, so that's what's in the error message.
When using unboundtest, I get a similar timeout: (Hard to understand all the debugging messages there, but the last line says "i/o timeout" which means that the overall resolution process took too long.)
DNSViz also says that your DNS servers aren't replying:
rq.fo zone: The server(s) were not responsive to queries over UDP. See RFC 1035, Sec. 4.2. (147.135.104.178, 147.135.104.190)
The ISC EDNS compliance checker says that your servers aren't returning the exact responses it's expecting either:
I don't really have answers for you, just sharing these tests I've done. What DNS software are you running, and is there anything even remotely odd in how it might be configured, or what gets routed to it? Are you expecting all your DNS servers to be globally accessible? I'm not sure why you were expecting disabling IPv6 on them would have helped anything, either, can you explain more about what routing issues you were having that led to you doing that?
I couldn't access two of the machines at all over IPv6 from my home network, so I figured it was some weird routing error/DC issue with IPv6. I left it like that for a few years before the crawling error rate annoyed me enough to just remove IPv6 entirely. That was like a year ago.
The DNS server running I'm running is probably the most unique thing to my situation -- it's one I wrote a few years ago called "adns" for fun. I've tested it fairly rigorously, but there isn't any EDNS support that I've added to it. I've been running it here with LetsEncrypt for several years with no issues.
It's interesting that you got UDP non response on those two IPs, I'm able to query them for general or CAA records without issue from my location. I'm wondering if the DC is doing the same funny things that it did with IPv6.
I'll crawl through that DNSViz report and see what I can see. Thanks.
We've seen quite a few cases around here where people were using custom-written DNS software and ended up not quite following the specs exactly which sometimes caused trouble for Let's Encrypt's resolvers, even though many other resolvers managed to work around it enough for many other use cases. Not saying that there's any specific problem with your software, just that DNS is much more complicated than it seems at first.
Just as another random networking thing you may want to look at, if it seems that reply packets sometimes aren't making it where they should, is to confirm that you don't have anything blocking Path MTU Discovery (that is, that blocks ICMP packets that are actually needed). That can sometimes lead to packets that don't get delivered, especially with larger packets.
Some random sites describing it, I know there are more and various testing tools out there somewhere too: