DNS verification troubleshooting

When you add a custom domain, Elido polls DNS every 30 seconds to look for the records we asked you to create. Usually verification completes within 60 seconds. When it takes longer, this checklist covers what's almost always wrong.

Confirm the records exist from outside your network#

The first check is whether the records are visible publicly, not just at your registrar.

dig links.acme.com CNAME +short
# expected: <something>.elido.me.

For an apex domain:

dig acme.link A +short
# expected: 2 A records (Hetzner FRA + OVH FRA)

dig acme.link AAAA +short
# expected: IPv6 from one of those PoPs

If dig returns nothing, the registrar hasn't propagated yet — or, more often, the record was saved with a typo.

Common typo patterns#

Compare the record value against the exact value Elido showed you in Settings → Domains → [domain] → DNS records. The most common mistakes:

• Trailing dot. Some registrars require <target>.elido.me. (with the trailing dot); some auto-add it. Pasting <target>.elido.me. into a registrar that auto-adds it yields <target>.elido.me.. — invalid. Try without the trailing dot.
• Hostname instead of FQDN in the Name field. For links.acme.com, some registrars want links in the Name field, not links.acme.com. If you typed the full FQDN, you've actually created links.acme.com.acme.com.
• Wrong record type. A subdomain needs CNAME. An apex needs A (or ALIAS). If your registrar doesn't support apex CNAME flattening, switch to A records — we provide both options in the DNS instructions panel.

Apex (zone-root) domains#

CNAMEs at the apex are forbidden by the DNS spec. If you're trying acme.link (not links.acme.com), you have three options:

1. Use the two A records we provide. Works everywhere.
2. Use ALIAS / ANAME if your registrar supports it (Cloudflare, DNSimple, easyDNS). It flattens to the right A records automatically.
3. Pick a subdomain instead. go.acme.com or links.acme.link is easier and CDN-friendlier than the apex.

Cloudflare proxy (orange cloud)#

If your domain is behind Cloudflare's proxy (orange cloud on), DNS verification still works but TLS provisioning fails. Cloudflare terminates TLS itself, so our Caddy never sees the visitor and can't issue a certificate.

Turn the orange cloud off (DNS only / grey cloud). Cloudflare will serve as authoritative DNS only; we handle the proxy.

If you genuinely need Cloudflare's DDoS layer in front, use Cloudflare's Origin CA certificate and upload it to Elido under Settings → Domains → [domain] → Custom certificate.

CAA records#

If your domain has CAA records, they must allow Let's Encrypt:

dig acme.link CAA +short
# if the result has any lines, letsencrypt.org must be one of them

If you see 0 issue "letsencrypt.org" in the output, you're fine. If you see CAA records for other CAs only, add one for Let's Encrypt:

acme.link.    CAA  0 issue "letsencrypt.org"

DNSSEC mismatch#

If your registrar has DNSSEC enabled but the DS records weren't published correctly, public resolvers will return SERVFAIL instead of your records. Run:

dig +trace links.acme.com

If the trace ends in SERVFAIL, fix DNSSEC at your registrar before continuing — usually by disabling DNSSEC, waiting an hour, and re-enabling with the correct DS records.

Verification poll cadence#

We poll DNS every 30 seconds for the first hour after you added the domain, then every 5 minutes for the next 24 hours, then every hour thereafter. You can click Verify now any time to force an immediate check.

If your domain stays Pending for 24 hours and dig from outside your network shows the right records, click Verify now once — sometimes our cached negative result from earlier propagation lingers.

What "verified but no TLS" looks like#

If DNS is verified but the domain shows "TLS pending" for more than 10 minutes, Caddy is having trouble with Let's Encrypt. Causes:

• CAA records (see above).
• Rate-limiting from Let's Encrypt (50 certs/week/registered-domain). Hit this only on very high-volume rollouts.
• TLS-ALPN challenge blocked by an upstream firewall. Open port 443 to our ingress IPs (listed on our trust page).

Troubleshooting#

Verification works from my laptop but not from the dashboard. Your laptop is using your local DNS resolver; our verifier uses public resolvers (1.1.1.1, 8.8.8.8). If your registrar hasn't propagated globally, public resolvers may not see the record yet. Use dig @1.1.1.1 links.acme.com to confirm what we see.

Records look right but Verify keeps failing. Lower the TTL on the records to 300 seconds and wait 10 minutes. High TTLs make negative caching painful.

Apex CNAME flattening was enabled but verification failed. Cloudflare flattens at query time, but only for queries through Cloudflare's resolvers. Public resolvers see the CNAME and reject. Switch to A records explicitly.