DNS Resolution Chaos: Why Some Subdomains Vanish While Others Thrive

DNS Mysteries: When One Subdomain Works and Others Vanish

The borisovai-admin project was running smoothly on the main branch, but there was a catch—a frustrating one. admin.borisovai.tech was responding perfectly, resolving to 144.91.108.139 without a hitch. But auth.borisovai.tech and auth.borisovai.ru? They had simply disappeared from the internet.

The task seemed straightforward: figure out why the authentication subdomains weren’t resolving while the admin panel was working fine. This kind of infrastructure puzzle can turn into a time sink fast, so I needed a systematic approach.

First, I checked the DNS records directly. I queried the DNS API expecting to find auth.* entries sitting quietly in the database. Instead, I found an empty records array—nothing. No automatic creation of these subdomains meant something in the provisioning logic had fallen through the cracks. The natural question followed: if auth.* records aren’t in the API, how is admin.borisovai.tech even working?

The investigation took an unexpected turn. I pulled out Google DNS (8.8.8.8) as my truth source and ran a resolution check. Suddenly, auth.borisovai.tech resolved successfully to the same IP address: 144.91.108.139. So the records existed somewhere, but not where I was looking. This suggested the DNS configuration was either managed directly at the registrar level or there was a secondary resolution path I hadn’t accounted for.

Then came the real discovery. When I tested against AdGuard DNS (94.140.14.14)—the system my local environment was using—the auth.* records simply didn’t exist. This wasn’t a global DNS failure; it was a caching or visibility issue specific to certain DNS resolvers. The AdGuard resolver wasn’t seeing records that Google’s public DNS could find immediately.

I ran the same check on auth.borisovai.ru and confirmed the pattern held. Both subdomains were missing from the local DNS perspective but present when querying through public resolvers. This pointed to either a DNS propagation delay, a misconfiguration in the AdGuard setup, or records that were registered at the registrar but not properly distributed to all nameservers.

Here’s an interesting fact about DNS that caught me this time: DNS resolution isn’t instantaneous across all servers. Different DNS resolvers maintain separate caches and query different authoritative nameservers. When you change DNS records, large providers like Google cache globally, but smaller or regional DNS services might take hours to sync. AdGuard, while excellent for ad-blocking, might not have the same authoritative nameserver agreements as Google’s public DNS, creating visibility gaps.

The fix required checking the registrar configuration and ensuring that auth.* records were properly propagated through all authoritative nameservers, not just cached by some resolvers. It’s a reminder that DNS is often the last place developers look when something breaks—but it should probably be the first.

---

😄 Why did the DNS administrator break up with their partner? They couldn’t handle all the unresolved entries in their relationship.