What's new

dnsmasq hostname doesn't resolve on OSX/IPad but resolves on Windows/Android

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Dathuil

New Around Here
Hey folks, hoping someone can point me in the right direction to solve my problem.

I've got a NAS running on my local network that run some docker containers (home assistant etc) which exposes a port on the local network. For ease of use and not wanting to mess around with my external domain name I figured to use dnsmasq to map two hostnames to the internal ip address of the NAS so I can just go to homeassistant.local/mnemosyne.local in the browser instead.

I've installed merlin and setup the following entry in the dnsmasq.conf.add file after following the following guide in the wiki
Bash:
admin@RT-AC88U-E008:/jffs/configs# cat dnsmasq.conf.add
address=/homeassistant.local/mnemosyne.local/192.168.2.100
admin@RT-AC88U-E008:/jffs/configs#

After all the restarts and DNS flushing on Windows/Android I can navigate to either URL and be redirected to the NAS as expected. However on OSX/Ipad when I attempt the same only the mnemosyne.local hostname resolves.
On my windows machine when I ping either I get back the static IP address of the NAS
Code:
Pinging homeassistant.local [192.168.2.100] with 32 bytes of data:
Reply from 192.168.2.100: bytes=32 time=1ms TTL=64
Reply from 192.168.2.100: bytes=32 time=2ms TTL=64
Reply from 192.168.2.100: bytes=32 time=1ms TTL=64
Reply from 192.168.2.100: bytes=32 time=2ms TTL=64


On OSX when I ping mnemosyne.local I get back the static IP of the NAS
Code:
ping mnemosyne.local
PING mnemosyne.local (192.168.2.100): 56 data bytes
64 bytes from 192.168.2.100: icmp_seq=0 ttl=64 time=6.988 ms
64 bytes from 192.168.2.100: icmp_seq=1 ttl=64 time=5.241 ms
64 bytes from 192.168.2.100: icmp_seq=2 ttl=64 time=6.709 ms
64 bytes from 192.168.2.100: icmp_seq=3 ttl=64 time=6.853 ms
64 bytes from 192.168.2.100: icmp_seq=4 ttl=64 time=5.924 ms
64 bytes from 192.168.2.100: icmp_seq=5 ttl=64 time=6.798 ms
^C
--- mnemosyne.local ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.241/6.419/6.988/0.629 ms

On OSX when I ping homeassistant.local I get the following error
Code:
❯ ping homeassistant.local

ping: cannot resolve homeassistant.local: Unknown host

I'm at a loss currently as to what could be causing this given that it does work on Windows, so any and all help or advice would be appreciated!
I'm aware that this could be something to do with how the NAS is setup, but given that it's working on Windows/Android I figured I should start with the first connection point
 
This sounds like the age-old problem of Apple devices using mDNS to resolve names rather than DNS. What do you get if you try an nslookup?
Code:
nslookup homeassistant.local
 
Code:
→ nslookup homeassistant.local
Server:        192.168.2.1
Address:    192.168.2.1#53

Name:    homeassistant.local
Address: 192.168.2.100

Looks to be resolving the correct IP with nslookup @ColinTaylor. is this something that can be resolved on the router or does it have to be configured on the machine iteself?
 
So DNS on the router is working correctly. So this is a client side issue.

Check your mac's resolver rules. I don't use macs so I can't tell you where they are. There was a similar problem reported here:


Bear in mind that ping probably resolves names differently than a browser does (this is the case in Windows). So check that your browser is actually using your local DNS and not using an external "private" DNS.
 
I was going to suggest that you check the contents of /etc/nsswitch.conf but I read that macos doesn't use that file. I'm not sure that's true so it might be worth checking anyway.

Are you using .local as your router's DNS domain (you shouldn't be). See this post for some potential issues regarding .local, DNS and mDNS.
 
Oh that's interesting RE the .local domain. I'm now thinking that i should start again and just use my actual domain name and reserve the subdomains for the local network. I'll try that now and see what comes up

RE the nsswitch.conf, it doesn't look to exist in /etc
 
So after changing both URLs to use something other than the local domain I can ping both and access them via the browser. from a little more digging it looks like OSX reserves the .local domains for some internal services which can cause some issues.

I'm now struggling with SSL for these custom domains on the local network, but I don't think that's a problem for here. Progress has been made anyway!, thanks for your help @ColinTaylor
 
dns-sd is the Multicast DNS (mDNS) & DNS Service Discovery (DNS-SD) test tool for MacOS.
dns-sd -q foo.local <---to get mDNS
dns-sd -q foo or foo.domain <---to get DNS
 
Seems that .lan is probably the safest bet these days for LAN side - .local has been reserved for years per IETF, and .home and .service have been set aside lately for matter...

Good info here that I do try to maintain over time...


With regards to AsusWRT - they have partial support for Avahi, but they are missing a component that would make life a bit easier for their avahi software, and that is libnss-mdns, which avahi uses for local lookups on mdns...
 
With regards to AsusWRT - they have partial support for Avahi, but they are missing a component that would make life a bit easier for their avahi software, and that is libnss-mdns, which avahi uses for local lookups on mdns...
https://github.com/lathiat/nss-mdns
libnss-mdns would provide only lookup (& caching) of hostnames in the .local domain unless you register hostnames with Avahi. The current mDNS seems to work fine without a central lookup & cache. dnsmasq already provides hostname lookup for single-label hostnames and multi-label hostnames within the LAN domain.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top