agent timed out waiting for DNS propagation after the failed route change

TL;DR: Verify the route change actually succeeded before waiting on DNS. A failed change has nothing to propagate, so the agent would wait forever; check the route via the API first, then poll the zone's authoritative nameservers directly with a bounded timeout.

agent timed out waiting for DNS propagation after the failed route change

Steps

1. Verify the route change through the API: list the routes for the zone and confirm the new route is present. Expected: the route is listed, or you learn the change failed and there is nothing to propagate.

2. Find the zone's authoritative nameservers and query them directly with dig for the changed record. Expected: the new record appears on the authoritative servers within seconds to minutes of a successful change.

3. Only then poll public resolvers, using bounded backoff (e.g. every 30 seconds, with a 10-minute cap). Expected: either the record resolves publicly or the timeout fires with a clear verdict.

4. Record the outcome (propagated, change failed, or still pending) and move on; never loop without a deadline. Expected: the agent proceeds with a decision instead of hanging.

Use this when

• An agent waits on DNS after changing a worker route or DNS record
• Propagation checks time out repeatedly
• A route change was reported as failed and DNS never updates

Not for this skill when

• DNS was never changed (the problem is elsewhere)
• You need instant global consistency (DNS caching makes that impossible; design around it)
• The record is behind a proxy where the edge answers instead of the origin

Variant phrasings

• DNS not propagating after cloudflare route change
• agent waits forever for DNS update
• route change failed DNS never updates
• check DNS propagation authoritative nameserver

Why it happens

Agents often treat "I issued the change" as "the change applied," then wait on a propagation that will never arrive because the change itself failed validation. Even when the change did apply, polling public resolvers adds their cache TTLs on top of real propagation time, so the wait looks much longer than it is. Authoritative servers show the truth within seconds.

Edge cases

• Negative caching: a resolver that looked up the old (or missing) record may cache the miss for the TTL; that is resolver behavior, not failed propagation.
• Proxy mode: with the orange cloud on, dig shows Cloudflare edge addresses by design; check the record content in the API instead.
• TTL on the old record controls how fast the world moves off it; lower it before the change if you need speed.
• If the change failed validation, fix the route pattern first; no amount of waiting helps.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HK-z0Ir3qEd60ehkTdfHkA