I had a DNS bug that was only showing up about 1 in every 4 times someone visited the client’s website afresh. What was the bug, how did I deal with it, and why did "we already checked DNS" almost send us down the wrong path?
The Background
The client’s story is one every WordPress developer will recognize. The client had a hosting account with a company and had registered a domain name with them. They had also built a website using an AI builder on this hosting account and pointed the domain name to it.
After not seeing a great ROI with their website, they contracted me to build a new one, and the first order of business was to point their DNS to the new hosting account they would now be using to host this new website. Easy and routine stuff.
The Bug
However, the client kept messaging me that they were seeing a banner from their old host stating the website was unavailable. That should not have been happening because the domain name was no longer pointed to this old host.
And the most infuriating thing is that they were seeing the banner and I wasn't, and the banner was showing up intermittently. They would refresh the site, there it was. Refresh again, and it was gone.
"We already checked DNS" Almost Sent Us Down The Wrong Path
My first theory was that they had made a classic DNS mistake and that their A record was still pointing at the old host. So, we checked it, fixed it, rechecked it, and made sure it was correct.
The banner still showed up intermittently, as if mocking me. I was starting to get mad because I had to continue building this website.
My second theory was DNS propagation lag. I reasoned that some resolvers around the world just hadn't caught up yet. I have seen this happen, and I usually wait 24-72 hours for things to sort themselves out.
When I saw that the banner was not showing up, I went back to work. But the client was still seeing the banner and hadn't flagged it again. They assumed I was working on it while I assumed the issue was fixed.
Digging In
After a week and a half, they reached out. The banner was still showing up.
This ruled out propagation entirely because DNS propagation doesn't take this long unless something is actually wrong.
Because the client had changed the settings on their end, there was no need to go that route again. So, I decided to query the domain's authoritative registry directly instead of checking DNS through a regular resolver.
I did this because I know a regular resolver can cache stale answers and that the authoritative registry is the actual source of truth and is not affected by caching or lag.
The command I ran was:
dig NS <example.org> @a0.org.afilias-nst.info
Note: That registry server only answers for .org domains, so you should swap in the registry server that matches your own domain's TLD if you want to do a check like this.
What I found
And there it was:
ns3.nameserver.com.
ns-246.awsdns-30.com. ← there it is
ns2.nameserver.com.
ns4.nameserver.com.
Three of the four nameservers had been correctly updated to the new host.
The fourth was still the old provider's AWS nameserver, and ns1 of the new host was missing entirely. It was never added, and the AWS nameserver had taken its place.
After looking into this a bit more, I learned that DNS resolvers don't always ask the same nameserver in a set but instead rotate between the ones listed.
So roughly 1 in every 4 lookups worldwide was landing on the leftover AWS nameserver, which was still serving the old zone. Additionally, all requests routed through a DNS server with the new nameserver resolved cleanly.
This was the root of the "sometimes it shows, sometimes it doesn't" issue we were seeing.
It was never a DNS propagation issue but an incomplete nameserver swap sitting at the registrar level the entire time.
This was a partially done migration that looked, from every regular check, like it had already been finished.
How I Dealt With This DNS Issue
The fix was replacing the leftover AWS nameserver with the missing ns1.nameserver.com at the registrar. Once all four nameservers agreed, every resolver got the same answer every time from then on.
Conclusion
The first takeaway from dealing with this is that when something is "intermittent" in DNS, the ratio of how often it fails can be a clue, not noise. The second is that developers and webmasters should always check the registry directly and not a caching resolver when a fix "should have worked" but hasn't.
If you're mid-migration and something is behaving inconsistently, this is worth ruling out first. Drop a comment or message me if you want a hand digging into it or if you are looking for a developer with excellent troubleshooting skills, a keen eye for such issues, and a genuine love for challenges like these.
Top comments (0)