EdgeRouter's Local DNS Blackouts: A Home Lab Troubleshooting Tale

---

If you're running a Pi-hole behind an EdgeRouter and seeing inconsistent local DNS resolution—like some hostnames failing, resolving to incorrect public IPs, or only working intermittently—this might be the exact fix you’re looking for.

I’ll walk through the exact issue I ran into, what caused it, and the single setting that fixed it for good.

---

The Setup: EdgeRouter + Pi-hole + Conditional Forwarding

This is a pretty common home network layout:

• Router: Ubiquiti EdgeRouter 4 (10.10.1.1)

• DHCP: Handled by the EdgeRouter

• DNS: Pi-hole (10.10.1.149), handed out via DHCP

• Local DNS: Conditional Forwarding in Pi-hole is used to send queries for local hostnames (like myserver.local.lan) back to the router, which should know the client IPs it assigned via DHCP.

Everything looked solid on paper. The router was issuing leases. The Pi-hole was filtering ads and forwarding internal queries back to the router. Local devices should’ve been reachable via names like myserver.local.lan.

Except they weren’t.

---

The Symptoms: Inconsistent, Confusing, and Misleading

Local DNS lookups started failing in unpredictable and inconsistent ways:

• myserver.local.lan would return an NXDOMAIN.

• Sometimes it would resolve to a random public IP.

• Occasionally, it worked fine, only to break again minutes later.

• ping myserver might succeed thanks to mDNS, not DNS.

That inconsistency was the real headache. If it were always broken, I'd know where to start. But this was worse—it sometimes worked, just not reliably.

Most DNS queries were working just fine—external domains resolved without issue, and anything I’d manually assigned a static IP or hostname in Pi-hole worked consistently. The failures only affected DHCP-assigned devices that were expected to resolve through Conditional Forwarding.

---

The Investigation: Tracing the DNS Failure

Checking Pi-hole’s query logs revealed something important:

• Pi-hole was receiving queries for *.local.lan

• It was forwarding them to the EdgeRouter (10.10.1.1)

• But the router was replying with NXDOMAIN or sometimes a bogus IP

I SSH’d into the router and ran:

ping myserver.local.lan

No resolution. Same error.

So the EdgeRouter couldn’t even resolve names of devices it had given IPs to. That narrowed the problem down quickly.

---

The Root Cause: DHCP and DNS Weren’t Sharing Info

The EdgeRouter uses two separate systems:

• isc-dhcpd for DHCP leases

• dnsmasq for DNS forwarding

They can share hostname ↔ IP mappings, but seemingly only if explicitly configured.

I checked the current configuration:

show service dhcp-server use-dnsmasq
> disable   # (expected)

show service dhcp-server hostfile-update
> disable   # (problem!)

The hostfile-update setting tells isc-dhcpd to write lease info to a file that dnsmasq can read. With it disabled, dnsmasq had no idea who was on the network—so it couldn’t resolve local names.

---

The Fix: Enable Hostfile Updates

Here's how to fix it:

configure
set service dhcp-server hostfile-update enable
commit
save
exit

Then either:

• Reboot the router, or

• Restart dnsmasq, and renew leases on your clients

Once that’s done, Pi-hole will receive accurate local responses from the EdgeRouter, and local DNS will behave the way it should.

---

Why It Broke in Strange Ways

Before the fix, things broke in inconsistent and misleading ways because of how DNS systems and caches behave:

1. Initial failure – EdgeRouter had no hostname info → returns NXDOMAIN

2. Pi-hole fallback – Sends query to upstream (e.g., Cloudflare), which has no business answering *.local.lan, but may return a bogus wildcard record

3. Cached incorrect answer – Pi-hole serves a bad public IP for a while

4. Occasional success – If a lease was recently issued, some internal state might briefly align before it breaks again

After enabling hostfile-updateThat entire chain is avoided.

---

Final Notes: If You're Seeing Weird DNS in Your Lab...

If you're seeing symptoms like:

• Local hostnames randomly failing

• Public IPs resolving for .local.lan queries

• Inconsistent behavior that clears after a reboot (but comes back)

Then check this on your EdgeRouter:

show service dhcp-server hostfile-update

If it's disable, flip it to enable. That setting is the missing link that allows EdgeRouter's DHCP server to feed hostname info to its DNS forwarder—without it, local resolution will never be consistent.

---

Bonus: Why Not Just Use dnsmasq for Everything?

You could. You can even run dnsmasq for both DHCP and DNS on the EdgeRouter, but that’s not the default in most configurations—and if you’re already relying on isc-dhcpd, this fix gets things working with minimal disruption.

If this helped you chase down a bug DNS issue in your home lab, consider leaving a comment or sharing it. It might save someone else from going down the same rabbit hole.

Disclaimer:
Most of the formatting and a lot of the wording in this article were put together by ChatGPT 4.1, working from my notes and technical experience. I’m not a professional writer—just sharing what I’ve learned in the hope it might save someone else some time. Both ChatGPT and I can make mistakes, so always use your own judgment and double-check things before making changes to your own setup.