Getting confused by the DNS and hosts management on Turris

Software SW tweaks
1

This is what I understood:
We are using knot-resolver as a cache DNS “server”
We are using dnsmasq only as a DHCP server.
We should not use the LuCI interface.

knot-resolver is not doing a forwarding on dnsmasq for the local domain but directly importing data by a script.

Please correct me if I’m wrong. If everything is right then come my next question:
The init script of knot-resolver is loading the local address from the hosts file?

But then why not just doing a forwading to dnsmasq as it is anyway installed but pointed to another port so that we could “simply” configure dnsmasq for the local zone? That would be someway more clear as knot-resolver would act only as a cache server, without populating the hint file by scripting. And dnsmasq will continue to work “as usual” just keeping it on a different port.

I’m just trying to understand which is the more resilient and elegant way to manage a local DNS server avoiding to do to match tweaking on the default config.

2

This is what I do. But if you do this you will need to rearrange the order of things in kresd.conf. I can show my kresd custom.conf file when I.get back to a computer.

I think it allows for much easier local lookups than the default set up and a lot more control.

3

Nit: /etc/hosts is not loaded by default, I believe.

4

dnsmasq has DNS resolution disabled by default, not on different port.

knot-resolver can do resolving by itself, while dnsmasq forwards to upstream servers. This can cause issues if your ISP modifies DNS somehow.

Not by default, only if you explicitly configure it to do that.

That would make knot-resolver useless.

5

@fantomas
dnsmasq has DNS resolution disabled by default, not on different port.

Yes dnsmas is disabled by setting port=0 in the conf file. But it’s easy to change and have dnsmasq working, as an example setting port=5353 to avoid conflicts with the caching resolver.

@fantomas
knot-resolver can do resolving by itself, while dnsmasq forwards to upstream servers.

That’s partially wrong. knot-resolver is a caching resolver, it’s not a DNS server so it could resolve only once a DNS server told him how. And if you want a local DNS server you need to set a forwarding rule on knot-resolver. Quoting the documentation of knot-resolver:

In order to resolve internal-only domains a query policy has to be added to forward queries to a correct internal server. See Internal Resolver

@fantomas
That would make knot-resolver useless.

That’s wrong. It’s useless if you consider that you could get rid of knot-resolver and simply use dnsmasq as a replacement (as in OpenWrt btw). But that would lead to many unpleasant consequence on the management of your Turris; and there are certainly some advantages on using knot-resolver as the caching resolver.

Instead, if you consider that knot-resolver as been choosed for some good reason and that dnsmasq is already installed and running on your system, then enabling dnsmasq for local resolving and adding a forwarding rule to knot-resolver is a quite good choice.
That way you will have knot-resolver doing the usual work and you keep a working reForis interface. At the same time you will get a local DNS server that you could manage for your needs, and that just adding a forwarding rule to knot-resolve for the local resource. The local DNS server could even be on another host in which case dnsmasq would not be involved.

6

You should use a different port since this conflicts with another service (MDNS). I use 5300.

1 Like
7

I was wrong, I used port 5553, but no matter, as long as you pick a port that isn’t used for something else.

In any case, I wanted to paste my custom.conf for kresd:

policy.add(policy.suffix(policy.STUB('127.0.0.1@5553'), policy.todnames({'localnet.home.arpa','40.168.192.in-addr.arpa'})))
-- Allow reverse lookups
policy.add(policy.suffix(policy.PASS, { todname('40.168.192.in-addr.arpa') }))
policy.add(policy.suffix(policy.DENY, policy.todnames({'168.192.in-addr.arpa'})))
...
policy.add(policy.all(
       policy.TLS_FORWARD({
             {'1.1.1.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/ca-certificates.crt'},
...
             {'2001:148f:fffe::1' ,hostname='odvr.nic.cz' ,ca_file='/etc/ssl/certs/ca-certificates.crt' }
})))

I found if you have Turris set up for forwarding, the TLS_FORWARD section is put first before any part of custom.conf. So, even if you just have the section for forwarding your local lookups to dnsmasq but you have Turris set for forwarding, it wont send requests to dnsmasq.

So the TLS_FORWARD section is just copied from the version that Turris creates, but I pasted it after my local dnsmasq lookups. The other reason I wanted to use dnsmasq is local reverse lookups don’t work with the way Turris does things (at least that was the case the last time I tried it).

8

Well, OK if it works for you, but I’ll leave some comments…

That used to be true, but not for years already. So you shouldn’t need to complicate this anymore. The forwarding rules from reForis are still generated before custom code, but their execution order is after anything added by policy.add

Also, using .PASS on something that already chose .STUB doesn’t do anything, I believe (triggering a STUB action prevents processing any other rules).

9

Both dnsmasq and knot-resolver are DNS servers, providing DNS resolution fia DNS protocol for their clients, they just have a bit different functionalities.
While dnsmasq does not resursive resolution and relies on forwarding to upstream servers, knot-resolver can do recursive resolution and does it by default (it can be configured to do forwarding).

knot-resolver also supports DoT (DNS over TCP) and DoH (DNS over HTTP) as server and DoT as client.

Otoh, dnsmasq can be easily configured to provide local /etc/hosts (or similar files) via DNS, while configuration of knot-resolver to do the same is a bit more complicated.

I am using dnsmasq on port 53 on my turris for 2.5 years without problems. I have dropped knot-resolver because of some problems (e.g. with resolution of hosts in /etc/hosts)

I simply see and have no problems with using one single DNS server instead of using two stacked servers and I consider such configuration problematic, as tracing issues created by forwarding from one to another is more complicated than tracing issues with one.

Can you explain what real problems arise from this?

10

Blockquote
Can you explain what real problems arise from this?

Just taking some idea from the Turris Wiki

  • As soon as KNOT is no longer the resolver in use, nothing displayed on the reForis DNS screen is relevant. In particular, connectivity test results are no longer valid, and should be ignored. The DNS configuration can then only be done in LuCI (and on the command line).
  • In the version of Turris OS tested here (5.2.7), DNSMASQ was generating a storm of DNSSEC “Delegation of Signature” requests, causing name resolution to fail for some domains; a quick workaround, but not recommended, is to disable DNSSEC in LuCI (remember that the DNSSEC setting in reForis has no effect at the moment).
  • Finally, the use of DNSMASQ is not supported by Turris technical support. You are on your own.

Those are “real” problem? Probably not. So it is not to say that you should not follow that path. Just that probably it is not the best option if you want to keep a working integration with reForis in the long term.

And we are only asking knot-resolver to do a forwarding for the local zone, as you say dnsmasq can be easily configured to provide local resolution, while that’s not the case with knot-resolver.

To my view, switching completely to dnsmasq, is more invasive over the Turris standard settings than adding one custom forwarding rule and enabling dnsmasq on another port. In both case you will have to manipulate dnsmasq manually (or maybe with LuCI).

11

Time to play with this again. Anything to simplify my setup. Thanks.

12

…we need to explicitly know what exactly causes those problems, as they may happen when you forward to dnsmasq and result of using dnsmasq to forward queries, no matter if those requests went through knot-resolver before.

Until then, I see no reason to use knot and forward to dnsmasq or the opposite.

13

One feature I rely on in dnsmasq is the ability to redirect entire domains to arbitrary addresses, which I use to blackhole spam domains. Haven’t checked if knot-resolver also offers this feature.