Episode V: Bluehost Stikes Back

My inbox for drew@drewsk.tech was quiet for a few weeks and I didn’t think much of it. I was planning on sitting down to clean up old articles and publish a new one when I noticed that the blog site was down. Technically, the site was still up, but DNS wasn’t pointing to it. It turns out - all of my DNS entries were gone.

A sudden and unexpected failure to find the website

What Happened?

There’s an amount of incredulity that I felt when I was looking at the DNS Manager page in the Bluehost settings for the domain and it was completely blank. A records, CNAME records, and MX records were all gone. For a moment I thought perhaps I had been a victim of malicious activity, but unfortunately after beginning a chat with Bluehost support it became clear that this is by design.

Timeline

On December 29, 2022, my Wordpress hosting account with Bluehost was set to expire as I had migrated to a static website hosted elsewhere. My domain, also with Bluehost, was renewed through 2025 and the DNS records were all updated to point to the new site (in addition to email and a few other properties). I received an email that warned me that my data would be removed ("all data associated with the account will be permanently removed from our servers"), which was not cause for alarm as I had already duplicated my usual backup of the Wordpress site in addition to the site migration.

At the end of January, my email account went unusually quiet but I also had an extended vacation out of the country. Unknown to me, at this time Bluehost had removed the DNS records for the domain in addition to any of the hosted data.

As February began to unfold, a quick glance at the weekly site analytics email showed a red flag - almost no site traffic. Realistically, this site isn’t very busy, but there’s a handful of articles that have regular traffic.

This weekend (February 20th), I took a closer look at the analytics report and manually checked the website, getting a DNS probe error. After the actual endpoint (Azure Static Web Apps) had no problem loading, I went into the Bluehost domain management portal. It’s at this point that I see every single DNS entry is gone and reach out to Bluehost support via chat.

Intentionally Deleting DNS Records

Bluehost support conveyed that deleting all the DNS records when hosting for a website expires is standard procedure, regardless of whether the domain is renewed or the records point to external entities.

I tried to explain to Bluehost chat why this wasn't ok

Frankly, I struggle to imagine what review process this policy made it through, because deleting DNS records has the potential for serious implications (email delivery, etc.) beyond removing the hosted website as DNS records are infrastructure, not web content. I’d encourage Bluehost to revise this process and discontinue removing customer infrastructure tied to the domain name, not website hosting.

but I was about to lose my temper

At the end of the chat I wasn’t able to gain any level of trust back with Bluehost for DNS records. At the very least, this is a warning to you about using Bluehost for domain management. Continue to read on for more about the mistakes that I had made in this process and changes I’m making.

Amateur Infrastructure

As egregious as Bluehost deleting a swath of customer DNS entries for an owned domain is, I made a critical error in my site migration and an editorial choice that I regret. For me, this is essentially hobby technology that overlaps into past, present, and future work. I’m not concerned about financial loss from website down time like a usual business, but a gap in email delivery is something I’ve got heartburn over.

Critical Error: Site Monitoring

Even though I’m not concerned that the website stays up 24x7, I do need to keep an eye on it as the canary for a number of pieces of my infrastructure link. The quickest method for doing a periodic (once a day) check is a GitHub workflow that leverages an action based on curl, Jtalk/url-health-check-action :

# every day at 1:00am
on:
  schedule:
    - cron: '0 1 * * *'

jobs:
  drewsktech:
    runs-on: ubuntu-latest
    name: Test DrewskTech website
    steps:
      - name: Check the deployed service URL
        uses: jtalk/url-health-check-action@v3
        with:
          # Check the following URLs
          url: https://www.drewsk.tech|https://drewsk.tech
          max-attempts: 3
          retry-delay: 5s

This isn’t an active monitoring solution, but it is a regular alerting solution that will drop me an email overnight if a piece out of the website stack goes offline again. I had website monitoring configured on the previous Wordpress-based site, but hadn’t setup it again on the self-hosted site.

Editorial Choice: DNS Hosting

When you own a domain name, it often uses the default the DNS name servers from the domain reseller and this is generally good enough for public DNS records to point at an email server, a web server, and more. The key component of this relationship with the provided name servers is the trust in the domain reseller.

Without trust in my domain reseller at this point, it’s time to revise a choice I made during the website migration and switch to a 3rd party DNS. Admittedly, this is the first time I’m venturing into managing public DNS records outside of a domain reseller so it’s a new adventure. I’d like to treat the DNS records for the domain more properly like infrastructure where I have more control on its configuration and the ability to backup the records.