Hostname resolution without domain doesn't work

MOX hardware MOX HW problems
1

I just received my shiny new Turris MOX on Friday and was really looking forward to finally replace my old WiFi router with something awesome, but then I already spent almost a day by debugging why basic things doesn’t work:-(
I just wanted my DHCP clients to be able to connect to the internet and resolve local hostnames.
I finally found a way how to convince MOX to send DNS server to my clients (DHCP-Options
burried in advanced LAN settings), but I still struggle with the hostname resolution.
I managed to make it partly working by specifying search/domain in resolv.conf on the clients, but there are still clients that doesn’t work with this, namely my docker nodes running on raspbian.

On my previous router running tomato-usb firmware with dnsmasq, I was able to resolve local hostnames with or without specifying the domain, but MOX can only resolve them with the domain specified.
Is that some kind of limitations of kresd/unbound or whatever DNS server is used in place of dnsmasq, or is this just a bug in this alpha MOX firmware?

My system log contains lot of occurrences of the following error:

Feb 24 15:09:57 turris dnsmasq-dhcp[20356]: read /etc/ethers - 0 addresses
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 3: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 4: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 5: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 6: from: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 7: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 8: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 9: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 10: from: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 13: syntax error: unexpected “(”
Feb 24 15:09:57 turris dnsmasq[20356]: script process exited with status 2

Could this be related?

2

Yes, that’s apparently some mistake (?) in the script that transports names from DHCP server to DNS server.

The fact that you have to specify the suffix (.lan by default) is not a random bug – it’s how it is in Turris OS. (This one is not specific to MOX.) The usual approach is to do this from the client side, e.g. Linuxes often have the setting that if you don’t specify any dot in a name, the domain (from DHCP) gets appended. Browsers will typically refuse dot-less names anyway and use a search engine directly IIRC.

3

I see. Thanks for fast response!

Going through my old dnsmasq config, I think it must have worked thanks to “expand-hosts” option.

I just tried to add search line to resolv.conf on one docker node and restart docker daemon. It seems to fix the issue. Domain line is not enough, but search seems to be honored by docker and propagated to containers.

Now I just need to find how to convince MOX to send this by DHCP :wink:

4

Yep that is related. It looks like that python script is being interpreted by shell. This happens commonly if there is hashbang left out of script. Can you please post output of head /etc/resolver/dhcp_host_domain_ng.py?

5

head /etc/resolver/dhcp_host_domain_ng.py
#!/usr/bin/python

import subprocess
import sys
import syslog
from syslog import LOG_ERR, LOG_INFO, LOG_DEBUG, LOG_WARNING
import re
import socket
import os
from os import listdir

6

For this client-directed approach on unix-like systems I’d recommend looking into man resolv.conf

7

I created an issue for it and assigned it to appropriate developer. Please provide additional info if you are able to debug issue little bit more: https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/332

2 Likes
8

I saw, that the issue you created for it was resolved.
Is there a way to test it on my MOX?

9

Yes there is. Currently this fix is in hbk and hbd branch. You would have to switch your router to track one of these branches but be aware that those are development branches and that stuff might break if you use them. Switch can be done with command switch-branch.

We plan to release alpha3 at the beginning of next week so you might just wait for that if you want.

10

Thanks.
I may try that, but I doubt, that it will fix other issues introduced by the fact, that kresd is used as default resolver.
I already gave up and switched to dnsmasq, which unsurprisingly fixed all the issues…