The current hypothesis I have is that yes, the nameservers for the .ru zone (<letter>.dns.ripn.net.) aren't supporting case-echoing, and the unbound instance that Let's Encrypt uses to resolve the name isn't falling back to not requiring it for that name. Case echoing is something that doesn't seem to be strictly required by the standard, but most DNS servers do. Unbound should be able to detect that the DNS server doesn't do that, and fall back to not requiring it, in most cases.
I do remember one instance (in this thread) where packets were getting sporadically lost between Let's Encrypt's validation servers and the DNS servers, which caused the Unbound fallback logic to get invoked because it thought the server wasn't handling case-echoing even though it did. I don't think that kind of thing is happening here, but it can be hard to tell if something somewhere might be dropping packets and throwing a big wrench into things.
Most telling to me is that Unboundtest, which is in theory configured the same way as Let's Encrypt's validation servers, seems to be able to resolve things fine. Plus, that this seemed to be working for you up until at least a couple months ago. I think that leaves two main possibilities:
- There was some upgrade (or other configuration change) to Unbound that's been made to the Let's Encrypt validation servers within the last couple months, but has not been made to Unboundtest. @jsha, is there any chance you can take a look at this possibility?
- There's some sort of network routing issue, where Let's Encrypt's validation servers (both primary and secondary!) are hitting some kind of different path than Unboundtest is, going to a different DNS load-balancer or dropping more packets or something along those lines.
And to emphasize, this is all just a hypothesis based on conjecture and circumstantial evidence, it wouldn't shock me if the real problem was actually something else that we haven't discovered yet.