How to Remedy SERVFAIL during Caddy + DuckDNS Certificate Challenge

by Rian

Caddy is a tool I use for home lab HTTPS management. However, the tool is not bulletproof. It’s not a simple GUI tool to add services and forget. One such problem Caddy can introduce with HTTPS is during the challenge to obtain a certificate. Because the certificate has to be renewed periodically, even if it succeeded at one point, it may fail or give out an error tomorrow.

I’ll get straight to the remedy that worked for me, and explain my theory of what must be happening behind the scenes:

*.somename.duckdns.org {
    tls {
        dns duckdns {env.DUCKDNS_TOKEN}
        propagation_delay 2m
        # Bypass local DNS for ACME challenge lookups
        resolvers 1.1.1.1 8.8.8.8
    }

    ...

}

From what I could find, it was not DuckDNS that went down. DuckDNS did have slow propagations, so I decided to put in the delay of 2 minutes; but it was largely irrelevant. The problem was the DNS resolver. SERVFAIL doesn’t mean the query went nowhere. It means the resolver answered but couldn’t finish resolving. In my previous setup I did not specify a resolver, so Caddy defaulted to the local ISP. That automatic fallback is exactly what kept failing. Pointing it at more reputable ones solved the issue immediately.

To the tangent of the tangent: pointing Caddy at a resolver of my choice is a workaround, and the standard infrastructure my ISP runs may or may not respect that path. What’s more unfortunate is where the effort goes. Not into the resolver sitting in disrepair, but into a genuine interest in censorship: SNI-based filtering (already in place), and against ECH as well. If done right, ECH would keep the ISP blind to which sites a user reaches. The investment is in surveillance, not in competence. As a consumer and a hobbyist, all I can say is: I hope I’m not paying for this broken ISP DNS.