📄 the-night-i-broke-dns.md 6,902 bytes Apr 20, 2026 📋 Raw

title: "The Night I Broke DNS and My Wife Couldn't Reach Facebook"
slug: "the-night-i-broke-dns"
category: "homelab"
date: 2026-04-20
author: "Matt"
excerpt: "I moved DNS to Pi-hole on a Saturday night. By Sunday morning, half the house was offline and the dog's automatic feeder was on strike. Here's what went wrong and how I fixed it."
read_time: 8
tags: ["homelab", "dns", "pi-hole", "networking", "tailscale"]

The Night I Broke DNS and My Wife Couldn't Reach Facebook

I want to say it started with noble intentions — optimizing network latency, improving ad blocking efficiency, streamlining my DNS resolution path. But honestly? I was bored on a Saturday night and reading the Pi-hole documentation seemed like a good time.

It was not a good time.

The Setup

Like a lot of homelabbers, I'd been running my network on default settings for too long. Router-provided DNS pointed at my ISP's resolvers, which pointed at... who knows. The usual setup: it works until it doesn't, and you don't think about it until something breaks.

I had a Beelink mini PC sitting there — the one running OpenClaw, handling the smart home dashboard, doing its job reliably. It had capacity. And Pi-hole is lightweight. What could go wrong?

Famous last words.

What I Did

Saturday, 11 PM:

  1. Installed Pi-hole on the Beelink with Docker (because I wasn't about to give it a whole OS for DNS)
  2. Configured it to use Cloudflare and Quad9 as upstream resolvers
  3. Set the router's primary DNS to the Beelink's LAN IP
  4. Set the router's secondary DNS to... nothing. Just left it blank.

That last one was the mistake. But we'll get there.

I tested from my phone. Pages loaded. Ads disappeared. The dashboard in Pi-hole showed queries rolling in. I felt like a network engineer.

I went to bed.

What Happened

Sunday, 7:45 AM. Aundrea's voice from the living room:

"The internet isn't working."

Now, "the internet isn't working" in a household with a homelab guy is a diagnostic challenge. It could mean:

  • The ISP is down
  • The Wi-Fi is down
  • DNS is broken
  • One specific site is down
  • She's on the wrong Wi-Fi network
  • The container I started 8 hours ago has crashed

I shuffled out in my slippers, coffee in hand, and started diagnosing.

# From my laptop
$ nslookup facebook.com
;; connection timed out; no servers could be reached

$ nslookup google.com
;; connection timed out; no servers could be reached

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.2 ms

IP routing worked. DNS didn't. The Pi-hole container had crashed overnight — Docker restart policy was set to no because I hadn't configured it yet. And because I'd left the router's secondary DNS blank, every device on the network had exactly one DNS resolver, and that resolver was unconscious.

The Collateral Damage

Here's what I didn't account for when I made DNS a single point of failure:

  • Aundrea's phone — No Facebook, no Instagram. The thing she cares most about on a Sunday morning.
  • The kids' tablets — Sullivan's YouTube Kids playlist? Gone. Harper's PBS app? Infinite loading spinner.
  • Maggie's automatic feeder — Yes, our dog's Wi-Fi-connected feeder relies on DNS to reach the scheduling API. Breakfast was delayed 45 minutes. Maggie was not philosophical about it.
  • The smart thermostat — Also DNS-dependent. Wasn't a problem this time (schedule was cached), but noted for future panic.
  • My own dashboard — The HoffDesk dashboard pulls from three APIs. All three rely on DNS to reach their endpoints. Dashboard showed "DEGRADED" across the board. Accurate, but not helpful.

Total affected devices: 14. Total affected humans: 3 (4 if you count the dog, and she absolutely counted that morning).

The Fix

Three things, in order:

1. Immediate: Get DNS working again

docker restart pihole
# Verify it's up
docker logs pihole --tail 20

Took 30 seconds. Family back online. Peace restored.

2. Short-term: Redundancy

Added the router's secondary DNS back to Quad9 (9.9.9.9) directly. If Pi-hole goes down again, devices fall back to a working resolver. We lose ad blocking temporarily, but we keep the internet. Aundrea can reach Facebook. The dog gets breakfast on time. Everyone wins.

3. Long-term: Make it resilient

  • Docker restart policy: unless-stopped — because of course
  • Health check: Pi-hole's built-in Docker health check, plus a cron job on the Beelink that pings the Pi-hole web interface every 5 minutes and restarts the container if it's down
  • Tailscale integration: My devices on Tailscale use MagicDNS, which has its own resolution path. So Tailscale-connected devices had a second DNS path the whole time — I just hadn't verified that it was working for LAN resources
  • Monitoring: Added Pi-hole status to the HoffDesk dashboard health section (this was the original motivation for the health endpoint, actually)

What I'd Do Differently

Set the secondary DNS before changing the primary. This is Networking 101 and I skipped it because I was excited. Never change production DNS at 11 PM on a Saturday without a fallback. Actually, never change production DNS at 11 PM on a Saturday. Period.

Use Docker restart policies from day one. unless-stopped should be the default, not no. I was "going to configure it later." Later came at 7:45 AM in the form of an angry partner and a hungry dog.

Test failure modes, not just success modes. I verified Pi-hole worked. I never verified what happens when it doesn't. In production (yes, your home network is production), failure testing is more important than success testing.

Announce maintenance. Even in a household of four, a heads-up — "Hey, I'm changing DNS tonight, let me know if anything seems off tomorrow morning" — goes a long way. Especially when "anything" includes the dog's breakfast.

The Lesson

Home labs are production environments. Maybe the SLA is "don't break the Wi-Fi before coffee," but that's still an SLA. And the people affected by your infrastructure decisions aren't users in a ticketing system — they're your family, standing in the living room, asking why Facebook is down.

Treat your home network with the same respect you'd give a production system. Redundancy, monitoring, rollback plans. Because Pi-hole at 11 PM feels like a quick win, but Pi-hole at 7 AM feels like a crisis.

The dashboard health section now shows Pi-hole status with a green pill when it's up and a red one when it's not. I see it every morning. It's a small, constant reminder: your family's internet is your responsibility. Act like it.

This is the first post in our Home Lab Growing Pains series — real stories from running infrastructure at home. If you've got a war story, we'd love to hear it.

← Back