Back to DevLog

DNS Gremlins and SSL Silent Failures: Getting MajesticMirrorBooth Live

3 min read

What a day of debugging DNS mysteries and SSL silent failures! Today I finally got majesticmirrorbooth.com live after wrestling with some classic hosting gotchas.

The Vercel Authentication Dance

Started the day with a blocked Vercel alias step. Turns out my CLI wasn't properly authenticated in the shell session. The fix was simple once I figured it out:

VERCEL_TOKEN + --scope andrew-cruzs-projects

With that sorted, app.gethoneybun.com is now live and returning HTTP 200. The DNS Setup UI shipped successfully too.

The GoDaddy Parked Record Culprit

Here's where things got interesting. I was trying to get majesticmirrorbooth.com live with SSL, but kept hitting silent failures. The SSL would just... not work. No errors, no warnings, just nothing.

After some detective work, I found the root cause: GoDaddy automatically adds a parked A record that creates DNS round-robin to the wrong IPs. This causes Let's Encrypt challenges to fail silently, which is incredibly frustrating to debug.

The solution was a multi-step dance:

  1. Delete the parked A record
  2. Issue apex-only SSL first
  3. Confirm the certificate with openssl s_client
  4. Re-issue with www SAN

Boom! Both apex and www now have proper SSL coverage.

New Guardrails Added

I've learned this lesson the hard way enough times that I added it as §11 in my CLAUDE.md guardrails:

Always check for GoDaddy parked A records before SSL setup - they're the standard culprit for silent SSL failures on new domain cutover.

I also added a §14 section tracking live operator sites, because keeping tabs on what's actually deployed is crucial for debugging.

The Cloudways API Lie

One particularly annoying discovery: the Cloudways API returns "ok" even when SSL installs fail silently. There's no operation_id path to track, so you think everything worked when it didn't. Classic case of optimistic API design gone wrong.

What's Next

With majesticmirrorbooth.com now live, I need to:

  • Run the pre-deploy check script
  • Do an SEO diagnostic
  • Verify the heartbeat mu-plugin and render worker are working properly

The GoDaddy OAuth reseller program is on my backlog (task id: 239e87c7), but I'm deferring that until we hit 20+ operators per month.

Key Takeaways

Sometimes the simplest problems - like a parked DNS record - can cause the most mysterious failures. Having good documentation and guardrails saves future-me from repeating these debugging sessions.

Also, never trust an API that says "ok" without giving you a way to verify the operation actually worked!

Share this post