DNS Isn’t Broken—You Just Haven’t Slept Yet

Yesterday’s work bled into today, and for a while it felt like DNS itself had turned against me.

I had already migrated domains, databases, and email off Hostinger and onto my own infrastructure. Most of it was working. Sites were loading, email was flowing, and things were starting to feel stable.

Except for one subdomain.

It kept resolving to an old Bluehost IP, showing an “account suspended” page. At first glance, it looked like DNS propagation. That’s the usual suspect. Wait a few hours, maybe a day, and things usually settle.

But this time, it didn’t.

Following the Trail

I started checking things the way you do when something doesn’t make sense anymore:

dig festivalofleaves.dev.regaldragondanceparty.com A

;; ANSWER SECTION:
festivalofleaves.dev.regaldragondanceparty.com. 14400 IN A 66.235.200.147

Still pointing to a Bluehost IP.

So I bypassed local caching:

dig @8.8.8.8 festivalofleaves.dev.regaldragondanceparty.com
dig @ns1.codejamboree.com festivalofleaves.dev.regaldragondanceparty.com

Same result.

That ruled out propagation. The problem wasn’t “out there.” It was right here.

The Record That Wouldn’t Let Go

Inside the DNS zone, the record was still set to the old IP:

festivalofleaves.dev   A   66.235.200.147

It had survived the migration quietly, never overwritten.

Updating it to the correct server IP should have fixed everything.

But it didn’t.

I even restarted the DNS service, expecting the change to take effect immediately:

/scripts/restartsrv_named

All the obvious attempts to update the A record failed.

It still pointed to Bluehost.

The Real Clue: SOA

Then I noticed something I hadn’t paid much attention to before. I saw an SOA (Start of Authority) record that mentioned a Bluehost name server.

Mname: ns1.bluehost.com
Rname: root@box2035.bluehost.com

That was the clue.

Even though I had taken control of the nameservers, this one subdomain was effectively handing authority back to Bluehost through the way the zone had been carried over. Something hadn’t fully transitioned.

The change I made earlier hadn’t taken effect the way I expected. Not because DNS was broken, but because I wasn’t fully working in the right place yet.

Once I corrected the record in the active zone and brought the SOA in line with my own nameserver:

ns1.codejamboree.com. me.codejamboree.com.

…and bumped the serial, everything started behaving exactly as expected.

It wasn’t that DNS ignored the change.

It was that I hadn’t fully taken control of the zone yet.

It Wasn’t DNS. It Was Me.

This wasn’t propagation.

It wasn’t caching.

It wasn’t some mysterious internet delay.

It was a leftover configuration detail. One small piece was buried among many DNS entries that hadn’t been updated during the move.

The Part That Matters Most

What actually solved it wasn’t another command.

It was stepping away.

After a night’s sleep, returning with a clear head made the issue obvious within minutes. The same data was there the night before. I just wasn’t seeing it.

Final Thoughts

DNS has a reputation for being unpredictable, but more often than not, it’s doing exactly what it was told to do, even if you weren’t the one who told it.

The hard part is understanding what you inherited, especially after a long day of migrations, edits, and assumptions.

Sometimes the best troubleshooting step isn’t another command.

It’s sleep and a fresh cup of coffee.