DNS Cache Poisoning: Why AdGuard Refused to See New Records

DNS Cache Wars: When AdGuard DNS Holds Onto the Past

The borisovai-admin project was running smoothly until authentication stopped working in production. The team had recently added new DNS records for auth.borisovai.tech and auth.borisovai.ru, pointing to the server at 144.91.108.139. Everything looked correct on paper—the registrars showed the records, Google’s public DNS resolved them instantly. But AdGuard DNS, the resolver configured in their infrastructure, kept returning NXDOMAIN errors as if the records didn’t exist.

The detective work started with a DNS audit. I ran queries against multiple resolvers to understand what was happening. Google DNS (8.8.8.8) immediately returned the correct IP address for both authentication domains. AdGuard DNS (94.140.14.14), however, flat-out refused to resolve them. Meanwhile, the admin.borisovai.tech domain resolved fine on both services. The pattern was clear: something was wrong, but only for the authentication subdomains and only through one resolver.

The culprit was DNS cache poisoning—not malicious, but equally frustrating. AdGuard DNS was holding onto old NXDOMAIN responses from before the records were created. When the DNS entries were first added to the registrar, AdGuard’s cache had already cached a negative response saying “these domains don’t exist.” Even though the records now existed upstream, AdGuard was serving stale cached data, trusting its own memory more than reality.

This is a common scenario in distributed DNS systems. When a domain doesn’t exist, DNS servers cache that negative result with a TTL (Time To Live), often defaulting to an hour or more. If new records are added during that window, clients querying that caching resolver won’t see them until the cached NXDOMAIN expires.

The immediate fix was simple: flush the local DNS cache with ipconfig /flushdns on Windows clients to clear stale entries. For a more permanent solution, we needed to either wait for AdGuard’s cache to naturally expire (usually within an hour) or temporarily switch to Google DNS by manually setting 8.8.8.8 in network settings. The team chose to switch DNS servers while propagation completed—a pragmatic decision that got authentication working immediately without waiting.

What seemed like a mysterious resolution failure turned out to be a textbook case of DNS cache semantics. The lesson: when DNS behaves unexpectedly, check multiple resolvers. Different caching strategies and update schedules mean that not all DNS services see the internet identically, especially during transitions.

😄 The generation of random DNS responses is too important to be left to chance.