Connection to DoT server is not retried

Question

I'm running my own DNS-over-TLS server under my domain (dns.example.com). On my Motorola G100, which is running Stock Android 11, I can set the private DNS to this domain and it works. This works on my Linux machines, two other Androids (some Motorola on Android 10 and a Samsung with Android 10), and also on two different routers (AVM FritzBox can use DoT as upstream).

The server is not at fault, the certificate is valid and all devices work the way they should, that is, until the server is rebooted or otherwise blocked. Then, of course, I receive the notification that it "can't access the private DNS server".

The Linux machines recover and just retry to connect, as well as the routers. But the Android phones don't want to retry even when I know for sure that the connection is working.

Upon disabling private DNS and reenabling with my domain, the following log is shown (IPs removed)

09-30 19:32:46.091  1144 20197 W resolv  : Validating DnsTlsServer <MY_IPV4> with mark 0xf006b
09-30 19:32:46.091  1144 20198 W resolv  : Validating DnsTlsServer <MY_IPV6> with mark 0xf006b
09-30 19:32:46.138  1144 20197 W resolv  : SSL_connect ssl error =1, mark 0xf006b: No such file or directory
09-30 19:32:46.138  1144 20198 W resolv  : SSL_connect ssl error =1, mark 0xf006b: No such file or directory
09-30 19:32:46.138  1144 20197 W resolv  : TLS Handshake failed
09-30 19:32:46.138  1144 20198 W resolv  : TLS Handshake failed
09-30 19:32:46.138  1144 20197 W resolv  : query failed
09-30 19:32:46.138  1144 20197 W resolv  : validateDnsTlsServer returned 0 for <MY_IPV4>
09-30 19:32:46.138  1144 20198 W resolv  : query failed
09-30 19:32:46.138  1144 20198 W resolv  : validateDnsTlsServer returned 0 for <MY_IPV6>
09-30 19:32:46.138  1144 20197 W resolv  : Validation failed
09-30 19:32:46.138  1144 20198 W resolv  : Validation failed

I don't know why it tells my that the handshake fails, all other devices (or kdig +tls) can connect just fine. From the server's reboot to now, no config, certificate or software version was changed.

My guess is that Android caches the connection and "remembers" that it failed at some point in the past and doesn't even try to connect again. I tried rebooting, shutdown, airplane mode, another DoT (dns.google works), disabling DoT but nothing fixes this behavior.

Answer 1

Apparently, Android (even the newest versions) can't deal with the type of certificate that Let's Encrypt generates by default.

The solution is a combination from the Let's Encrypt forum and the setting --preferred-chain="ISRG Root X1" for certbot.

If you use caddy as your server, you can set it in the Caddyfile global options:

{
...
  preferred_chains {
    root_common_name "ISRG Root X1"
  }
...
}

You have to force the renewal of the affected certificates/subdomains by deleting the corresponding files in caddy's data directory. (Beware of rate limiting if you generate many certificates at once.)