FaunaDB custom domain: DNS resolution error before TLS handshake

Answer first

An error like Name or service not known that occurs before any TLS handshake means the failure is in DNS resolution, not in certificate issuance or validation. CAA records and the certificate chain only matter after the client has resolved the hostname and opened a TCP connection. So of your three hypotheses, only the first — a missing or incorrect A record — can produce this symptom.

Why the other two causes are ruled out

• CAA record: A restrictive or missing CAA entry prevents Let's Encrypt from issuing or renewing the certificate. The client never sees this directly; it would manifest as an expired or missing certificate after DNS resolves, typically as a TLS handshake or trust error, not a resolution error.
• Certificate chain: Strict client-side validation failures surface as handshake errors (unknown issuer, hostname mismatch, expired cert). The handshake cannot even begin until the name resolves, so a DNS error proves the problem is upstream of certificates entirely.

What to check

Confirm what the custom domain actually resolves to:

dig +short your-domain.example.com A
dig +short your-domain.example.com CNAME

If this returns nothing, or returns IPs that do not belong to Fauna's edge infrastructure, that is your root cause. Common misconfigurations in this situation:

1. The A record was never created, or was created on the wrong zone (e.g., at a different DNS provider than the authoritative one).
2. The record was created for www.your-domain but the client connects to the apex, or vice versa.
3. Old edge IPs were hardcoded. Fauna's edge addresses are anycast and can change; copying IPs from an old setup or a forum post is unreliable. Use the current values from Fauna's dashboard/documentation for your database's region group.
4. DNS propagation or TTL: a recently changed record may not be visible from the client's resolver yet. Compare dig @8.8.8.8 against your local resolver to spot caching discrepancies.

After DNS resolves, verify the rest

Once the A record is fixed, proactively confirm the other two layers so you do not hit a second failure:

dig +noall +answer CAA your-domain.example.com
openssl s_client -connect your-domain.example.com:443 -servername your-domain.example.com </dev/null

The CAA output should include issue "letsencrypt.org" (or there should be no CAA record at all, which permits any issuer). The openssl output should show a Let's Encrypt-issued chain with Verify return code: 0 (ok).

Uncertainty

This assumes the error string comes from the client's resolver and not from a proxy or VPN in the path that rewrites DNS. If dig resolves correctly from the same machine but the client still fails, the missing diagnostic is whether the application runs in a container or network namespace with a different resolver configuration — that would change the recommendation from fixing the zone to fixing the runtime's DNS setup.