LAN hostnames no longer available? (Solved - sortof)

solved

#1

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:

The file /etc/ethers is empty.

As expected, the /tmp/dhcp.leases file contains lines like this:

1499935789 10:9a:fd:5f:0f:d9 192.168.2.30 esxi 01:10:9a:dd:5f:0f:d9
1499920730 28:6a:fa:bc:2d:e0 192.168.2.239 iPad2 01:28:6a:ba:bc:2d:e0

The /tmp/resolv.conf.auto file contains

search lan
nameserver 127.0.0.1

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.

Any pointers to what may be wrong?


#2

Hi fsteff,

maybe this one I wrote recently works for you too:


Short summary: Try to set DNS server port to 53 instead of 0.

Kind regards
ChrisPHL


#3

Hi ChrisPHL,

Just the medicine I needed! Thanks!!

I wonder how this value was changed, though!

It looks like both hostname and hostname.lan are now valid.

Thank you for your help!!!


#4

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?


#5

I just tested with netstat, and it appear port 53 is already services by kresd, so also setting DNS server port to 53 is bound to give problems:

:~# netstat -tulpn
Active Internet connections (only servers)
Preformatted text`Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      3247/kresd
tcp        0      0 :::53                   :::*                    LISTEN      3247/kresd
udp        0      0 0.0.0.0:53              0.0.0.0:*                           3247/kresd
udp        0      0 :::53                   :::*                                3247/kresd
udp        0      0 0.0.0.0:67              0.0.0.0:*                           23924/dnsmasq

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. :frowning:

So what is the right way of dealing with this???


#6

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.


#7

IIRC dnsmasq runs the DHCP protocol so it knows internally to add those names to DNS.


Doplnění DNS/DHCP dokumentace
#8

Yes it makes sense, this is probably how it is working.


#9

Thanks @vcunat and especially @X-dark,

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! :-/


closed #10