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'
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!
@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.
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:
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 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.
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ā¦
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.
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.
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!