Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

DNS negative caching: avoid creating a name after clients already asked for it

Last updated: 1 Oct 20266 min read
tutorial
AdvancedBy AITrove Editorial

DNS resolvers can cache negative answers such as a name not existing. If clients query a hostname before its record is created, some resolvers may keep returning the cached negative answer until its negative cache lifetime expires. Lowering the positive record's TTL later does not clear that previous absence. A record visible from an authoritative server can therefore remain invisible to clients using a recursive resolver.

Operational decision

A settlement service will start calling a new payout endpoint. Publish the record before deploying clients that reference it, then query the authoritative name servers and multiple recursive resolvers from relevant networks. The shell sample checks an illustrative test name and its zone metadata; substitute the approved domain before use. Record whether a failed lookup occurred before creation and inspect the zone's negative-cache settings and observed resolver response. If a resolver still returns the prior negative answer, keep the old route or gate the client rollout until it expires. Test the actual TLS and application path after resolution, because an A record alone does not prove service health. Do not repeatedly create and remove the same hostname during a cutover test; the removal can seed more negative caches. Keep a rollback name available that was published ahead of time.

bash
dig payout-new.aitrove.test A
dig payout-new.aitrove.test A @1.1.1.1
dig aitrove.test SOA

Cost and verification

Publishing names ahead of demand uses little runtime capacity but requires coordination with certificate issuance and route preparation. Waiting for negative caches slows a cutover, while switching clients early creates connection errors despite a correct authoritative zone. Resolver implementations can cap cache lifetimes, so measure from the networks that matter rather than assuming one global expiry. Alert on client lookup failures and successful external transactions, not only authoritative record state.

Common Mistakes

  • Do not assume a new positive TTL clears cached NXDOMAIN answers.
  • Do not deploy clients before the name and route are ready.
  • Do not call one authoritative lookup proof of client resolution.

Connected lessons

Practice and check

devops
operations
Storage details