Check from the LAN client:
nslookup koffiezetapparaat.lan 8.8.8.8
This should be intercepted and resolved correctly.
This is so strange, it seems to work correctly from e.g. my laptop:
$ nslookup koffiezetapparaat.lan 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Name: koffiezetapparaat.lan
Address: 192.168.1.190
and even with different DNS servers:
$ nslookup koffiezetapparaat.lan 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Name: koffiezetapparaat.lan
Address: 192.168.1.190
but still not on my Android phone.
I looked it a bit up and it seems that there are other people with (kind of) the same problem. For instance, this topic on Android stack exchange: https://android.stackexchange.com/questions/49188/how-to-get-mdns-working-for-chrome-on-android
Manually setting the primary (and secondary) DNS server to 192.168.1.1 didn't change anything either. I have no clue on how to go from here, really.
1 Like
It seems the only way out is to buy a public domain. 
guys? has anyone tried my suggestion yet? Force Android phone to use local DNS for local domain name resolving
3 Likes
For me Network Analyzer can resolve and ping a host in the lan, but maybe it has to do with the Android version. I have just a hijack rule to send all queries to my Piholes.
1 Like
Newer Androids using port 853 by default for name resolution on IPv6. If IPv6 service is not available the fallback is hardcoded for 8.8.8.8/4.4 port 53 in any case. A public resolver will never resolve a local domain.
For me it sounds you have missconfigured dnsmasq/firewall. Like dnsmasq is bypassed. oO
What happen if you edit /etc/hosts and enter a new line with "192.168.1.190 koffiezetapparaat koffiezetapparaat.lan"? Is it getting resolved now?
What is the output of: "uci show dhcp"?
2 Likes
That's pretty cool, this actually works:
I still hope to find a solution which is less of a workaround, but if I don't find it, I will use this app!
2 Likes
Try to block both DoH and DoT ports for Google DNS:
1 Like
What happen (...) resolved now?
# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.1.190 koffiezetapparaat koffiezetapparaat.lan
Then I issued /etc/init.d/dnsmasq restart but still ended up with 'Failed to resolve IP address'.
What is the output of: "uci show dhcp"?
root@openwrt:~# uci show dhcp
dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
dhcp.@dnsmasq[0].localservice='1'
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.start='100'
dhcp.lan.limit='150'
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'
dhcp.lan.ra_management='1'
dhcp.lan.leasetime='2h'
dhcp.lan.force='1'
dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'
dhcp.odhcpd=odhcpd
dhcp.odhcpd.maindhcp='0'
dhcp.odhcpd.leasefile='/tmp/hosts/odhcpd'
dhcp.odhcpd.leasetrigger='/usr/sbin/odhcpd-update'
dhcp.odhcpd.loglevel='4'
dhcp.@host[0]=host
dhcp.@host[0].mac='[mqtt-mac]'
dhcp.@host[0].dns='1'
dhcp.@host[0].ip='192.168.1.4'
dhcp.@host[0].name='mqtt'
dhcp.@host[1]=host
dhcp.@host[1].mac='[openwrt-mac]'
dhcp.@host[1].name='openwrt'
dhcp.@host[1].dns='1'
dhcp.@host[1].ip='192.168.1.1'
dhcp.@host[2]=host
dhcp.@host[2].mac='[second openwrt-mac]'
dhcp.@host[2].name='openwrt-boven'
dhcp.@host[2].dns='1'
dhcp.@host[2].ip='192.168.1.2'
dhcp.@host[3]=host
dhcp.@host[3].mac='[third openwrt-mac]'
dhcp.@host[3].name='openwrt-kelder'
dhcp.@host[3].dns='1'
dhcp.@host[3].ip='192.168.1.3'
dhcp.@host[4]=host
dhcp.@host[4].name='openhab'
dhcp.@host[4].dns='1'
dhcp.@host[4].ip='192.168.1.5'
dhcp.@host[4].mac='[openhab-mac]'
I have added this part to the firewall:
firewall.@rule[11]=rule
firewall.@rule[11].dest_port='853'
firewall.@rule[11].src='lan'
firewall.@rule[11].name='Block Google'\''s DNS New'
firewall.@rule[11].dest='wan'
firewall.@rule[11].target='REJECT'
firewall.@rule[11].dest_ip='8.8.8.8' '8.8.4.4' '2001:4860:4860::8844' '2001:4860:4860::8888'
firewall.@rule[11].proto='tcp' 'udp'
However, koffiezetapparaat doesn't get resolved with this new rule.
What might be interesting: I took a look at /cgi-bin/luci/admin/status/iptables and saw that there hasn't been any traffic on those rules until now:
Perhaps I should set something up in OpenWrt to see what addresses (and ports) my Android device tries to communicate with?
1 Like
Make sure to reconnect your phone to apply changes.
Reloading OpenWrt firewall most likely doesn't break established connections.
Hmm... If hosts file does not bite then I would assume that your phone is not asking DNSmasq for DNS. On my phone I can set WLAN settings manually. If I do so it is pre-filled with 8.8.8.8 and 8.8.4.4 (Android 9) for DNS resolution. If I replace it with a dummy dns (does not resolve anything) I can see that the device itself is still using an huawei dns resolver to get in touch with his own services (dns.hi-cloud.cn; cannot remember the exact name anymore; tcpdump showed me the traffic).
So I decided for myself to intercept any 53,853,5353 traffic redirecting to LAN IP respectivly I've blocked 853 and 5353 completely. In addition I've blocked the main DoH IPs/Servers including Huawei DNS. I cannot be sure if I got all because there is a lot 443 traffic to other Huawei domains also.
If you setup all correctly (esp. your firewall rules) then Android is using your DNS resolver for sure. It is remarking this if you connect your phone to a WLAN with this hard redirects with an "!" beside of the Wifi picture in headline at the beginning of the connection was initiated (like no connection available).
But beside all that it (in my experience) it is more likely that the program which you are using to access your LAN location is not using the defaults from Android and is using its own DNS resolution method. I can see this on my device also. Some Apps are able to use local names others are not. Which means that I have to use plain IP instead.
And Android 9+ has an option to explicit set an DNS (called "Private DNS"). You could try to set DNS here globally (at least for Android)
.
So the best bet is to analyse with tcpdump first to see what is going on and/or to try another program to see if things are changing. If I look at your LSC Smart .... App I would say that it is more an App issue.
2 Likes
My 2 cents, have you double checked the DHCP server properties (you may force the DNS in DHCP options, and add a custom local domain)...
Do you also use a local suffix domain ?
Lan / Local / other...
Sometimes, short (local or lan) resolutions do not work correctly, but a full local domain may fix this behavior...
Strange behaviour going on. A minute ago, my phone suddenly resolved koffiezetapparaat.lan properly. I wanted to make some screenshots to show you this along with the current settings (for future readers ofr future reference) but all of a sudden, koffiezetapparaat.lan does not get resolved properly anymore.
Luckily, I saved the tcpdump log (as pwned suggested). I will read through this and try to find out what went different this time.
Correct resolving:
16:02:02.808623 ARP, Request who-has koffiezetapparaat tell Telefoon.lan, length 46
16:02:02.808802 IP Telefoon.lan.18456 > openwrt.lan.53: 40623+ PTR? 190.1.168.192.in-addr.arpa. (44)
No resolving:
16:13:32.611251 IP Telefoon.lan.59676 > 52.232.216.86.443: Flags [P.], seq 2606:3587, ack 5756, win 422, options [nop,nop,TS val 819405971 ecr 1053534868], length 981
16:13:33.400697 IP Telefoon.lan.59676 > 52.232.216.86.443: Flags [.], ack 6064, win 433, options [nop,nop,TS val 819406768 ecr 1053543441], length 0
16:16:01.132239 IP Telefoon.lan.49108 > 20.185.73.23.443: Flags [P.], seq 3588:4569, ack 6064, win 433, options [nop,nop,TS val 3457205215 ecr 710600902], length 981
16:16:01.305224 IP Telefoon.lan.49108 > 20.185.73.23.443: Flags [.], ack 6372, win 444, options [nop,nop,TS val 3457205401 ecr 710608801], length 0
16:20:24.274708 IP Telefoon.lan.35954 > 20.44.78.251.443: Flags [.], seq 2030808332:2030809760, ack 3394053553, win 422, options [nop,nop,TS val 1762652882 ecr 3877128620], length 1428
16:20:24.274838 IP Telefoon.lan.35954 > 20.44.78.251.443: Flags [P.], seq 1428:1580, ack 1, win 422, options [nop,nop,TS val 1762652882 ecr 3877128620], length 152
16:20:24.939723 IP Telefoon.lan.35954 > 20.44.78.251.443: Flags [.], ack 309, win 433, options [nop,nop,TS val 1762653551 ecr 3877139229], length 0
What I think is happening here: Android maybe uses a range of different DNS (over HTTPS) servers to resolve hostnames. The one time it resolved koffiezetapparaat.lan correctly was the time that it used a blocked Google DNS server and thus relayed it to openwrt.lan to do the resolving. The other times, it gets passed as HTTPS traffic to different IP's.
3 Likes
A whois is telling: OrgTechName: Microsoft Routing, Peering, and DNS
I guess the App itself is asking this cloud DNS server. Android will probably never rely on a Microsoft DNS resolver. 
As the App is asking over HTTPS you cannot do much about it. The only thing you could do is to get the resolving name of this IP like for other resolvers (e. g. dns.quad9.net) and block this address/url or redirect it to your local DNS. But that would only work if the App is not so smart and does not fetch a list of possible DNS resolvers before over its own servers to have more then one available.
If you are lucky it is hardcoded and you just have to redirect a few urls.
EDIT: What you could try is restrict the device by MAC/IP to LAN only (so no internet available for it; if this is enough for your needs). It might be that your redirect to the local resolver is working then and your local domain gets resolved every time.
Another soultion would be to reach your lan from outside over your regular 4G connection (using DDNS with port forwarding and redirecting).
2 Likes
I have tried a lot of tcpdumping today and yesterday but failed to properly isolate DNS traffic to/from my phone; I will open a different topic for that right now and report back as soon as this is resolved.
I've been doing a lot of research on this the last couple of days and found out that Google Chrome (!) on my phone resolves local DNS just the way it should. Even without setting extra firewall rules.
I have a strong feeling now that my problems have little to do with Android or OpenWrt but rather Firefox' implementation of DNS on Android.
Thank you for all the help you've offered over the last couple of days. I've learnt a lot about OpenWrt and networks in general.
Maybe I will address this to the Firefox developers, but I feel like the work here is done for now.
2 Likes
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Firefox uses DNS over HTTPS by default on both Android and PC, as a privacy feature. It ignores the system's DNS settings, afaik.
You can read more about it and how to turn it off here
EDIT: Btw, Chrome is also rolling out the same feature in version 83 and later, enabling DNS-over-HTTPS where it can
3 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.