Kresd does not honor the expandhosts config option

I am trying to add a new domain name for the router to kresd config. I am using the hbt testing 5.0.0 branch.

So, in luci I went to Network -> Hostnames. I added “dc0.ds.example.com” with an ip address of 192.168.6.1 (my router’s lan ip).

Now, I can resolve “dc0.ds.example.com.lan”, which include the “.lan” tacked on for a local domain. I want to remove that.

So, I proceed to Network -> DHCP and DNS in Luci. I select the “Advanced Settings” tab. I uncheck expand hosts. I save and apply the change.

Unfortunately, the kresd init script does nothing different in that case. According to the description of the option on here, I believe that should remove the “.lan” part.

So, I started digging a bit further. I noticed that the kresd is configured put the static hostnames into /tmp/kresd/hints.tmp. However, if I look in the kresd init script (/etc/init.d/kresd), I can see that it just dumps names with the local domain appended without looking at the expandhosts setting.

Would it make sense to change this so that expandhosts changed the values written into /tmp/kresd/hints.tmp. My hints.tmp looks like this:

192.168.6.1 dc0.ds.example.com.lan

I would prefer that is look like this when expandhosts is set to 0:

192.168.6.1 dc0.ds.example.com

I can definitely write up a change for this if this is acceptable. However, I have a few questions about the gitlab instance.

  • How do I find the ssh fingerprint? I would like to verify it when I go to clone the repo via ssh.
  • How do I fork? Seems I cannot do that even after logging in?
  • I assume this is the same answer as the previous, but how do I create a merge request?

The LuCI settings are referring to dnsmsaq settings, there are no options for kresd in LuCI. Then the resolver-conf package provides the glue script /etc/resolver/dhcp_host_domain_ng.py for providing reverse DNS records to kresd.

Did you notice those dnsmasq settings?

See docs: https://doc.turris.cz/doc/en/public/dns_knot_misc
Section „Adding static address records“

This is not entirely true. Some of the options in /etc/config/dhcp are honored in kresd (namely the local domain name and the config domain stanzas). Shouldn’t we strive to support more config option for compatibility? I also wonder what the feasibility of reworking the luci support so that it doesn’t show options that are irrelevant for kresd and add options relevant to kresd.

Thanks for that link. I hadn’t come across that.

Unfortunately you can’t – gitlab.labs.nic.cz won’t allow users to create projects by default (and for GitLab, forking is creation of a project).

The linked openwrt docs describe the option as something else than you actually want, according to my understanding at least:

Add the local domain part to names found in /etc/hosts

and the default Turris set up won’t even add /etc/hosts items into the served DNS.

As noted, you can add custom bindings relatively easily. Foris GUI also allows you to change the lan suffix to something else, but not remove it because splicing any DHCP names directly into the top-level DNS doesn’t seem like a good idea.

Actually, this might interest you if I understand it right. The domain option in dnsmasq is served over DHCP and some clients then try to append it to DNS names when they search for them (depending on their configuration and circumstances like the number of dots in the name). Dnsmasq: customize search domain

My main problem is that the luci interface has a lot of options that don’t do anything when using kresd as the resolver. I think this is super confusing for users. I basically think that dhcp and dns options need to be reorganized so that the make sense no matter which implementation is being used for each service. I think this means that common options need to separated from options that are different for each implementation. I am not sure yet was that would look like in my mind.

Yes, we know it’s confusing, but so far I haven’t heard of a “nice solution”. I don’t know how luci works, but it seems clear that this would require the Turris team to maintain a fork of some parts. So far the approach has been that luci is meant for advanced users and those are expected to know a bit what they’re doing; anything commonly needed should get exposed by (re)Foris.

Well, you could put a warning onto the (re)Foris DNS configuration page that LUCI’s DNS settings will not be honored (or list those that are honored explicitly). Does not fix the issue, which might be too hard, but at least would warn the TOS users, without the need to change anything in luci?