knot violates the “be liberal in what you accept from others and conservative in what you give” credo by principle and thus i dont think it is fit for non-professional use.
could you please elaborate on the why?
You may want to know that it’s used professionally (IIRC, Cloudflare).
Yes. One thing is that dnsmasq is in reality only forwarding to forwarding resolver. Meaning that it is able to only forward to some other forwarding resolver. It is unable to contact root DNS servers on its own. This simplifies its design of course and allows its developers to do some shortcuts such as reliance on upstream forwarding resolver for DNSSEC root verification and so on. Problem is that in most cases those upstream resolvers are missconfigured in such a way that such setup and reliance compromises DNS resolving. You can solve that with forwarding to some other resolver server such as for example 1.1.1.1 but in case of dnsmasq there is no forced verification that this server is really providing you with valid DNS responses. Anyone on path to forwarded server can hijack its address, well at least in default configuration of dnsmasq. This is not theoretical attack. This attack already happened and cost some people a lot of money in cryptocurrency. Knot-resolver gives you possibility to not rely on some upstream DNS server it can directly contact root DNS resolvers. It also enforces DNSSEC authentication and that way ensures that even if you are forwarding that forwarding server was unable to change DNSSEC signed domains. This is not just some exercise in security. If someone hijacks your DNS upstream resolver it can replicate our old version of packages server with known vulnerabilities. Router in such case has no idea that something like that is happening and can downgrade packages and that way expose known vulnerability and open itself to attack.
Second thing is my own feel that dnsmasq violates Unix philosophy “do one thing and do it right”. Having both DHCP and DNS in one program opens you to various theoretical attack such as denial of both services by attacking just one of them or exploiting one service by penetrating other one. If you found a way to hijack DHCP it in general would allow you to just control dhcp, in case of dnsmasq it could also give you possibility to control dns.
I think that this credo violates basic security principles. Being liberal most of the times means opening self to attacks. I am not saying that it is completely wrong, I am just saying that it can’t be applied without considerations and should not be the primary credo.
4 Likes
If you’re more concrete, we might be able to fix it, but please write that into a separate thread and mention me. This thread seems more suitable for those who already know for sure that they don’t want knot-resolver/foris/…
There’s probably no single choice that can satisfy completely everyone. I’m clearly biased; one example use case is the TLS forwarding, which should be clickable in upcoming Turris 3.11.
If you have a perfect ISP (quality, security, trust), I agree you might not perceive much advantage in comparison to using their DNS directly or through a simple cache (like dnsmasq).
2 Likes
minute of silence for the poor blockchain nerds.
srysly?
if i own your dhcp i can do a lot more then mess with your dns.
agreed, yet the internet is built on it.
touche` i have not yet encountered may instances of problematic lies in dns apart from a holiday in france 
i dont think dnssec or the implementation in knot is the problem here, just that its not fit as a default. not even for prousers or enthusiasts.
@einar: yes
Yes but only to hosts with dynamically assigned IPs. You won’t do too much to static configuration and in most networks statically configured hosts are high value targets such as servers.
Internet is also a place where anyone with access to computer on top level Internet can announce malicious route to any other host and redirect complete ranges to different locations just because it is common to have peering configured to propagate even unsigned routes because what if they are valid. Just because it works it does not means that it is right and that there is no possible improvement.
I think that this is way out of topic now so let’s stop here.
As I wrote I have nothing against credo you wrote. I just don’t think that it should be honoured more than security but during this argument I completely ignored knot it self. I don’t think that kresd developers violates it. You might be wronging them. DNS is not easy. Just reading RFCs is monumental task and when you go to real world you found out that almost nobody read them. DNS resolvers are full of hacks just because someone in some application implemented DNS client with its own quirk that is surprisingly nowhere to be found in RFCs. There are maximal sizes of respond packets and even various parts of sectors in those packets. @vcunat can definitely speak more in depth with precise examples. If some device does not work with kresd then it is most probably bug and should be reported to kresd developers. It is not because they decided to violate credo you pointed out. That is also one of the reasons why @vcunat is so active here.
4 Likes
If the main issue is that dnsmasq can’t contact root servers directly, then the logical solution is to also run knot locally, and have dnsmasq forward queries that it can’t resolve via dhcp names or static config to the knot server - not the other way around. Maybe this is how it’s configured by default now, in which case I’ll give it another try.
Sure, dnsmasq is a violation of the Unix philosophy, but practicality beats purity. Some monolithic software is awful (such systemd, or Windows in general) but others are great - for instance, ZFS is far better than any other filesystem+RAID without shelling out tons of money for specialized storage hardware. dnsmasq is far simpler than trying to get a DHCP and DNS server to talk to each other. I’ve done that before with BIND and DHCPD, and it was not a fun process. This is definitely a scenario where it makes sense to throw the Unix philosophy out the window in favor of less moving parts.
1 Like
No. There’s a script that obtains data from dnsmasq and feeds them into the resolver (kresd on Omnia, unbound on Turris 1.x).
Having all DNS queries go through two resolvers doesn’t feel a right default, though it shouldn’t be difficult to configure. What’s reasonable (and I’ve seen it on the forum): let the resolver forward some DNS queries to dnsmasq, primarily *.lan (or the domain you choose instead of that).
Slightly off topic, but this isn’t actually true, is it? Relying on DNS for security doesn’t seem very wise. AFAIK debian and probably others have protection against rollbacks and excessive update delays while still using http. At most one could slightly delay or (visibly) DOS updates.
Generally speaking, in most cases there’s some other layer that will save you (TLS is typical), and in many cases you do need such a layer – securing correctness of addresses won’t really help against some attackers (e.g. your ISP).
I’m personally not really aware of any DNS queries regularly done from common user machines where the correctness of the answer is that important from security point of view. Exception: poisoning name server addresses would make it possible to redirect all DNS queries to attacker’s nameserver, causing privacy leak and simplifying further attacks. DANE/TLSA might have been a very important “exception”, but apparently browsers don’t feel like using it. (I believe the usual certificates (DV) are significantly less secure than TLSA with DNSSEC, but…)
The idea of serving outdated packages is an interesting one. I haven’t verified that, but it seems easy to forget to check whether the information about the latest version is sufficiently new. (Traditional signatures have validity much longer than it takes to exploit published bugs.) For off-path attackers I expect it’s more difficult to DoS the updating process than to poison traditional non-validating DNS.
Would it be at least possible to support the configuration mattventura is talking about?
I completely agree with his statement, that in case you really feel, that dnsmasq is not fit for the job of secure DNS resolver, then knot-resolver should be used locally as the “gateway” for dnsmasq.
By doing this:
You are doing precisely what mattventura described in his post as really bad practice:
I do understand your standpoint here:
But the issue is, that by doing what you propose (to forward some DNS queries from kresd to dnsmasq), you are only trying to overcome the fact, that knot-resolver is not fit for the job of local home LAN DNS. What is worse, it doesn’t fix the issue either.
The reasoning, that cynerd describes in following posts is 100% real in corporate networks or networks of bigger scale, but especially the second part with “statically configured hosts as high value targets” is irrelevant for SOHO networks…which Turris routers are mostly designed for I guess.
Here is my view on this and why I strongly think, that knot-resolver, even though probably great DNS resolver for ISP and backbone networks, is not fit for serving a DNS role for SOHO network:
After 15 years of managing SOHO networks and using all sorts of SOHO routers from various vendors, almost always flashed by community firmware like OpenWrt, DD-WRT or Tomato, I have yet to encounter a single one, that would give me a single issue with DNS resolving or DHCP. All were 100% working without issues with rock solid reliability in this regard.
But since my MOX arrived some three weeks ago and replaced one of such routers in my home network, I am still struggling with DNS and hostname resolution and even DHCP didn’t work out of the box. I am still finding new things, that doesn’t work and trying to fix them or workaround them, as some do not have a fix…
Today I was fixing my Smart home system, which was not communicating with some of my security cameras, as it doesn’t use local domain to resolve local hostnames (and I had hostnames there, instead of IP addresses, as it always worked on any previous router).
My docker swarm cluster is also still broken, as inside the cluster it uses just hostnames without any domain to resolve other containers and as these containers provide services and communicate with things in LAN, all containers and devices were using just simple hostnames without domain and everything worked. Not with MOX…
Yesterday I finally found, why I am unable to connect to my tablet using hostname. The catch is, I do have a docking station with ethernet adapter for it, and I have static DHCP defined only for ethernet, not for WiFi. With dnsmasq as DNS, this was not an issue, as it was aware of which DHCP clients were active and returned correct IP. So when the tablet was on WiFi (most of the time), it returned it’s dynamically assigned IP and when it was on ethernet, it returned that IP. But knot-resolver always returns that static DHCP defined in a router, even though the tablet was not connected through that interface a single time since I switched to MOX from my old router…
I do also have a reliability issue with knot-resolver, not just feature one: When I enable DNSSEC and let the router test, whether it works OK, I do get two green ticks. But then my DNS resolving of external hostnames randomly doesn’t work. I am not sure, whether it is that it doesn’t work for some hostnames/domains or whether it just has hiccups, where it sometimes work and sometimes not. I honestly didn’t invest much time into debugging it, as I discovered it after two weeks of trying to workaround different issues in my network, caused by MOX. So I went and disabled DNSSEC (yes, not proud of myself, but it now resolves external DNS reliably).
I bet that all SOHO routers, I worked with before, had one thing in common, all used dnsmasq for DHCP and DNS and even though it is probably not as secure or performing as knot-resolver, it is rock stable, reliable and provides all the expected services that small local LAN needs, which is obviously something knot-resolver can’t do.
It is important to say, that it is not it’s fault. Most probably it was just never designed for such role.
So please, even if having two DNS resolvers in the router doesn’t look as a great default to you, give us at least the option to have it configured that way.
Considering how many Turris routers will serve in SOHO role, where knot-resolver is suboptimal, versus how many of them will serve as some line routers in ISP or corporate networks, where knot-resolver feels right home, I would say that having dnsmasq, as the piece of SW serving all the needs of local LAN clients, would be much better default option, than what we have now.
ironically because of knot, i have often seen omnia/mox beeing reffered to as “the home-router made by a dns-company that will fuckup your dns”.
seems to me the kids are more into dns-over-https anyways these days…
1 Like
Unfortunately that seem correct:-(
Looks like I didn’t do my due diligence before ordering the MOX…
Fortunately it really turned out to be easy switching to more sane setup of having dnsmasq as local DHCP + DNS and forwarding all requests for external hostname resolution to knot-resolver:
- Move kresd to free/unassigned port
uci set resolver.common.port=‘40’
uci commit resolver
service kresd restart
- Set dnsmasq as DNS resolver and make it use kresd as upstream DNS
uci set dhcp.@dnsmasq[0].port=‘53’
uci set dhcp.@dnsmasq[0].server=‘127.0.0.1#40’
uci set dhcp.@dnsmasq[0].noresolv=‘1’
uci set dhcp.@dnsmasq[0].dhcpscript=‘’
uci set dhcp.@dnsmasq[0].dnssec=‘0’
uci set dhcp.@dnsmasq[0].dnsseccheckunsigned=‘0’
uci commit dhcp
service dnsmasq restart
As all these changes are done using uCI, it shouldn’t get overwritten during updates and even if yes, it should be easy to fix.
Originally I didn’t disable dnssec in dnsmasq, but with it enabled I was getting timeouts for dns queries, as it took kresd really long to answer. Often longer than 2s which seems to be default timeout for clients.
It would be great, to offer this setup as an option in Forris/LuCI, as dnsmasq is definitely better option for small local network.
My network finally works again. Yay! 