On a recent trip I kept getting connection failures that needed retrying — pages half-loading, API calls timing out, the usual DNS-smells-wrong experience. It was intermittent enough to be annoying but consistent enough that I knew something was actually broken.
I narrowed it down to DNS pretty quickly. My GL.iNet MT-3000 travel router was dropping queries or returning nothing for some domains.
The culprit turned out to be obvious in retrospect: before leaving I had shut down my Pi-hole servers at home. Those Pi-holes live on my Tailscale network, and my travel router connects back to that network. Somewhere, something was still trying to use them for DNS.
I tried spinning one of the Pi-holes back up — no change. So last night I actually dug into the GL.iNet admin panel.
Here’s the thing I didn’t know: GL.iNet routers run AdGuard Home as the built-in DNS layer, and AdGuard Home has its own upstream DNS configuration that’s completely separate from the router’s basic DNS settings. You get to it via the AdGuard Home interface, under Settings > DNS settings > Upstream DNS servers.
Buried in there were two IP addresses: my Pi-hole boxes, hardcoded by their Tailscale IPs — a setting I’d configured and forgotten about entirely.
The fix was replacing those with something that doesn’t depend on my home network being up — 1.1.1.1 (Cloudflare) and 9.9.9.9 (Quad9). I have new Pi-holes now, but they’re not on Tailscale yet, so public DNS it is for now.
The tricky part was that the GL.iNet web UI has a DNS section in the main router config. I’d already checked that — it looked fine. The AdGuard Home upstream config is a completely separate place, only reachable by clicking through to the AdGuard Home admin interface itself. Easy to miss if you don’t know it exists.
If you use a GL.iNet router with AdGuard Home enabled and your DNS depends on anything on your home network, double-check those upstream DNS settings before you travel.