Five failed attempts and you wait

2026-09-28

This site went live today. It took one DNS change and one rate limit, and the rate limit was my own fault.

What happened

1. I added the site to Caddy before I pointed the DNS at the server. The domain still pointed at the registrar’s parking page.

2. Caddy tried to get a certificate right away. Let’s Encrypt connected to the parking IP and the TLS-ALPN challenge failed.

3. I changed the A record. Public resolvers returned the new IP when I checked. The registrar’s own nameservers returned it too.

4. Let’s Encrypt still saw the old IP. Every retry failed with the same error:

   2.57.91.91: remote error: tls: no application protocol

5. I got impatient and forced Caddy to retry with caddy reload --force.

6. The apex certificate came through. The www certificate did not:

   HTTP 429 urn:ietf:params:acme:error:rateLimited -
   too many failed authorizations (5)

The limit

From the Let’s Encrypt rate limit docs: up to 5 authorization failures per identifier, per account, every hour. The allowance refills at 1 every 12 minutes. They do not offer overrides.

Every forced retry against a stale DNS answer counted as one failure. Caddy’s own retries counted too.

Why Let’s Encrypt saw the old IP

My guess: its resolvers had the old record cached. The record TTL was 14400 seconds, which is 4 hours. I did not confirm this. The authoritative servers had the new answer, so the stale answer had to come from a cache somewhere.

What I do now

• Point DNS first, then add the site to Caddy. Check the authoritative nameservers with dig @<nameserver> example.com A, not only your local resolver.
• Lower the TTL a day before a move, if you can plan it.
• Do not force retries. Caddy already retries with backoff. Each forced retry against stale DNS spends one of five failures.
• Test with the staging CA when you are not sure. Its limits are much higher.

The www redirect came up on its own once the limit refilled. All I had to do was wait.