Until recently, I was able to access my devices on my local lan using hostname.lan - but this functionality appear to have disappeared - probably in relation to the latest updates.
Various posts appear to indicate that hostname and hostname.lan should be equally useable, but in my case neither of them work.
In Static Leases I’ve tried to add hostnames as both mixed-case and as all lower-case (as an old post indicated this could be a problem) but this didn’t change anything.
Also hostnames from devices requesting an IP by DHCP, does not work.
I believe all my DHCP and DNS settings in LuCI are set to default:
When configuring my ESXi server to use DHCP, and configuring a static lease for it’s MAC address, I see that it’s able to get it’s hostname from the DHCP - but the hostname is not useable.
Attempting to use nslookup or ping -a to verify a hostname fails.
Unfortunately the fix had side effects, so I had to go back to have the DNS Server Port at 0.
My childrens iPads, and possible other devices (I didn’t test all), failed to get an IP over DHCP when the DNS Server Port was set to 53. The moment I changed it back to 0, they all started working -> for unknown reasons without my old problems returning.
But I fear it’s not for long, and I’d really like to get to the root cause of this.
I guess it has to do with startup-order, or perhaps some race-condition?
Last in this list is also dnsmasq, which is the tool which should be responsible for the DNS and DHCP section in LuCi. I find nothing running on port 0, which in understandable given the explanation of the usage of port 0:
Port 0 is a reserved port in TCP/IP networking, meaning that it should not be used in TCP or UDP messages. However, port 0 carries special significance in network programming, particularly Unix socket programming: for requesting system-allocated, dynamic ports. (lifewire.com)
So I find it safe to assume the running instance of dnsmasq on port 67 was the one destined to go to port 53.
So obviously during startup, there must be some race conflict as to which process get port 53. And the bit question is, why is kreds even running? Can it just be shut off?
Well, attempting to check up on the forum, just made this more confusing; How-to-configure-local-address-dns-resoultion-on-omnia and also Dnsmasq-lan-domain-while-still-using-knot-resolver explains a lot, and on several points looks resolved - untill you read the next comment.
There is 3 available DNS resolvers on your Turris: dnsmasq, kresd and unbound. Only one of them is needed and may listen on the port 53 at a a given time.
Have a look at /etc/config/resolver to see wich one is set as your preferred one (kresd is the default).
Whichever resolver you choose, you should get .lan resolution working:
For unbound, have a look directly in /var/etc/unbound/unbound.conf, you should see a local-zone section
For kresd, there is a /tmp/kresd/hints.tmp file generated when the server start
For dnsmasq, not sure where the file is I have not tested
However, dnsmasq is also used for dhcp. It should definitely listen on port 67 for this to work. But the “option port” is not for this but for DNS. In other word, you may keep “option port 0” if you do not want to use dnsmasq as DNS, and DHCP should work.
Just back from a few vacation days, and are now catching up.
Your explanation makes sense - but isn’t really intuitive. Would be nice to have it all in a GUI somehow - instead of just a fraction of it.
However, I have things working now, and it appear to be stable - also after the latest update.
I still don’t know why it failed first, nor why DHCP fails on iPads (It was working on an iPhone and a few android phones) when the DNS Server Port was set to 53.
What I do know is that after changing the DNS Server Port from 0 to 53, rebooting, then setting it back to 0 and rebooting again, appears to have fixed something - I just have no clue what! :-/