Pihole stops resolving local DNS addresses for Android device

Hash6232 · April 14, 2025, 6:06am

The issue I am facing:
I set pihole so it uses quad9 and cloudflare as DNS addresses and also added a bunch of local TLDs in the local DNS list. But when I'm on WiFi, connected to my router with DNS specifically pointing to pihole, the local DNS is resolved only once. Further resolutions after visiting other websites (and using quad9 and cloudflare dns) overwrite local DNS addresses and my device starts using them instead of also throwing local DNS into the mix. I also pointed wireguard to pihole using the DNS option in wg0.conf and it works as intended even on my Android device but everything stops working the moment I switch to WiFi.

Details about my system:
Docker image running on debian stable along with other containers. Everything running behind a Caddy reverse proxy.

What I have changed since installing Pi-hole:
Set quad9 and cloudflare DNS. Enabled conditional forwarding as suggested by Copilot

Bucking_Horn · April 14, 2025, 6:08am

Run from a laptop or PC connected to your WiFi, please share the output of:

nslookup pi.hole

nslookup flurry.com

nslookup pi-hole.net

Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

Hash6232 · April 14, 2025, 4:15pm

I changed DNS on my laptop network adapter so it points to my pihole (with local IP 192.168.1.10).

PS C:\Users\User> nslookup pi.hole
Server:  thinkcentre.local
Address:  192.168.1.10

Non-authoritative answer:
Name:    pi.hole.MYISPHOMENETADDRESS
Address:  127.0.0.1

PS C:\Users\User> nslookup flurry.com
Server:  thinkcentre.local
Address:  192.168.1.10

Non-authoritative answer:
Name:    flurry.com.MYISPHOMENETADDRESS
Address:  127.0.0.1

PS C:\Users\User> nslookup pi-hole.net
Server:  thinkcentre.local
Address:  192.168.1.10

Non-authoritative answer:
Name:    pi-hole.net.MYISPHOMENETADDRESS
Address:  127.0.0.1

The token URL is: https://tricorder.pi-hole.net/yiFgaPqN/

Bucking_Horn · April 15, 2025, 7:23am

As your debug log shows that you are running Pi-hole in Docker, please share your Pi-hole container's docker run or docker compose script.

What's that machine at 192.168.1.10?

Note that the .local TLD is reserved for mDNS protocol usage and should not be mixed with plain DNS.

If your router would be announcing .local as its local/search domain, you should change that to something suitable, e.g. to home.arpa, lan or internal.

All of your nslookups return 127.0.0.1.
That would indicate that it isn't Pi-hole that has answered those requests.

You should be able to verify this, e.g. if you run nslookup pi-hole.net, do the respective lookups register in Pi-hole's Query Log?

Hash6232 · April 17, 2025, 4:41pm

That IP is my home server. It runs all of my docker containers. Pihole among them. I also removed the local DNS assignments from my router because I want to use a DNS proxy instead. I don't need the local TLD to be available for everyone, just to the devices using pihole as a DNS proxy. I will do more tests now that I changed TLD to .lan and report back on what happens when I use nslookup.

The .env file merely contains the timezone, web UI password and sets FTLCONF_dns_listeningMode to all.

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    env_file: .env
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
    volumes:
      - ./:/etc/pihole
    restart: unless-stopped

networks:
  default:
    name: caddy_net
    external: true

Hash6232 · April 17, 2025, 5:53pm

It seems that using a different TLD did the trick. I ended up using thinkcentre.home, edited my Caddyfile and added the necessary local DNS domain&subdomain entries to pihole. Now everything works

Hash6232 · April 18, 2025, 7:07am

It seems I jinxed myself. The same problem is happening after a day. And from the look of it, it seems to be an Android problem. I can connect to pihole no problem on my laptop. I naturally set my pihole local IP as primary and secondary DNS address for both my access points in the Android settings but eventually they stop working. When I tried clearing the field to re-enter the IP I noticed the placeholder used google DNS. It might be using google dns secretly as fallback for some reason..

Ok. I edited my DNS addresses in the WiFi settings of my phone and set the primary address to my pihole and the secondary address to a dummy IP in case it was silently rejecting identical addresses and using google DNS as fallback. After that I tested on both Firefox and Chrome and it is only working in Chrome. I don't know why that would be the case. Possibly some sort of internal DNS cache in Firefox for Android?

Even when I empty the DNS cache forcefully I am not able to resolve the address on Firefox for Android

I know this isn't just a Firefox issue because other apps using the local TLD also can't resolve the address. For example I can't connect to my sftp directories or to the qbittorrent remote client. When I try to browse other websites I correctly see my device in pihole query logs too

Hash6232 · April 18, 2025, 9:09am

This is what I see in the pihole.logs when I tap on refresh on my phone while being on thinkcentre.home (which should be resolved thanks to the local DNS rules):

2025-04-18 11:07:34.875 gravity blocked incoming.telemetry.mozilla.org is 0.0.0.0
2025-04-18 11:07:42.422 query[HTTPS] thinkcentre.home from 192.168.1.12
2025-04-18 11:07:42.422 cached thinkcentre.home is NODATA
2025-04-18 11:07:42.481 query[A] incoming.telemetry.mozilla.org from 192.168.1.12
2025-04-18 11:07:42.481 gravity blocked incoming.telemetry.mozilla.org is 0.0.0.0

Bucking_Horn · April 18, 2025, 11:24am

Please provide a fresh debug token.

Above just shows a HTTPS query for thinkcentre.home.
A client would be expected to also send A and AAAA queries, especially if a HTTPS reply is NODATA.

If A/AAAA really would be missing from your Pi-hole's Query Log, that would again imply that your client uses another DNS server besides Pi-hole, just as your previous nslookup results:

Hash6232 · April 18, 2025, 11:43am

This is the token URL: https://tricorder.pi-hole.net/oVG3TsI0/

This is the nslookup from my laptop output, where everything works fine, with some bizarre results (notice the server being an unrelated subdomain instead of the base url). The requests also shows up in my pihole query logs:

PS C:\Users\User> nslookup pi.hole
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.1.10

Non-authoritative answer:
Name:    pi.hole.MYISPHOMENETADDRESS
Address:  127.0.0.1

PS C:\Users\User> nslookup flurry.com
Server:  servarr.thinkcentre.home
Address:  192.168.1.10

Non-authoritative answer:
Name:    flurry.com.MYISPHOMENETADDRESS
Address:  127.0.0.1

PS C:\Users\User> nslookup pi-hole.net
Server:  servarr.thinkcentre.home
Address:  192.168.1.10

Non-authoritative answer:
Name:    pi-hole.net.MYISPHOMENETADDRESS
Address:  127.0.0.1

For reference, this is my Caddyfile:

thinkcentre.home {
        tls internal
        redir / /admin
        reverse_proxy pihole:80
}

*.thinkcentre.home {
        tls internal

        @servarr host servarr.thinkcentre.home
        handle @servarr {
                redir /autobrr /autobrr/
                redir /prowlarr /prowlarr/

                handle_path /autobrr/* {
                        uri strip_prefix /autobrr
                        reverse_proxy autobrr:7474
                }

                reverse_proxy /prowlarr/* prowlarr:9696
        }

        @torrent host torrent.thinkcentre.home
        handle @torrent {
                reverse_proxy qbittorrent:8081
        }
}

and this is my local DNS:

Bucking_Horn · April 18, 2025, 12:50pm

And how do they register in Pi-hole's logs?

To that regard, please share the results of:

sudo grep -n flurry.com /var/log/pihole/pihole.log

sudo grep -n servarr.thinkcentre.home /var/log/pihole/pihole.log

sudo grep -n pi-hole.net /var/log/pihole/pihole.log

As you run a dockered Pi-hole, you'd need to execute those statements from within your Pi-hole container.

Hash6232 · April 18, 2025, 1:31pm

Here's the result. I omitted the lines from discourse.pi-hole.net. Also servarr.thinkcentre.home is a subdomain for the servarr suite. Pihole is hosted on thinkcentre.home. I don't know why it's even there in the logs.. Alternatively I could try purging the docker volume and starting from scratch. Hoping this entire mess wasn't being caused by caddy somehow

(ranger) root@thinkcentre:/srv/docker/pihole# docker exec pihole grep -n flurry.com /var/log/pihole/pihole.log
27165:Apr 18 13:31:47 dnsmasq[52]: query[A] flurry.com.MYISPHOMENETADDRESS from 192.168.1.137
27166:Apr 18 13:31:47 dnsmasq[52]: forwarded flurry.com.MYISPHOMENETADDRESS to 1.0.0.1
27167:Apr 18 13:31:47 dnsmasq[52]: reply flurry.com.MYISPHOMENETADDRESS is 127.0.0.1
27168:Apr 18 13:31:47 dnsmasq[52]: query[AAAA] flurry.com.MYISPHOMENETADDRESS from 192.168.1.137
27169:Apr 18 13:31:47 dnsmasq[52]: forwarded flurry.com.MYISPHOMENETADDRESS to 1.0.0.1
27170:Apr 18 13:31:47 dnsmasq[52]: reply flurry.com.MYISPHOMENETADDRESS is NODATA-IPv6
27404:Apr 18 13:47:12 dnsmasq[52]: query[A] flurry.com.MYISPHOMENETADDRESS from 192.168.1.137
27405:Apr 18 13:47:12 dnsmasq[52]: cached flurry.com.MYISPHOMENETADDRESS is 127.0.0.1
27406:Apr 18 13:47:12 dnsmasq[52]: query[AAAA] flurry.com.MYISPHOMENETADDRESS from 192.168.1.137
27407:Apr 18 13:47:12 dnsmasq[52]: cached flurry.com.MYISPHOMENETADDRESS is NODATA-IPv6

(ranger) root@thinkcentre:/srv/docker/pihole# docker exec pihole grep -n servarr.thinkcentre.home /var/log/pihole/pihole.log
27154:Apr 18 13:31:34 dnsmasq[52]: /etc/pihole/hosts/custom.list 192.168.1.10 is servarr.thinkcentre.home
27164:Apr 18 13:31:47 dnsmasq[52]: /etc/pihole/hosts/custom.list 192.168.1.10 is servarr.thinkcentre.home
27174:Apr 18 13:32:12 dnsmasq[52]: /etc/pihole/hosts/custom.list 192.168.1.10 is servarr.thinkcentre.home
27397:Apr 18 13:47:02 dnsmasq[52]: /etc/pihole/hosts/custom.list 192.168.1.10 is servarr.thinkcentre.home
27403:Apr 18 13:47:12 dnsmasq[52]: /etc/pihole/hosts/custom.list 192.168.1.10 is servarr.thinkcentre.home
27409:Apr 18 13:47:19 dnsmasq[52]: /etc/pihole/hosts/custom.list 192.168.1.10 is servarr.thinkcentre.home

(ranger) root@thinkcentre:/srv/docker/pihole# docker exec pihole grep -n pi-hole.net /var/log/pihole/pihole.log
131:Apr 17 18:43:03 dnsmasq[52]: query[A] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
132:Apr 17 18:43:03 dnsmasq[52]: forwarded pi-hole.net.MYISPHOMENETADDRESS to 1.0.0.1
133:Apr 17 18:43:03 dnsmasq[52]: reply pi-hole.net.MYISPHOMENETADDRESS is 127.0.0.1
134:Apr 17 18:43:03 dnsmasq[52]: query[AAAA] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
135:Apr 17 18:43:03 dnsmasq[52]: forwarded pi-hole.net.MYISPHOMENETADDRESS to 1.0.0.1
136:Apr 17 18:43:03 dnsmasq[52]: reply pi-hole.net.MYISPHOMENETADDRESS is NODATA-IPv6
27175:Apr 18 13:32:12 dnsmasq[52]: query[A] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
27176:Apr 18 13:32:12 dnsmasq[52]: cached pi-hole.net.MYISPHOMENETADDRESS is 127.0.0.1
27177:Apr 18 13:32:12 dnsmasq[52]: query[AAAA] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
27178:Apr 18 13:32:12 dnsmasq[52]: cached pi-hole.net.MYISPHOMENETADDRESS is NODATA-IPv6
27410:Apr 18 13:47:19 dnsmasq[52]: query[A] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
27411:Apr 18 13:47:19 dnsmasq[52]: cached pi-hole.net.MYISPHOMENETADDRESS is 127.0.0.1
27412:Apr 18 13:47:20 dnsmasq[52]: query[AAAA] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
27413:Apr 18 13:47:20 dnsmasq[52]: cached pi-hole.net.MYISPHOMENETADDRESS is NODATA-IPv6

Bucking_Horn · April 18, 2025, 2:00pm

I would have expected to see 4 DNS queries hitting PI-hole's Query Log for each nslookup, e.g.

query[A] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
query[AAAA] pi-hole.net.MYISPHOMENETADDRESS from 192.168.1.137
query[A] pi-hole.net from 192.168.1.137
query[AAAA] pi-hole.net from 192.168.1.137

Your output shows that the last two queries never make it to Pi-hole, but only queries expanded by your local search domain MYISPHOMENETADDRESS.

Is MYISPHOMENETADDRESS some actual domain you've obfuscated, probably even a public one?

Otherwise, I'd expect public DNS servers to reply DNS requests for anything `MYISPHOMENETADDRESS` with NXDOMAIN (click for details)

dig pi-hole.net.MYISPHOMENETADDRESS @1.0.0.1
; <<>> DiG 9.16.50-Debian <<>> pi-hole.net.MYISPHOMENETADDRESS @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42731
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.MYISPHOMENETADDRESS. IN	A

;; AUTHORITY SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2025041800 1800 900 604800 86400

;; Query time: 19 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri Apr 18 15:42:59 CEST 2025
;; MSG SIZE  rcvd: 135

Furthermore, DNS requests for servarr.thinkcentre.home are entirely absent from your logs.

All observations combined, this would strongly suggest that something is intercepting DNS requests in your network, and that something is only forwarding a subset of DNS requests to your Pi-hole.

The most likely candidates would be dedicated firewall hardware or your router.
What make and model is your router?

Hash6232 · April 18, 2025, 2:14pm

Yeah. It's essentially the equivalent of homenet.myisp.tld. It's set in my router in the DNS tab. I am using my ISP router and its internal firewall so nothing dedicated that might get in the way. As far as I know there's only one DNS proxy in the network and it's pihole. Would purging my docker volume and starting from scratch help?

I just realized that maybe it's using servarr.thinkcentre.home because it's the first match in the custom.list file. I deleted all the entries and left only the base domain in the local DNS tab. The subdomains seem to still work even without explicitly adding them. I flushed the cache in my laptop and in my browser and they still resolve so it's all good. I'll do some more testing with my phone

Bucking_Horn · April 18, 2025, 3:18pm

No.

As explained, your observations indicate that DNS requests are intercepted and redirected to another DNS server, and that then only forwards some of those requests to Pi-hole.

Reinstalling Pi-hole would not change that.
You'd need to locate and reconfigure the interceptor instead, if possible.

Run from your Windows machine, please share the result of:

nslookup -class=chaos -type=txt version.bind

And run from within your Pi-hole container, please share

dig servarr.thinkcentre.home @127.0.0.1

dig servarr.thinkcentre.home.MYISPHOMENETADDRESS @8.8.8.8

Hash6232 · April 18, 2025, 4:18pm

PS C:\Users\User> nslookup -class=chaos -type=txt version.bind
Server:  servarr.thinkcentre.home
Address:  192.168.1.10

version.bind    text =

        "dnsmasq-pi-hole-v2.91"

(ranger) root@thinkcentre:/srv/docker/wireguard# docker exec pihole dig servarr.thinkcentre.home @127.0.0.1

; <<>> DiG 9.18.35 <<>> servarr.thinkcentre.home @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48310
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;servarr.thinkcentre.home.      IN      A

;; ANSWER SECTION:
servarr.thinkcentre.home. 0     IN      A       192.168.1.10

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Apr 18 18:09:58 CEST 2025
;; MSG SIZE  rcvd: 69

(ranger) root@thinkcentre:/srv/docker/wireguard# docker exec pihole dig servarr.thinkcentre.home.MYISPHOMENETADDRESS @8.8.8.8

; <<>> DiG 9.18.35 <<>> servarr.thinkcentre.home.MYISPHOMENETADDRESS @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64566
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;servarr.thinkcentre.home.MYISPHOMENETADDRESS. IN A

;; ANSWER SECTION:
servarr.thinkcentre.home.MYISPHOMENETADDRESS. 21600 IN A 127.0.0.1

;; Query time: 40 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Apr 18 18:12:13 CEST 2025
;; MSG SIZE  rcvd: 94

I tried looking for servarr in the config file and the toml file was storing it first place in the array. I removed everything and only left thinkcentre.home and now nslookup is using it:

PS C:\Users\User> nslookup -class=chaos -type=txt version.bind
Server:  thinkcentre.home
Address:  192.168.1.10

version.bind    text =

        "dnsmasq-pi-hole-v2.91"

Hash6232 · April 18, 2025, 6:42pm

I think I might have found my problem: Be aware of Android's shady IPv6 DNS

When I check my DNS list for a certain AP on Android, I sometimes can see an IPV6 right on top of my preferred DNS address. For some reason Android likes to sneak it on top turning it into the de-facto main DNS address. Clearing the DNS fields and re-entering them fixes the problem at first but after reconnecting the IPV6 address shows up.

The only workaround I found so far is turning DHCP back on and using an always-on VPN connection so my device is forced to use the same DNS as my docker container. No further wireguard configuration is required. I merely added a DNS option to my wireguard service inside my docker-compose.yml and set the address to my local host IP (in my case 192.168.1.10). Now everything works perfectly even when I'm connected to the same network the wireguard server is in.

Some people recommend adding 192.168.1.0/24 (or whatever your subnet is) to the AllowedIPs of the wireguard peer connection, next to 0.0.0.0/0 in order to allow local IPs resolution and it indeed appears to work but I don't know the implications of such a change. I'll simply keep using the local DNS rule set in pihole to connect to my home server

Bucking_Horn · April 19, 2025, 7:25am

This is just cosmetics, it only affects how Pi-hole would resolve a reserve lookup for 192.168.1.10.

It won't address your issue of client requests not reaching your Pi-hole, and thus cannot resolve local names.

Your router may be advertising its own IPv6 address as local DNS server, allowing your clients to by-pass Pi-hole.

You'd have to find a way to configure your router to stop advertising its own IPv6 as DNS server, or to advertise your Pi-hole host machine's IPv6.

You'd have to consult your router's documentation sources on further details for its IPv6 configuration options.

If your router doesn't support configuring IPv6 DNS, you could consider disabling IPv6 altogether, provided you'd not depend on IPv6 for reasons.

If your router doesn't support that either, your IPv6-capable clients will always be able to bypass Pi-hole via IPv6.
You could then try to mitigate this, by setting Pi-hole as the only upstream of your router, provided your router supports it.
But note that you won't be able to attribute DNS requests to original individual IPv6 clients in such a configuration.

Hash6232 · April 19, 2025, 7:36am

I just checked my router control panel and the DHCPv6 server is already off so the problem might not be in my router but in Android 15. In order to change the default DNS addresses in my router I need to reset it to factory default and although it's pretty easy and I only need a bunch of parameters to sign-in to the VoIP service I would much rather limit the custom DNS values to the devices I use and let everyone else use the default ISP DNS addresses

I also found this one thread where you also helped someone with a similar problem and tried setting my router the same way he did: IPv6 DNS configuration on ZTE H6645P - #7 by Deltwin

but instead of using a real IPv6 I entered a dummy address: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Whilst the setting is turned off, this will also hopefully act as a contingency plan in case it turns itself back on. In theory, a non-existing address should simply not work meaning the IPv6 DNS resolution should fail and fallback to my primary custom choice

Bucking_Horn · April 19, 2025, 8:25am

DHCPv6 is different from NDP Router Advertisements (RA).
Switching off your router's DHCPv6 server may or may not disable RAs also. You'd have to consult your router's documentation and support for details.

As explained, that would allow IPv6 clients to by-pass Pi-hole completely, unless you can control IPv6 DNS server addresses on a client itself.

If yours is also a ZTE router featuring the same web UI, you should be fine with adopting their configuration.