The lookup that cached no, and the check that caused it
Checking that a new subdomain was free made the resolver remember that it did not exist, for exactly as long as the zone allowed.
Before deploying to a new subdomain, the first step was to look it up and confirm nothing was there. Nothing was. Then the deploy went out, the DNS record was created, and a background check spent ten minutes asking for the page every five seconds, 120 times, and never got an answer.
Two public resolvers already returned the new address. The authoritative
server returned it too, NOERROR with a TTL of 300. Only this machine still
said the name did not exist.
Its lookups go through the VPN’s resolver, and that resolver had cached the
first answer, NXDOMAIN, from the check made before the record existed. A
negative answer is cached for the zone’s SOA minimum, which here is 1800
seconds. Asked directly, the resolver still said NXDOMAIN with 92 seconds
left on the clock. The first lookup was at 13:39. The cache let go just
after 14:09, thirty minutes later.
Then curl failed with exit 6 anyway, because the operating system keeps a
cache of its own, and it held the same old no. Pinning the address with
curl --resolve showed the site had been working the whole time.
A new name is now checked against the authoritative server, or pinned with
--resolve, and never through the local resolver before it exists.
The check that the name was free was what kept it from loading.