DNS Negative Caching: Why Your Resolver Forgets Good News

DNS Cache Wars: When Your Resolver Lies to You

The borisovai-admin project was running smoothly until authentication stopped working—but only for certain people and only sometimes. That’s the kind of bug that makes your debugging instincts scream. The team had recently added DNS records for auth.borisovai.tech, pointing everything to 144.91.108.139. The registrar showed the records. Google DNS resolved them instantly. But AdGuard DNS—the resolver configured across their infrastructure—kept returning NXDOMAIN errors as if the domains didn’t exist at all.

The investigation started with a simple question: Which resolver is lying? I ran parallel DNS queries from my machine against both Google DNS (8.8.8.8) and AdGuard DNS (94.140.14.14). Google immediately returned the correct IP. AdGuard? Dead silence. Yet here’s the weird part: admin.borisovai.tech resolved perfectly on both resolvers. Same domain, same registrar, same server—but auth.* was invisible to AdGuard. That inconsistency was the clue.

The culprit was negative DNS caching, one of those infrastructure gotchas that catches everyone eventually. Here’s what happened: before the authentication records were added to the registrar, someone (or some automated system) had queried for auth.borisovai.tech. It didn’t exist, so AdGuard’s resolver cached that negative response—the “NXDOMAIN” answer—with a TTL of around 3600 seconds. Even after the DNS records went live upstream, AdGuard was still serving the stale cached result. The resolver was confidently telling clients “that domain doesn’t exist” because its cache said so, and caches are treated as trusted sources of truth.

The immediate fix was straightforward: flush the local DNS cache on affected machines using ipconfig /flushdns on Windows. But that only solves the symptom. The real lesson was about DNS architecture itself. Different public resolvers use different caching strategies. Google’s DNS aggressively refreshes and validates records. AdGuard takes a more conservative approach, trusting its cache longer. When you’re managing infrastructure across multiple networks and resolvers, these differences matter.

The temporary workaround was switching to Google DNS for testing while waiting for AdGuard’s negative cache to expire naturally—usually within the hour. For future deployments, the team learned to check new DNS records across multiple resolvers before declaring victory and to always account for the possibility that somewhere in your infrastructure, a resolver is still confidently serving yesterday’s answer.

It’s a reminder that DNS, despite being one of the internet’s most fundamental systems, remains surprisingly Byzantine. Trust, but verify. Especially across multiple resolvers.

Got a really good UDP joke to tell you, but I don’t know if you’ll get it 😄