Android 15 stopped reading dnsmasq entries

Yesterday I swapped out a wireless access point and, once that seemed to be working, attempted to get DAWN running to improve roaming. That didn't go great (clients stopped being able to connect to wifi) so I did my best to revert it.

Now I'm seeing that my Google Pixel 7 Pro running Android 15 can no longer connect to my local self-hosted services for which I had defined a named address in dnsmasq. My same SSID is setup for 2.4 and 5 GHz on the router and AP, so I tried enabling one at a time and all behave the same. I even connected a USB-C to ethernet adapter to my phone to rule out wifi specific issues and the issue persists.

However, if I turn on my Wireguard VPN connection from my phone to my router (either while still on the local network or on mobile data) I am able to connect to addresses listed in my dnsmasq settings.

My current /etc/config/dhcp (sanitized by removing static leases and additional list address '...' entries):

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'
        option confdir '/tmp/dnsmasq.d'
        list address '/home.lan/192.168.1.90'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'
        list ra_flags 'none'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config dhcp 'iot'
        option interface 'iot'
        option start '100'
        option limit '150'
        option leasetime '12h'

config dhcp 'guest'
        option interface 'guest'
        option start '100'
        option limit '150'
        option leasetime '12h'

config dhcp 'CAMS'
        option interface 'CAMS'
        option start '100'
        option limit '150'
        option leasetime '12h'

What I remember doing during the DAWN setup (following these docs) is

  1. replacing the default version of wpad-* on my wireless router and AP with wpad-openssl (originally I accidentally installed wpad thinking that was the "full" one mentioned in the docs - it seems I probably could have left that stock)
  2. installing luci-app-dawn and
  3. adjusting the few config items in the docs

Working backwords, I removed the config items, uninstaled dawn, and for wpad I forgot exactly which version was installed previously but tried both leaving it as is and replacing with my best guess from memory (wpad-wolfssl on my E8450 running OpenWRT 22.03.3 and wpad-mbedtls on the newly set up NWA50AX Pro running OpenWRT 24.10.1).

For testing, I have been using termux and Network Analyzer. While on wifi with VPN off I can do a DNS query (whithout specifying a DNS server - the text box is left with the dimmed reference IP of 192.168.1.1) for my home.lan address it immediately pulls up an A record with the correct IP. If I try a ping or route test for home.lan it says "Failed to resolve IP address". If I enable my Wireguard tunnel (in which DNS server is set to 192.168.1.1 and Allowed IPs are 192.168.1.0/24, 192.168.9.0/24, and 172.16.1.0/24), then my ping and route tests work fine.

My Linux desktop (hard-wired), a Linux Laptop (on wifi), and a macOS laptop (tested hard-wired and wifi) all are able to connect to the dnsmasq entries (although I did notice one device that I usually connect to using <hostname>.lan isn't reachable now, so maybe that is a clue?).

I have tried:

  1. Disabling Private DNS on my phone
  2. installing umdns (which I believe had been installed with DAWN but removed again automatically when DAWN was removed)
  3. DNS hijacking (posibly just the LuCI part - I'm forgetting what all I did at midnight last night)
  4. I think there was more, but it was late and I can't recall anything else.

Any tips for digging deeper into this?

Not much to do with local topology, it just falls to auto-doh , you can add canary domain to override its default behavior and use local dns.

I'm not familiar with canary domains, but some googling found the docs for https-dns-proxy which seems to set canary domains for local requests in addition to proxying all DNS to use DoH (a nice bonus).

I've got it setup and loading https://one.one.one.one/help/ it shows that my traffic is using DoH (which it wasn't before on either my phone or computer), so to me at least that indicates the DNS traffic is going through OpenWRT's dnsmasq, but I'm still not able to resolve my internal addresses on my Android phone unless I'm specifically doing a DNS lookup separate from anything else (nslookup home.lan or Network Analyzer app).

What is particularly curious for me is that I'm 99% sure this was all working a few days ago - I've got at least one Android app that was configured to use one of these dnsmasq address overrides and I'm sure I was using it without VPN (I'm just not sure how recently).

Selection is timing based, few slow responses and it goes to public secure dns. I

Okay, I think I fixed it. I had tried the DNS hijacking before, and then I did the canary domains via https-dns-proxy, but I did not use them together. Turning both on, things seem to be working again!

It is still weird to me how this broke to begin with, but I've got network wide DoH now, so I guess it is a net win.

Thanks for the help @brada4

Woops, spoke too soon. Seems like it is maybe intermittently fixed? I tried accessing something on my network again and it is back to not resolving. I cycled my wifi and now it is back.

check the dns stats, maybe you need to ignore slow provider dns server.

killall -USR1 dnsmasq
logread -e dnsmasq