How to get CNAMEs with kresd - Answer: unable/no solution

I note that if I have the following in /etc/config/dhcp, then TO / kresd automatically integrates with OpenWrt / dnsmaq and I can resolve those hostnames:

config host
    option name 'lxc-nginx'
    option mac 'aa:bb:cc:00:01:33'
    option ip '172.27.0.133'

However CNAMES do not work:

config cname
    option cname 'real-domain.com'
    option target 'lxc-nginx.home'

I had a look at Turris Documentation, but there is no answer there. I also had a quick look in the init scripts, but nothing was obvious on a quick glance.

I must admit, I find TO’s insistence upon kresd to be the only frustrating thing about it. But it is very frustrating!

Maybe @vcunat, you may be able to help?

There is currently no direct support in knot-resolver to inject CNAMEs into the DNS locally.

@dbonnes If not mistaken unbound has local CNAME/DNAME capabilites/support and you are not tied to kresd.

However there is bit lack of documentation for unbound on TO. If you wish I could share/help with the setup, except perhaps for the local CNAME bit as currently not utilizing such.

One thing to note is that this would likely need to be a DNAME. CNAMEs for domains are not allowed.

You should be able to set up your own DNS file to include a custom file, but that’s a bit more advanced.

1 Like

I’ve had a quick google search for implementing CNAMEs in knot and found nothing.

You know what? I think I’m done with it. I have never seen any benefit from using Knot, and I’ve had heaps of problems with it - mainly very slow responses to DNS queries.

I’m switching over to dnsmasq and see how that goes…

[EDIT] CNAMEs work, as expected, with dnsmasq. For the benefit of others, this is what I did:

uci set dhcp.@dnsmasq[0].port=53
uci set resolver.common.port=5353
uci commit
reboot

It may have been enough to do the following with needing a reboot:

/etc/init.d/resolver restart
/etc/init.d/dnsmasq restart

And check with the following:

netstat -nltp

Sure. You can find a few people on the forum who use a similar setup and get some inspiration from there. Using dnsmasq for DNS isn’t officially supported on Turris, and consequently there tend to be occasional breakages on updates, but of course you can…

@vcunat : I am not sure if you’re displeased, and being sarcastic, or not…

I have used OpenWrt for many, many years, and I can say they have a different ethos to CZ.nic. I certainly need no ‘inspiration’ from anyone with regards to using dnsmasq over knot (although we will see what the next update does to my configuration).

I have participated in - and contributed to - the TO community, and really enjoyed TO as a product. I also like the idea of being a good netizen by contributing to your honeypot, etc.

However, I really feel the resolver - as implemented in the Omnia - still needs work. A lot of work. The fact is that it is slow, and it doesn’t provide/mirror the configuration of /etc/config/dhcp (which, for those who don’t know, includes dnsmasq’s DHCP and DNS configuration).

There are many posts in the forum to support this view. For me, the lack of CNAME support was the last straw.

I know that knot is CZ.nic’s pet creation, but you should think about things from your users’ points of view.

I’m sorry for not being clear. I don’t really have any feelings about it. I have more than enough work with people who are certainly interested in using knot-resolver (e.g. CloudFlare). If you prefer something else e.g. for CNAMEs or other reasons, that’s perfectly OK for me, though I won’t expend time to support it.

I meant inspiration in terms of solving related problems, e.g. some reported configuration resetting to kresd on larger upgrades, etc.

Btw may I ask what is the reason that TO team started to develop know and kresd and changed standard OpenWRT/LEDE standard in TO? In aspects should they be better and worth using them?

I’m not sure I understand the questions, but I was never on the Turris team itself, so I would better not try to answer anyway.

I see “Knot Resolver Team” beside your name. So I could put the question. Why have you chosen to make a team and product like that instead of choosing an existing one (like the ones used in vanilla OpenWRT/LEDE)?

We’re drifting away topically a bit. I wasn’t here when the knot-resolver project was started a few years ago, and it isn’t focused on routers/embedded (like dnsmasq), but I can write a few points as I personally see them.

First there weren’t many high-quality open-source full resolvers, probably just Unbound and venerable BIND. Dnsmasq is a special-purpose software, and it isn’t capable of working on its own AFAIK – it needs another resolver to forward to.

Therefore, similarly to knot-dns (authoritative DNS project), there was still space for another project to allow better diversity, which is good e.g. if you need to provide high guarantees, as nothing is without bugs. I also think it’s good to have a re-design every decade or two, as DNS is still quite changing.

@Fenevadkan

OpenWrt was/is designed to run on very low-spec machines, with relatively little Flash-ROM/RAM (like the routers you can buy from NetGear, et al). That is why OpenWrt uses dropbear instead of OpenSSH, and dnsmasq instead of (say) knot resolver (and so on). Even the busybox tools are modified to be smaller than ‘normal’ (and busybox was designed to be small).

Howeverr, the Turris Omnia has lots of Flash ROM/RAM and so you can pretty well run whatever you like…

In the case of DNS/DHCP, OpenWrt has for many years used dnsmasq, and that product has been dragged into the current age (e.g. the very recent addition of DNSSEC). It has the benefit of tight integration between DHCP and DNS. FWIW, it can be an authoritative (not a use-case for a SOHO/home router), or a caching-only relay.

For cz.nic, knot DNS came many years before the Turris project.

I am not 100% familiar with knot resolver, but I can confidently say it is pretty industrial. It can be an authoritative server, and you could comfortably use it if you were a TLD operator (and I assume that is the case for the .cz domain). I can safely assume it was never intended to run on a machine with (say) 4MB of RAM (although I am happy to be corrected on this point).

In short, dnsmasq and knot are coming from different directions and our TO routers are in the middle. I think @vcunat may well agree with me on this point?

Nonetheless (and IMHO), dnsmasq is a better fit for OpenWrt/LEDE, but others may disagree…

EDIT: some corrections…

1 Like
Two knots

I should just clear a few points. Public around Turris routers often fail to notice there are really two “knot” projects: knot-dns authoritative service, since 2010 (all years are just rough), and knot-resolver as recursive service, since 2014.

Original Turris routers started in 2013. In any case, I do not think Turris was a significant part of motivation to start knot-resolver.

Suitability for “small” devices

I agree both knot-* are primarily meant for larger usage, such as top-level domains and hosters (authoritative), ISPs and services like 1.1.1.1 (recursive). Still, they are written with efficiency in mind (in C), and required resources depend on the use case, e.g. knot-resolver on Omnia doesn’t take much RAM (~19 MiB in htop for me ATM), and on-drive requirements for libs aren’t too large either, so nowadays I’d say it’s theoretically usable even on lower-end devices than Omnia or MOX.

Has there been any progress with knot resolver in this since the last reply two years ago?

I have the very same problem as @dbonnes tried to solve. I use LXC container on Turris Omnia to host some services, say Samba and have a static IP and name associated with that, say “c1.lan”.

Now I need to configure knot resolver somehow to alias this name (either by CNAME or alias or any other means) as “samba.lan” so the fact that is hosted in a particular container is hidden as an implementation detail.

@vcunat: Is it possible to achieve somehow with knot resolver these days? I’ve went through the publicly available knot resolver documentation but it’s not clear.

Thanks in advance!

I believe CNAME situation hasn’t really changed since two years ago. Right now I am working on design changes that could allow it, but that’s not likely to be released soon.

If the address is static, why not just give the address to the name directly? That’s fairly easy, e.g. line like 192.0.2.4 c1.lan samba.lan in a hosts-like file: Turris Documentation

Hi Vladimir, thanks for blazingly fast reply, really appreciated!

Your solution actually works for me, although it’s not what I originally aimed for as my containers are getting the IP from DHCP and I have a reserved IP through MAC addresses for them. My bad, I shouldn’t have described that as “static”.

I can definitely live with assigning my containers and some other devices static IPs, but to answer the original question, now properly formulated - is there a way to achieve this for devices that get their names and IP addresses from the DHCP server?

I’ve seen kresd calls the /etc/resolver/dhcp_host_domain_ng.py when it starts through /etc/init.d/kresd start, so if the kresd itself can do it somehow, there is certainly a way to hook things up through this script, although it’s clear that I it’s not the best idea to modify it as it might get eventually upgraded from the new version of kresd package.

Thanks!

Yes, the script gets the names from DHCP. That’s c1 in this case – well if you could directly set the machine’s hostname to samba, it would just work on its own to bind the up to date IPv4 to samba.lan, but apparently you want to keep both of the names… which I can’t see how to do easily.

Yes, not using any alias is possible but it’s not an ideal solution for me as the point of using DNS entries (cnames, aliases or other means) as pointers to various services is enabling change of the underlying infrastructure without reconfiguring all clients using these services. The typical usecase would be moving samba from an lxc container to a raspberry pi, or setting up another container with samba to replace the original one and switching seamlesly when ready. This is just a standard enterprise approach I want to adopt in my home setup as well.

I could achieve this with configuring the IPs statically and use the hosts file, but static settings seem to be quite a significant overhead and a price I don’t want to pay.

I would normally have tried to replace the knot resolver with some other DNS resolver, such as unbound, but knot resolver seems to be tightly coupled to Omnia so the value is also not worth the risk here.

@vcunat - thanks for your confirmation that this is not possible with kresd. Do you see any chance of CNAME entries making it on the kresd roadmap? I understand it’s not that hot feature, but considering Turris is advertised (and priced) as superior router for fans and enthusiasts, it should support this feature. Cheers!

Yes, it is on current roadmap, as a part of other larger set of features/changes.