2026-10-18

A fresh DNS record existed, but my Mac still said the domain did not

I checked a domain too early. The record went live, but my Mac kept the earlier negative answer.

During a launch I tried the new domain before its DNS record existed. That first lookup returned NXDOMAIN. After I added the record, a public resolver could see it, but plain curl and the browser on my Mac still reported that the name could not be resolved. I was debugging a working deploy through a stale local answer.

The negative answer had its own lifetime

macOS kept the NXDOMAIN response in mDNSResponder. In this incident the zone's SOA minimum TTL was 1800 seconds, so that negative answer could hang around for roughly 30 minutes. Creating the record did not invalidate the earlier answer already cached on my machine. The difference between local curl and a public resolver was the clue.

I tried dscacheutil -flushcache without sudo. It did not reliably clear this mDNSResponder entry. A privileged HUP of mDNSResponder would flush it, but I did not have sudo on that Mac. Waiting for expiry was possible; it was a poor way to verify a live site.

Test DNS and the server separately

First ask a public resolver whether the new record exists. Then pin the expected server IP for an HTTPS request. Replace the example domain and IP with your own. curl --resolve keeps the requested hostname for HTTP and TLS while bypassing the local DNS lookup for that host.

dig @8.8.8.8 fresh.example A
curl --resolve fresh.example:443:<server-ip> \
  https://fresh.example/

For a browser check, launch Chrome or Playwright with a host resolver rule that maps the same name to that IP. That tests the page through the real browser against the intended server while the Mac cache is still wrong.

--host-resolver-rules="MAP fresh.example <server-ip>"

On the next fresh domain, I used a public resolver for the preflight check. That avoids feeding an early NXDOMAIN into the Mac resolver before there is a record to find.

Topics

• Deploys

Still stuck? Send it to Emsden Studio and get a straight answer on what it is and what fixing it costs.

More notes

• Put a feature branch on an existing Coolify URL, then put it back
• Check the offsite copy of a Coolify compose database backup
• Two Umami first-boot checks I nearly missed on Coolify
• Choosing a VPS in Australia for self-hosting
• Point your app at a Coolify Postgres by container name, not IP
• A launchd job that dies with no code change
• Coolify quietly bakes your build secrets into the image layers
• A full VPS disk on Coolify: 1905 MB per rebuild, down to 31 MB
• The Next.js standalone healthcheck trap on Coolify
• serve -s makes every URL on a multi-page site come back 200

All notes