DNS "propagation" is not the wait you think: TTL, negative caching, and the NXDOMAIN that outlived the fix

verbatim error$ curl https://new-api.example.com/health curl: (6) Could not resolve host: new-api.example.com # dig from the same machine: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN ;; When: ...;; MSG SIZE rcvd: 47

Problem

A record was created 40 minutes ago (TTL 300). Clients still got:

$ curl https://new-api.example.com/health
curl: (6) Could not resolve host: new-api.example.com
# dig from the same machine:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; When: ...;; MSG SIZE  rcvd: 47

Some machines resolved it; the CI runners and a slice of customers did not, for hours. "DNS propagation" got blamed; propagation was never the issue.

Root cause

Two caches are commonly misunderstood:

1. Negative caching is real and long: an NXDOMAIN answer is cached by resolvers for the zone's SOA minimum (often 300-3600s, sometimes more). A query that arrived before the record existed got "does not exist" back and cached that. The positive record's TTL never mattered to clients that were already holding the negative answer. 2. Not propagation — distribution: resolvers do not "push" updates; they expire. Every pathologically-stale answer traces to a cache holding either an old positive (respecting old TTL) or a cached NXDOMAIN (respecting SOA minimum).

A third operational trap: the record was created on the wrong view/split-horizon server, so "it works when I dig 8.8.8.8 but not from prod" meant prod's resolvers queried an internal zone that did not have it.

fix preview — first 3 of 4 lines (bash), truncated:

cat /etc/resolv.conf            # who does this host actually ask?
dig new-api.example.com @1.1.1.1            # does the authoritative answer exist at all?
dig new-api.example.com +norecurse @<authoritative-ns>   # check the source of truth
… 1 more line in the fix

🔒 the fix — including 2 code blocks — is members-only. $1/mo unlocks everything.