Speedup local name resolution

Software SW help
1

Hi,

if I reboot my mox it sometimes takes a long time until all local names can be resolved again.
That means the device gets an IP address but the name is not known:

root@turris:/etc/config# ping -c 1 192.168.10.95
PING 192.168.10.95 (192.168.10.95) 56(84) bytes of data.
64 bytes from 192.168.10.95: icmp_req=1 ttl=64 time=0.540 ms

--- 192.168.10.95 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.540/0.540/0.540/0.000 ms
root@turris:/etc/config# ping omv.lan
ping: unknown host omv.lan

I can accelerate the process by rebooting the devices, which is something I want to avoid.

I understand that I can populate /etc/hosts, but then I would loose the advantage of dynamic assignment of IP addresses.

Is there a way to force the update of the name cache?
Or is there a way to “inject” a known name into kresd during runtime, so that I can at least make the most important servers reachable again?

This is configured in /etc/dhcp

config dnsmasq
	option domainneeded	1
	option boguspriv	1
	option filterwin2k	0  # enable for dial on demand
	option localise_queries	1
	option rebind_protection 1  # disable if upstream must serve RFC1918 addresses
	option rebind_localhost 1  # enable for RBL checking and similar services
	#list rebind_domain example.lan  # whitelist RFC1918 responses for domains
	option local	'/lan/'
	option domain	'lan'
	option nonegcache	0
	option authoritative	1
	option readethers	1
	option leasefile	'/tmp/dhcp.leases'
	option resolvfile	'/tmp/resolv.conf.auto'
	option nonwildcard	1 # bind to & keep track of interfaces
	option port '0'
	option serversfile '/tmp/adb_list.overall'
	option localservice	1  # disable to allow DNS requests from non-local subnets

config dhcp lan
	option interface 'lan'
	option dhcpv6 'server'
	option ra 'server'
	option ignore '0'
	option leasetime '3d'
	option start '32'
	option limit '100'
	list dhcp_option '6,192.168.10.1'

config dhcp 'guest'
	option interface 'guest'
	option dhcpv6 'server'
	option ra 'server'
	option ignore '0'
	option leasetime '3d'
	option start '32'
	option limit '100'
	list dhcp_option '6,192.168.70.1'

Thanks for your help.

Peter

2

I don’t know where exactly is the problem. I’d expect that shortening the lease time would shorten this intermediate state. (You can set it in LAN tab in (re)Foris.)

Yes, there certainly are ways, though I’m not sure which will be most practical for your case. I often use a command like

ssh root@192.168.1.1 -- socat - /tmp/kresd/control/\*

to get into interactive console of the resolver. In this read-eval-print loop I inspect status or just perform commands; it’s almost the same as adding lines to Knot Resolver configuration. In your case e.g.:

hints['example.lan'] = '192.0.2.33'

(all is non-persistent, until restart or reconfiguration)

3

Thanks, @vcunat , the socat example is exactly the injection solution I was looking for.

1 Like
4

Creating fixed DHCP reservations also solves this problem. kresd then knows the mapping immediately and can resolve the names right after reboot of turris.

5

Well, I’m not sure if that approach is applicable here:

6

There is still a large difference - /etc/hosts needs manual management on ALL machines in the network. Static leases require configuration just on the DHCP server and all the resolving works exactly the same as with true dynamic reservations.

I actually can’t think of any case where truly dynamic reservations would be a must-have (at least when talking about servers on local network). But let the OP decide whether static leases are an acceptable solution…

Is there actually a reason why the leases file and the DHCP-DNS mapping is not persisted across reboots? Theoretically, the router could be down for some time and you could use a different DHCP server in the meantime, so the loaded leases and mappings would not be valid after you plug the turris back, but this sounds really like a corner case…

1 Like
7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.