TOS 6 issue with DHCP and internal DNS resolution

I’m trying to set up my Turris Omnia with multiple VLANs to segregate my internal network. To keep my network running during this migration, I took an older OpenWRT router that I had (Netgear WNDR3800), put OpenWRT 21.02 on it, configured all of the interfaces, firewall zones, and VLANs with my new network layout. Everything is working correctly on this router, and I’m using this as my production router while I figure out how to make this same setup work on my Turris Omnia.

I’ve managed to get VLANs with DSA figured out and I’m fairly confident that it’s configured correctly. However I’m having a bit of a show-stopper issue with DHCP and DNS. I’m using the default DHCP and DNS server that is configured with TOS6.

  • The first issue is that DHCP isn’t handing out any DNS info to clients. Clients are getting their own IP addresses correctly, but the DHCP response doesn’t include a DNS server. I can work around this by going into Interfaces → Edit → DHCP Server → Advanced Settings → DHCP Options, and set ‘6,’ (which is the IP address for the Turris Omnia). After doing that, the DHCP clients get the DNS server. It doesn’t seem like this should be necessary though, and my current OpenWRT router didn’t need this setting changed (nor did the TO when I was last using it, with TOS 5 and no VLANs).

  • Once I manage to get the DNS info to clients, the DNS server isn’t resolving internal hostnames. I can resolve public IP addresses (e.g. ‘dig @’, but internal hostnames aren’t being resolved. I have several internal hosts configured with static DHCP assignments.

I read that TOS doesn’t use the normal DHCP and DNS server used by upstream OpenWRT. I couldn’t find any logs for the DHCP and DNS server. Any suggestions for fixing this, or where I can look for more detailed logs and get more info on why it is failing?

I’m slightly tempted to try putting stock OpenWRT 21.02 (or maybe 22.03 RC1) on the TO since 21.02 on my other router is working fine. However I’ve seen in other posts that there are some kernel bugs being patched by Turris which aren’t upstream in OpenWRT. I also like the btrfs snapshot rollback feature in TOS.


1 Like

I’m not aware of difference in DHCP, but I don’t know these parts well.

DNS logs were separated to /var/log/resolver.

Sorry for the late reply. I haven’t had time to get back to this recently. I don’t have the log file /var/log/resolver. Is there some configuration needed to create this? I do see that kresd is running and is bound to port 53.

I was able to resolve the issue with hostname resolution for LAN devices. I had to log into reForis, go to “Network Settings” → “DNS” and check the box “Enable DHCP clients in DNS”. This resolved the issue with resolving my LAN hostnames. I didn’t expect to have to do this since I don’t normally use reForis to manage the TO.

I do still have the issue with the DHCP server not automatically handing out the DNS server to DHCP clients. I used the workaround in my first post of setting “6,” in the DHCP options (well actually I set it to the IP address for each different interface, so like ‘6,’ for the 192.168.10.x subnet, ‘6,’ for the 192.168.15.x subnet, ‘6,’ for the 192.168.20.x subnet, and so on).

Any suggestions for debugging this issue further?

When nothing is happening, nothing gets logged and the file isn’t created. More verbose logs can be triggered, e.g. this way, but it’s my understanding that now DNS itself works well for you and the issue is with configuring DHCP (which I don’t know well).

In case your *.lan names still don’t work well, there’s a script transporting names from DHCP to DNS; you can view its logs e.g. via command:

grep dhcp_host_domain_ng /var/log/messages

General advice: reForis is the main interface. If you bypass it, it’s assumed that you know what you’re doing, which apparently wasn’t so in this case. Especially for DNS it’s easy to get confused that luci settings don’t work, etc.