Wi-Fi & Network

Pi-hole down took out home internet

When Pi-hole is the only DNS you hand out and it dies, the whole house loses name resolution. Restore service fast, then build real redundancy.

Problem summary

If DHCP hands out only the Pi-hole as DNS and it goes down — reboot, failed update, stopped container, dead SD card — name resolution fails network-wide even though the internet link is fine. First confirm it's DNS, restore service with a temporary public resolver, then fix Pi-hole and add real failover.

Operator snapshotEvidence first

First proof

Reach something by IP (ping 1.1.1.1) and then try to resolve a name.

Screen to open

ping 1.1.1.1 then nslookup google.com

Expected signal

The IP is reachable but names fail — confirming the link is fine and DNS is the problem.

Stop boundary

Don't 'fix' it by adding 8.8.8.8 as a DHCP secondary — that leaks filtering and doesn't fail over.

Layer path

1When the only DNS server handed out by DHCP is Pi-hole and it goes down, name resolution fails for the whole network even though the internet link is fine — 'internet by IP works, nothing resolves'.

2The single point of failure is the design, not a bug: one resolver with no real failover. The fix has two halves — restore service now, then add genuine redundancy.

3A second DHCP-handed DNS (like 8.8.8.8) is NOT failover: most OSes treat the two as interchangeable and query each at random, so filtering leaks and cutover isn't clean.

4On a Raspberry Pi, SD-card wear (from constant logging/DB writes plus under-volting) is the classic cause of the outage.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Confirm it's DNS, not the link

Check: Reach an IP directly, then try a name; query Pi-hole with dig.

Expected result: IP works, names don't, dig against Pi-hole times out.

If not: If the IP is unreachable too, fix connectivity first — it isn't a Pi-hole problem.

Restore service with a temporary public resolver

Check: Point the router's DHCP DNS (or the affected client) at 1.1.1.1/8.8.8.8 and renew the lease.

Expected result: The household can resolve names again.

If not: Note this disables filtering — set a reminder to revert.

Diagnose why Pi-hole went down

Check: Check FTL status/logs; on a Pi, check for read-only filesystem / boot errors.

Expected result: You've identified a failed update, stopped container, OOM, or SD-card wear.

If not: If config is corrupt, restore a Teleporter backup rather than rebuilding blind.

Repair and revert to Pi-hole

Check: Fix the cause (restart/repair FTL, reimage to durable storage), confirm dig works, then set DHCP DNS back to Pi-hole.

Expected result: Pi-hole resolves and filters again, and clients use it.

If not: Verify a client's queries appear in the log before walking away.

Add real redundancy

Check: Stand up a second Pi-hole/AdGuard Home on independent hardware; for true failover use a keepalived/VRRP pair on a shared virtual IP with a dig health check; sync with nebula-sync or v6 Teleporter.

Expected result: A single resolver outage no longer takes down the house, and failover is clean.

If not: Do not rely on a DHCP-listed public secondary — it leaks filtering and doesn't fail over.

Harden the host

Check: On a Pi, move to a high-endurance card or SSD/USB boot, use a quality power supply, and trim FTL logging/DB writes.

Expected result: The recurring SD-card failure mode is removed.

If not: If outages persist, run the resolver on a more reliable box (mini-PC/NAS container).

Decision tree

If: IP reachable, names fail, dig against Pi-hole times out.

Then: Pi-hole is down and it's the only resolver.

Action: Temporarily set the router/client DNS to a public resolver to restore service, then fix Pi-hole and revert.

If: FTL won't stay running.

Then: Service/config failure (failed update, stopped container, OOM).

Action: Restart FTL, read its log, and fix the reported cause; restore a Teleporter backup if config is corrupt.

If: Raspberry Pi won't boot / filesystem read-only.

Then: SD-card wear or power problem.

Action: Reimage to a high-endurance card or SSD/USB boot; use a quality PSU; trim FTL logging.

If: It resolves again after a reboot but you want it to never take down the house.

Then: You need real redundancy, not a DHCP secondary.

Action: Stand up a second Pi-hole/AdGuard on independent hardware; ideally a keepalived/VRRP pair on a shared virtual IP with a dig health check.

Safe stop: Don't 'fix' it by adding 8.8.8.8 as a DHCP secondary — that leaks filtering and doesn't fail over.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Whole house 'no internet' but link lights are fine.	ping 1.1.1.1 succeeds; name resolution fails.	DNS (Pi-hole) down	Restore with a temporary public resolver, then fix Pi-hole.
Pi-hole web UI and dig both unresponsive.	FTL service status / container state.	FTL stopped/crashed	Restart FTL; read the log; restore Teleporter if config is bad.
Recurring outages on a Raspberry Pi.	Filesystem read-only / boot errors / dmesg.	SD-card wear / power	Reimage to endurance card or SSD/USB; quality PSU; reduce logging.
Filtering 'sometimes' works, sometimes not.	DHCP DNS options (is a public IP listed as secondary?).	Secondary-DNS leak	Remove the public secondary; deploy a real second resolver.

Reference

Commands and settings paths

Is it DNS or the link?

ping 1.1.1.1 then nslookup google.com

Where: On any affected client.

Expected: The IP pings but the name fails to resolve — it's DNS.

Failure means: If the IP also fails, it's connectivity, not Pi-hole.

Safe next step: Fix the link first if the IP is unreachable; otherwise restore DNS.

Is Pi-hole answering at all?

dig @<pi-hole-ip> google.com (or nslookup google.com <pi-hole-ip>)

Where: From a client on the LAN.

Expected: Pi-hole returns an answer.

Failure means: Timeout/refused confirms Pi-hole/FTL is down or unreachable.

Safe next step: Set a temporary public resolver to restore service, then repair Pi-hole.

Restore service immediately (temporary)

Router DHCP DNS (or one client) → 1.1.1.1 / 8.8.8.8, then renew lease

Where: On the router DHCP settings or a single client.

Expected: Clients resolve again via the public resolver.

Failure means: This disables filtering — it's a stopgap, not a fix.

Safe next step: Revert to Pi-hole once it's healthy so you're not silently unfiltered.

Check FTL / host health

sudo systemctl status pihole-FTL (or docker logs <pihole>) ; dmesg | tail

Where: On the Pi-hole host/container.

Expected: FTL is running and the filesystem shows no read-only/corruption errors.

Failure means: A dead FTL or read-only SD card explains the outage.

Safe next step: Restart FTL or reimage to durable storage; restore Teleporter if needed.

Hardware boundary

Hardware and platform boundary

Change only when

Add a second resolver the moment DNS filtering becomes load-bearing for the household — ideally an HA pair (keepalived/VRRP + virtual IP) on independent hardware.

Evidence that matters

Independent hardware for the second resolver, durable storage (SSD/USB over SD), a health-checked virtual IP, and a v6-compatible sync tool (nebula-sync / Teleporter).

Evidence that does not matter

A bigger blocklist or a faster Pi — neither addresses the single-point-of-failure that caused the outage.

Avoid

Adding a public DNS as a DHCP 'secondary' for failover (it leaks filtering and doesn't fail over), or following archived gravity-sync/orbital-sync guides under v6.

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

Device setup troubleshooter

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 research verified against Pi-hole docs/Discourse (the secondary-DNS-isn't-failover guidance and the host-loses-DNS caveat) and current redundancy practice; flags that gravity-sync/orbital-sync are archived and nebula-sync / v6 Teleporter are the current sync path, and that real failover needs keepalived/VRRP, not a DHCP secondary.

Sources/assumptions

Assumes Pi-hole (or AdGuard Home) is the DNS server handed out by DHCP and is currently the only resolver clients use.
Assumes the internet link itself is up — the failure is name resolution, not connectivity.
A single DNS server is a single point of failure; verify current Pi-hole redundancy guidance against the docs (the old gravity-sync/orbital-sync tools are archived).

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Apple Support: Wi-Fi and internet troubleshooting on MacUsed for safe first checks around Wi-Fi status, diagnostics, VPN/security software, and external network devices.Microsoft Support: Fix network connection issues in WindowsUsed for Windows network baseline checks before changing router-wide settings.Pi-hole documentationUsed as the first-party reference for Pi-hole install, configuration, and the v6 documentation set.Pi-hole: Core releases (GitHub)Used to date-stamp the current Pi-hole Core/FTL/Web versions rather than asserting a frozen version number.nebula-sync (Pi-hole v6 config sync)Used as the current Pi-hole v6 sync tool (via the v6 Teleporter API) — replaces the archived gravity-sync/orbital-sync.FCC: Home network tipsUsed for router placement, congestion, and baseline home-network troubleshooting guidance.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

How do I know it's Pi-hole and not my internet?

Reach something by IP first: if `ping 1.1.1.1` works but names don't resolve, the link is fine and it's DNS. Then query Pi-hole directly — `dig @<pi-hole-ip> google.com` (or `nslookup google.com <pi-hole-ip>`). A timeout/refused means Pi-hole is down; an answer means the problem is elsewhere (DHCP handing the wrong server, or a stale client cache).

Should I just add 8.8.8.8 as a second DNS so this never happens again?

No — that's the trap. Most operating systems treat two handed-out DNS servers as interchangeable alternatives, not primary-then-fallback, so clients query each at random over time. The practical result is your filtering leaks intermittently AND it still doesn't fail over cleanly. Real redundancy is a second Pi-hole/AdGuard Home, ideally a keepalived/VRRP pair sharing one virtual IP with a health check, or router-level health-checked DNS failover.

It's a Raspberry Pi — why does this keep happening?

SD-card wear is the classic cause: Pi-hole's logging and long-term query database write constantly, and cheap cards (plus under-volting from a weak power supply) lead to corruption, read-only filesystems, and boot failures. Use a high-endurance card or boot from SSD/USB, use a quality power supply, and consider trimming FTL's logging. Run a second resolver on independent hardware so one card can't take down the house.

How do I sync two Pi-holes in 2026?

Use nebula-sync (or Pi-hole v6's built-in Teleporter import/export) — it supports v6 via the Teleporter API. Do not follow older guides that recommend gravity-sync or orbital-sync: both are archived/abandoned and gravity-sync is incompatible with Pi-hole v6.