How Do You Make DNS Keep Working When the Internet Is Down?
Tech GuruKeep local DNS local. Your router, Pi-hole, AdGuard Home, Technitium, or internal resolver should answer local names without forwarding to the internet, and clients should have at least two reachable resolvers that behave consistently.
Design principle: Make the network boring on purpose: clear ownership, few trust zones, documented DNS, and access paths that fail closed.
The Short Version
- Keep local DNS local. Your router, Pi-hole, AdGuard Home, Technitium, or internal resolver should answer local names without forwarding to the internet, and clients should have at least two reachable resolvers that behave consistently.
- Use the decision matrix below, then prove the result with the validation checklist before making it the default.
Why This Matters Now
Begin by listing the local names and services that must survive a WAN outage, the VLANs and VPN clients that query them, and how quickly the household needs DNS restored. That inventory determines the resolver topology.
Many homelabs fail strangely during WAN outages because local names depend on public DNS, external proxy records, or cloud identity.
DNS should be treated as infrastructure with redundancy, monitoring, and a failure mode.
The goal is not just ad blocking; it is predictable name resolution for local services.
The sections below build a local home.arpa path, two consistent resolvers, and DHCP distribution, then use WAN-disconnect, second-resolver, cold-query, and configuration-restore checks to separate local DNS resilience from cloud-dependent application behavior.
Recommended Baseline
Let the router remain the DHCP authority, but have it advertise two internal resolver addresses that return the same local records. Pi-hole, AdGuard Home, or Technitium should answer those records locally instead of forwarding them to a public upstream.
Keep the local zone on resolver services that do not share one avoidable host dependency, synchronize or reproducibly define their records, and send both addresses through DHCP. Preserve resolver exports, router settings, direct IP administration, and a documented emergency bypass.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| Router DNS only | Small simple networks. | Weak logging and policy. |
| Pi-hole/AdGuard | Filtering plus local records. | Needs HA plan if critical. |
| Technitium/Unbound | More DNS control. | More complexity. |
| Active Directory DNS | Windows domain environments. | Heavy for normal homes. |
Decision Worksheet
Use the worksheet to enumerate local hostnames, current DHCP-provided resolver addresses, static clients, each VLAN and VPN path, browser Secure DNS behavior, and any application that still requires cloud identity even after its local name resolves.
| Worksheet Item | What To Write Down | Why It Matters |
|---|---|---|
| Primary question | How do I make DNS keep working when the internet is down? | This keeps the article tied to the reader's real decision instead of drifting into a generic product comparison. |
| Affected systems | The devices and services that lose internet, DNS, Wi-Fi, remote access, or admin reachability if this fails. | Readers should know who and what they are protecting before they choose hardware, software, or a cloud service. |
| Failure model | WAN outage, bad DNS, blocked discovery, stale firewall rules, expired certificates, and lost admin access. | Different failures need different controls. This row prevents RAID, sync, VPN, or MFA from being treated as magic. |
| Proof test | Test from a wired client, Wi-Fi client, phone on cellular, and any VLAN or tunnel that depends on the change. | A recommendation is not proven until it survives a small, repeatable test using realistic data, clients, or accounts. |
| Rollback path | Export config first and identify the old port, SSID, DNS server, or tunnel setting that restores service. | A reversible change is less stressful, easier to explain, and less likely to turn a weekend project into an outage. |
| Measurement to capture | Latency and throughput from the rooms or VLANs that matter, not just beside the router. | Numbers, logs, screenshots, or restore notes give the reader confidence that the decision was based on evidence. |
Run A WAN-Disconnect Drill
Unplug the WAN and watch what still works. Local names under home.arpa should resolve if your local resolver is healthy. Cached public names may work briefly. New public lookups should fail cleanly. DHCP leases should renew. NTP may drift if there is no local source. Apps that hard-depend on cloud identity may fail even when local DNS is fine.
Keep DNS HA simple. Two resolvers help only if clients know both, both have the same local records, and the router does not hand out a dead upstream path. Document the emergency bypass before an outage.
Real-World Example
Consider a home where nas.home.arpa, homeassistant.home.arpa, and media.home.arpa are present on both internal resolvers. During a WAN outage those local answers should remain available, while new public lookups may fail and cloud-authenticated features may still stop.
Trace one fresh local query from a client to its DHCP-advertised resolver, into the local zone, and back without an upstream lookup. Repeat against the second resolver and from every VLAN or VPN that needs the name; record public failures separately.
A successful local lookup proves only DNS. Home Assistant integrations, media authentication, certificate checks, or mobile apps may still require the internet. Label those cloud dependencies explicitly so a WAN drill does not misdiagnose expected application failure as resolver failure.
Rollout And Recovery Plan
Export DHCP and resolver configuration, populate identical local records on both resolver paths, and test one client with explicit DNS addresses before changing a DHCP scope. Expand to additional VLANs only after each resolver answers local names independently.
Rollback should restore the previous DHCP resolver options and known-good local-zone export, with direct IP access retained for the router and resolver consoles. Document how to renew a client lease and which temporary address can resolve public names during repair.
Implementation Details
Schedule the DHCP change when local services can be queried from representative wired, Wi-Fi, VLAN, and VPN clients. Keep direct IP bookmarks and console access available, and do not combine the DNS cutover with router firmware, subnet, or reverse-proxy changes.
- Choose a local domain that does not collide with public domains you do not own.
- Put important local records in the resolver clients actually use.
- Use DHCP options to hand out resolver IPs consistently.
- Avoid giving clients an ISP resolver as secondary if it breaks local names.
- Document how to bypass the filtering resolver during an outage.
Record these details while you build, not after the memory has already gone fuzzy:
- Latency and throughput from the rooms or VLANs that matter, not just beside the router.
- DNS behavior when the WAN is unplugged, VPN is connected, and browser secure DNS is enabled.
- Firewall logs for denied traffic between guest, IoT, management, and trusted networks.
- Open ports and externally reachable hostnames after the change.
Evidence To Collect
Capture reader-run results such as dig nas.home.arpa @resolver-ip or the equivalent nslookup query against both resolvers, DHCP lease details from each client class, and notes showing what resolved or failed with WAN disconnected.
- Current router, firewall, switch, access point, and DNS configuration exports before the change.
- Client evidence from the actual device: IP address, gateway, DNS servers, VLAN or SSID, and browser secure-DNS state.
- A test from outside the house, preferably cellular, when remote access or public exposure is part of the design.
- Firewall, tunnel, proxy, and DNS logs that show both allowed traffic and expected denies.
- A list of open ports, public hostnames, certificate expiry dates, and stale VPN or tailnet devices.
Failure Signals
- Local names stop working when the internet is down.
- Clients randomly use different DNS servers or bypass policy with browser secure DNS.
- Admin pages are reachable from guest, IoT, or public networks.
- No one can describe which device owns routing, DHCP, DNS, and remote access.
Adopt, Pilot, Defer, Avoid
- Adopt: Adopt the network change when ownership, DNS, firewall policy, remote access, and rollback are documented.
- Pilot: Pilot with one client, one VLAN, one hostname, or one tunnel before moving the whole house.
- Defer: Wait when the current setup is stable, backed up, monitored, and the proposed change is mostly curiosity.
- Avoid: Avoid exposing admin interfaces or broad internal networks just because a tunnel or reverse proxy makes it convenient.
Validation Checklist
- Local service names resolve with WAN disconnected.
- Router, NAS, Proxmox, Home Assistant, and reverse proxy names resolve from trusted devices.
- Both DNS servers return the same local answers.
- Clients receive expected DNS servers from DHCP.
- Monitoring alerts if one resolver goes down.
Common Mistakes
- Using ISP DNS as secondary and wondering why local names randomly fail.
- Depending on public DNS records for private services during WAN failure.
- Running DNS on the same host that depends on DNS to boot.
- Changing browser DoH settings without documenting them.
- Letting VPN clients use different DNS rules than home clients.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| Clients behave differently | DHCP, browser secure DNS, VPN DNS, IPv6, or manual settings are bypassing policy. | Check the resolver and gateway from the actual client, not only from the router UI. |
| Remote access breaks | Identity, DNS, tunnel routing, firewall policy, or certificate renewal changed. | Test from a mobile hotspot and review logs at the tunnel, proxy, and app layers. |
| Segmentation breaks apps | Discovery or controller traffic was blocked along with broad LAN access. | Add narrow mDNS, controller, DNS, NTP, or app-port exceptions and document them. |
Maintenance Cadence
Monitor both resolver processes and local-record drift monthly. Quarterly, disconnect WAN, renew a representative DHCP lease, query uncached local names through each resolver, and review cloud-dependent failures. Annually, verify the router and resolver exports remain usable on current hardware.
- Monthly: Review firmware, open ports, DNS failures, VPN users, certificate expiry, and noisy firewall blocks.
- Quarterly: Run a WAN-disconnect or remote-access test and confirm local names, admin access, and rollback notes still work.
- Yearly: Audit network segmentation, retire stale devices, and confirm router or firewall backups restore to current hardware.
The useful drill disconnects WAN, queries a fresh home.arpa name, renews DHCP, and temporarily stops one resolver to confirm the other returns the same local answer. Store the configuration exports somewhere reachable when both DNS hosts are unavailable.
When To Spend Money
Buy another DNS host only when the present router cannot serve a local zone, one host currently carries both resolver instances, or recovery requirements justify independent power and compute. Measure that gap before selecting a Pi, mini PC, UPS, or managed switch.
| Stage | Signal | Practical Buying Guidance |
|---|---|---|
| Do not buy yet | Coverage, DNS behavior, firewall policy, and client path have not been measured. | Map the network, export configs, test clients, and identify the bottleneck first. |
| Small useful spend | The design is sound but lacks one reliable link, management path, or recovery aid. | Managed switch, spare patch cables, labels, UPS for network gear, or a travel router for remote access testing. |
| Larger upgrade | Measured throughput, segmentation, VPN, Wi-Fi coverage, or routing limits block a real workflow. | Firewall appliance, access points with wired backhaul, 2.5GbE/10GbE switch, or a supported router platform. |
Useful Gear And Buyer Notes
The list starts with Raspberry Pi 5 kit as one possible resolver host, not a requirement or a complete redundancy plan. Compare Ethernet reliability, storage, power protection, replacement availability, and the ability to restore Pi-hole, AdGuard Home, Technitium, or Unbound configuration.
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
- Amazon search: Raspberry Pi 5 kit
- Amazon search: Intel N100 mini PC
- Amazon search: 2.5GbE mini PC firewall
- Amazon search: UPS small network
- Amazon search: managed switch
Related TechGeeks resources
- Homelab VLAN Design: Simple Network Segmentation That Works
- IoT Isolation for Homelabs: VLANs, Firewall Rules, and mDNS
- WireGuard Home VPN: Secure Remote Access for Your Homelab
- Homelab DNS Guide: Local Names, Ad Blocking, and Reliability
What This Does Not Protect or Validate
Router DHCP behavior, resolver releases, browser Secure DNS defaults, VPN DNS handling, and available hardware can change. This documentation-backed topology is not a measured TechGeeks outage result; run the WAN-disconnect, fresh-query, failover, and restore checks on the actual network.
It also does not replace a full security, backup, or disaster-recovery program. This is a documentation-backed design, not a report of measured TechGeeks outage testing. Run the WAN-disconnect, cold-cache, client-path, failover, and restore checks on your own network before relying on the design.
Segmentation, VPNs, tunnels, DNS filtering, and reverse proxies reduce risk only when firewall rules, logs, updates, and account recovery are maintained.
Practical FAQ
How do I make DNS keep working when the internet is down?
Keep local DNS local. Your router, Pi-hole, AdGuard Home, Technitium, or internal resolver should answer local names without forwarding to the internet, and clients should have at least two reachable resolvers that behave consistently. The important next step is to validate the recommendation with one small test before treating it as the default.
References
- Pi-hole project documentation
- AdGuard Home project repository
- Technitium DNS Server
- NLnet Labs Unbound documentation
- RFC 8375: Special-Use Domain home.arpa
- RFC 6762: Multicast DNS
- APNIC Blog: independent discussion of cold-start DNS behavior and resilience
Final Thought
The right answer is the one you can operate, document, test, and recover without guessing.
Need help applying this?
Bring TechGeeks into the real environment.
If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.
