Change standard DNS server for Turris Omnia itself

xturris · January 11, 2025, 8:35am

Hello everyone,
I would like to change the DNS servers of Omnia Turris myself. I have noticed that the settings in reForis in DNS Section only affect the clients that are connected to the Turris. The Turris itself uses the DNS servers of my provider according to the Luci Dashboard.
I have not found any other way to change the DNS servers as in “Luci - Interface - WAN”.
If I uncheck “Use DNS Server advertised” in the “Advanced Settings”, I can enter my desired DNS servers.
When I do this, I can also see the change in the Luci Dashboard.

My question is, this is the right way now to change the DNS servers?

First I had entered the DNS servers from Quad9 and then the update of the software in Luci “Software” no longer worked, I got wget 4 errors.
However, the Quad9 servers should be able to resolve the OpenWRT repositories in my opinion.
I was very surprised and thought I had done something wrong. Now I have used other DNS servers and everything works. Now I no longer have the DNS servers from the provider and it’s actually just as I wanted.

moeller0 · January 11, 2025, 11:12am

By default turrisOS uses knot which is not integrated with the luci GUI, so this needs to be configured in re-foris:
under network → DNS: click the “use forwarding” button, then select the desired pre-configured forwarder or click the “Add custom forwarder” button.

The luci dashboard does not know about knot and its configuration, so can not be trusted for turris OS. I would run a standard test at:
https://dnsleaktest.com/results.html
This will return your own pblic IPv4 address if turris is using knot without forwarding or the address of the configured forwarder.

But that primarily affects what the dashboard reports, which only matters if you use a DNS server configured in luci. (Sidenote, it would have been nice if the knot configuration had also been included in luci, but I have no idea how much effort that would be and guess team turris made an acceptable trade-off)

I would say no, do it in reforis, if you want to keep using knot.

xturris · January 11, 2025, 11:45am

Hi @moeller0,
First of all, cool that you give me an answer in this case here because I wanted to give you feedback on “our” other topic but since I marked it as solved it was no longer possible there…
Turris Omnia Wifi 6 and Telekom Glasfaser Modem 2
I have now fully implemented the topic and the telephony works perfectly with a FritzBox 7272.

Now to the topic here, I have to ask again …

What have I set so far:
I have selected a different DNS provider in reForis. My clients that have set Turris as the resolver all show this resolver on dnsleaktest.com… so everything is fine for the connected clients.

But I have just noticed in Luci Dashboard that the provider DNS is listed there. So I looked in the shell on the Turris in /etc/resolver.conf and it actually contains the provider DNS. Therefore I assume that Turris itself uses these DNS.
If I then make the custom DNS entries in Luci as I described above with the setting in the WAN interface, the desired DNS servers are in the resolv.conf.
If I then do a test in the shell with nslookup or in Luci via “Diagnostic” it looks good, my custom DNS servers are there.
So it actually looks good or do you say I should leave it because Turris uses other DNS servers via “knot” anyway?
If I leave it like this, will the Turris no longer use “knot”?
Actually everything works now except when I use the DNS servers from Quad9.

moeller0 · January 11, 2025, 12:27pm

Great, that is as far as i had tested this myself, before replying…

Mmmh, so I see the same in dashboard… (but as I said that seems benign), however as i neber tried to change the DNS settings in luci I see:

root@turris:~# cat /etc/resolv.conf 
search lan
nameserver 127.0.0.1
nameserver ::1

(I have no /etc/resolver.conf, but I guess that is just a typo or typing from memory).

However /etc/resolv.conf does not change with changing the setting in reforis…, so well possible that the router itself does not take the setting from reforis, I hope that I can ask one of the turris DNS experts to enlighten us, @vcunat could you please resolve this question for us (pun intended)?

I honestly do not know exactly. I was under the same assumption as you that changing the reforis setting would affect knot as well, but trying dig www.heise.de +trace is exactly the same whether I use my ISP’s forwarder or wether I have knot as recursive resolver… but maybe dig ... +trace does not actually do what I believe it does.

milkandhoney · January 11, 2025, 5:53pm

+trace does the opposite from what you want it to do.

It bypasses any local resolver and does everything by itself querying only authoritative server and no resolvers, starting from the top at ., going down to .de and heise.de and so on.

Just do a normal dig and look for the line starting with ;; SERVER: in the answer. That is the one who answered your query.

dig www.eff.org | grep SERVER
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)

milkandhoney · January 11, 2025, 6:09pm

/etc/resolv.conf tells the operating system which resolver to query.

On Turris and also most modern Linux systems nowadays that will always be 127.0.0.1.

Since you have a local resolver running, which is Knot on Turris or dnsmasq on OpenWrt or can be unbound or whatever your system is running.

The OS will use that as same as any DCHP client on LAN. If you want to know which upstream resolver your local resolver is using, take a look at your local resolvers configuration.

On Turris running Knot Resolver this would be /tmp/kresd.custom.conf.

moeller0 · January 11, 2025, 6:29pm

Thanks, what I wanted is to see the full sequence starting with the local DNS server, but as you said dig went straight to the root servers… I confused that with kresd which in my case acts as recursive resolver should do the exact same (for non-cached addresses, at least that is my assumption, which might as well be wrong ).

if I do this I always see 127.0.0.1, but that does not tell me whether knot is acting as recursive resolver or whether it dutifully queries the forwarder configured in reforis. Note I am quite happy with knot running as recursive resolver as I am not particularly fond of my ISP’s DNS servers.

recursive:

root@turris:~# cat /tmp/kresd.config 
--Automatically generated file; DO NOT EDIT
modules = {
    'hints > iterate'
  , 'policy'
  , 'stats'
  , predict = { window = 0, period = 0 }
}
hints.use_nodata(true)
policy.add(policy.rpz(policy.DENY, '/etc/kresd/adb_list.overall'))
hints.config('/tmp/kresd/hints.tmp')
net.listen('0.0.0.0', 53, { kind = 'dns' })
net.listen('0.0.0.0',   853, { kind = 'tls' })
net.listen('::', 53, { kind = 'dns' })
net.listen('::',   853, { kind = 'tls' })
trust_anchors.remove('.')
trust_anchors.add_file('/etc/root.keys', true)
net.bufsize(1232)
net.ipv4=true
net.ipv6=true
cache.open(20*MB)
user('kresd','kresd')

forwarded to ISP’s DNS servers:

root@turris:~# cat /tmp/kresd.config 
--Automatically generated file; DO NOT EDIT
modules = {
    'hints > iterate'
  , 'policy'
  , 'stats'
  , predict = { window = 0, period = 0 }
}
hints.use_nodata(true)
policy.add(policy.rpz(policy.DENY, '/etc/kresd/adb_list.overall'))
hints.config('/tmp/kresd/hints.tmp')
net.listen('0.0.0.0', 53, { kind = 'dns' })
net.listen('0.0.0.0',   853, { kind = 'tls' })
net.listen('::', 53, { kind = 'dns' })
net.listen('::',   853, { kind = 'tls' })
trust_anchors.remove('.')
trust_anchors.add_file('/etc/root.keys', true)
net.bufsize(1232)
net.ipv4=true
net.ipv6=true
cache.open(20*MB)
table.insert(policy.special_names, { count = 0, cb = policy.all(
policy.FORWARD({
	'62.109.121.2',
	'62.109.121.1',
	'2a01:c30::531',
	'2a01:c30::530',
}))})
user('kresd','kresd')

Thanks a lot, that was quite educational. Tl;dr: turrisOS honors the forwarder settings in reforis for clients and for the router running turrisOS.

vcunat · January 11, 2025, 8:15pm

I think it just works. I believe Turris has (basically?) no changes to luci from upstream. And luci just doesn’t know about Turris modifications, e.g. about the way that DNS is done differently.

Generally, if you use luci, you should know what you’re doing. There’s reForis if you don’t.

xturris · January 11, 2025, 10:50pm

I’m sorry but I don’t understand it yet.
I don’t see 127.0.0.1 anywhere like you do.

What I do in reForis is to set the Quad9 server in “DNS”.
If I leave everything in Luci as it is by default, then my /etc/resolv.conf contains the DNS server from the ISP.

cat /etc/resolv.conf 
# Interface wan
nameserver 217.5.100.185
nameserver 217.5.100.186

I then enter my custom DNS in Luci on the WAN interface as described above:

Then exactly these servers are listed in /etc/resolv.conf.

cat /etc/resolv.conf 
# Interface wan
nameserver 5.1.66.255
nameserver 185.150.99.255

Here is my dig output:

dig www.heise.de | grep SERVER
;; SERVER: 5.1.66.255#53(5.1.66.255) (UDP)

Here with trace option, I can also found my custom DNS server there:

dig www.heise.de +trace

; <<>> DiG 9.18.24 <<>> www.heise.de +trace
;; global options: +cmd
.			14404	IN	NS	e.root-servers.net.
.			14404	IN	NS	a.root-servers.net.
.			14404	IN	NS	j.root-servers.net.
.			14404	IN	NS	g.root-servers.net.
.			14404	IN	NS	l.root-servers.net.
.			14404	IN	NS	c.root-servers.net.
.			14404	IN	NS	k.root-servers.net.
.			14404	IN	NS	b.root-servers.net.
.			14404	IN	NS	i.root-servers.net.
.			14404	IN	NS	d.root-servers.net.
.			14404	IN	NS	h.root-servers.net.
.			14404	IN	NS	m.root-servers.net.
.			14404	IN	NS	f.root-servers.net.
.			14404	IN	RRSIG	NS 8 0 518400 20250123170000 20250110160000 26470 . MuUwkK7YHpJAu4frvRLM+RE7TBiC2RAq5A5f57vMBvdsgxvuWgZZgo3W mIRw+5SFzg0TF8Pj61GhEgXEg/ceiFTp2qZZGwtddk/tfvXr83hAMj4T Qd9Aq8a4KapN8C/OqaQs/L7cEQUyLR4kUmLyZ3A/zkQ3EE8miLlmY15I 2eZEi4w1mLx7t9elPibc9XjEhj0RIR/Fy4nyTXc/DWxT/UHFkez0KpeZ ksQmJBasVGxLSck1cKL8xKzTfp4DM1BJLPi1ItDDRN2p7E5JaoEFfsm3 ri6XDCGugpNlxnXNIPAoiKOoYyqWSApGy3//dhhpHx6JDuWplMO+h8oU Y0luNw==
;; Received 525 bytes from 5.1.66.255#53(5.1.66.255) in 10 ms

de.			172800	IN	NS	l.de.net.
de.			172800	IN	NS	z.nic.de.
de.			172800	IN	NS	a.nic.de.
de.			172800	IN	NS	f.nic.de.
de.			172800	IN	NS	s.de.net.
de.			172800	IN	NS	n.de.net.
de.			86400	IN	DS	26755 8 2 F341357809A5954311CCB82ADE114C6C1D724A75C0395137AA397803 5425E78D
de.			86400	IN	RRSIG	DS 8 1 86400 20250124170000 20250111160000 26470 . CeL5xwb6fS+ktDT97m/0mxKizNSY4zuxn/UDdpsASLOd9NPp6pTMR8et mhu5c8EV5zk0bWdeIaIW6iP1FKLj+tGgwSkvp1KqIspMp7IM7jgQFG3s jsO4C8X+rS7oFX2a4XtHkNHpTH6slUhRqhSnw1pYjI/GabEGiaREWoLg 0TwrUKkWKSSOWoiPvRP5nNZVd24dvc2+nqts85ik3svWb7g4aGTWfLbJ OsHLxk5liUln3vkbmdTNDxEr87kYX908RoH1GHdhU3d7Ugt5HG4tpP68 i5Bp2IFb4lw3Q85gf/PaSUqfnjKmFDipzQSWJ7d3UMS04S+lc91ow7S7 sJXK1Q==
;; Received 778 bytes from 192.5.5.241#53(f.root-servers.net) in 0 ms

heise.de.		86400	IN	NS	ns2.pop-hannover.net.
heise.de.		86400	IN	NS	ns.pop-hannover.de.
heise.de.		86400	IN	NS	ns.s.plusline.de.
heise.de.		86400	IN	NS	ns.heise.de.
heise.de.		86400	IN	NS	ns.plusline.de.
tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. 7200 IN NSEC3 1 1 15 CA12B74ADB90591A TJLCSJAT4LJTVO0TJNCRRDF6KF6ONEFB NS SOA RRSIG DNSKEY NSEC3PARAM
tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. 7200 IN RRSIG NSEC3 8 2 7200 20250122104255 20250108091255 63483 de. Di3Ng8BJ9GKixVJgxwMlJgsCLay/13GxMj4bjr1i8S0e21A7iTaa/TXG QCPNnHJXXPbncRIXkCENtri998s5zw3BvDrY0EcZbCbhigP35nJE4z59 LVUrPu0MoFfamCDwd/6hHcC6X3xx1NgaPKI81myQHaUuYiMkoCDKMH25 roQ=
ga624qcvfdcrth24fblomo7j82lsvu0v.de. 7200 IN NSEC3 1 1 15 CA12B74ADB90591A GA6325GEF7724RVDDS4A1DV460UM3GEE A RRSIG
ga624qcvfdcrth24fblomo7j82lsvu0v.de. 7200 IN RRSIG NSEC3 8 2 7200 20250122104255 20250108091255 63483 de. NSSfw+mN2F4Ul9GkL4GmcjJT6DdT6Mfd55j9EBuvSoAn6OKKCaLPa6Gr 1EjnHYRI+Vza6C0U01vMw+ztAi8BScnRdWiNmpGEKRnpWAWSqp96ip/f BgijvoFNKF9IjqKnmcVBr6tseJmvKzIjCVPh6k3YIvq8TaDudgnNjYxO xxM=
;; Received 859 bytes from 194.246.96.1#53(z.nic.de) in 10 ms

www.heise.de.		86400	IN	A	193.99.144.85
heise.de.		86400	IN	NS	ns.pop-hannover.de.
heise.de.		86400	IN	NS	ns.heise.de.
heise.de.		86400	IN	NS	ns.plusline.de.
heise.de.		86400	IN	NS	ns2.pop-hannover.net.
heise.de.		86400	IN	NS	ns.s.plusline.de.
;; Received 343 bytes from 212.19.48.14#53(ns.plusline.de) in 10 ms

The file /tmp/kresd.custom.conf does not exist for me.
Here is my /tmp/kresd.config:

cat /tmp/kresd.config 
--Automatically generated file; DO NOT EDIT
modules = {
    'hints > iterate'
  , 'policy'
  , 'stats'
  , predict = { window = 0, period = 0 }
}
hints.use_nodata(true)
policy.add(policy.rpz(policy.DENY, '/etc/kresd/adb_list.overall'))
hints.config('/tmp/kresd/hints.tmp')
net.listen('0.0.0.0', 53, { kind = 'dns' })
net.listen('0.0.0.0',   853, { kind = 'tls' })
net.listen('::', 53, { kind = 'dns' })
net.listen('::',   853, { kind = 'tls' })
trust_anchors.remove('.')
trust_anchors.add_file('/etc/root.keys', true)
net.bufsize(1232)
net.ipv4=true
net.ipv6=false
cache.open(20*MB)
table.insert(policy.special_names, { count = 0, cb = policy.all(
policy.TLS_FORWARD(
{{'9.9.9.9'
,hostname='dns.quad9.net'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
},{'149.112.112.112'
,hostname='dns.quad9.net'
,ca_file='/etc/ssl/certs/ca-certificates.crt'
}}))})
user('kresd','kresd')

I probably don’t understand it but in the end I have the result I wanted or not? The ISP providers no longer appear anywhere.
It is not yet clear to me whether I should now create the /tmp/kresd.custom.conf myself? Or everything is fine?
Since my dig output or even nslookup shows my custom DNS does it fit then?

nslookup heise.de
Server:		5.1.66.255
Address:	5.1.66.255:53

Non-authoritative answer:
Name:	heise.de
Address: 193.99.144.80

Non-authoritative answer:
Name:	heise.de
Address: 2a02:2e0:3fe:1001:302::

As I said, I don’t understand everything but would like to learn and above all I want to be sure that I am not making a configuration error.

vcunat · January 12, 2025, 2:50am

Normally you get

# cat /etc/resolv.conf 
search lan
nameserver 127.0.0.1
nameserver ::1

No idea how it’s possible to configure it into a different state. I’m sorry.

xturris · January 12, 2025, 11:02am

Could it be somehow related to “adblock”? I installed it via reForis Package. I think dnsmasq is also running on the Turris now, I found the dnsmasq process. Does that somehow confuse everything? I wouldn’t have expected dnsmasq now as apparently knot is running on the turris?
What does this attitude look like for you?
grafik

moeller0 · January 12, 2025, 12:09pm

As far as I can tell it acts as local dhcp server, so running dnsmasq is not indicative of it operating as DNS forwarder.

I would guess trying to configure DNS from within luci might have confused things and you might have ended up in a half baked state.

The screen shot is from luci, did you edit this manually or was this filled automatically as a consequence of changing the DNS setting in reforis?

xturris · January 12, 2025, 1:00pm

The screenshot is from Luci. In the original state, the checkmark is set and then the ISP server is in /etc/resolv.conf as described.
I then started to configure DNS in Luci to use my custom servers. In the end, I just checked the box and entered my servers as described above.

I don’t think I have a half-baked state because the tests with dig, nslookup etc. show the desired result in the end.

So I assume that the check mark is set for you.

Can you show me please what you see on Luci Dashboard at “DNSv4” please?
I change the custom server now to 127.0.0.1 and everything is also working…
grafik

My /etc/resolv.conf shows then this:

cat /etc/resolv.conf 
# Interface wan
nameserver 127.0.0.1

EDIT:
What I’ve noticed now… you always have “lan” in the resolv.conf, I have “WAN”?

moeller0 · January 12, 2025, 1:16pm

Don’t, really just stick to knot and use reforis to configure it…

For me (who has never fiddled with the luci DNS settings at all) the Use DNS serves advertised by peer is always checked independen of whether I enable forwarding in reforis or not.

Do yourself a favor and decide which DNS solution you want:
knot/kresd: stick to TurrisOS and use reforis exclusively to configure DNS
dnsmasq: consider changing to upstream OpenWrt which should work well on the omnia
(no idea about bind, but I believe there are howtos for running unbound as DNS server under OpenWrt)

I believe the checkmark is always set, I am more concerned with you filling values in the fields that appear if the mark is unchecked…

Sure it shows my ISPs servers, but these are not the servers that get used, as I said before that is merely a cosmetic consequence of turris’ knot/kresd configuration not being tightly integrated with luci.

Please do not change any DNS settings in luci, unless you switch to OpenWrt.

root@turris:~# cat /etc/resolv.conf 
search lan
nameserver 127.0.0.1
nameserver ::1

this here is the domain name that get automatically appended on dns searches for IIRC flat names, so when I try to search for OpenWrt-One I get the result for OpenWrt-One.lan, as .lan is OpenWrt"s default local domain…

milkandhoney · January 12, 2025, 1:32pm

I don’t understand, why bother?

Your DHCP clients are using Quad9.
Your Router’s OS is using Quad.

The issue was resolved, when you had the Quad set in Luci.

The alternatives are:

Reset to factory default and start from scratch, while not touching Luci this time.
Edit /etc/resolv.conf manually yourself and set it to 127.0.0.1, if that is important for you.

But as I said, the issue was already resolved.

xturris · January 12, 2025, 1:32pm

Ok let me start again I don’t know if we are talking at cross purposes.
I have now taken back my Luci attitude. So the check mark is set at:

And the fields are empty, so there are no custom servers entered by me. Just like it was at the very beginning, standard.

In the Luci Dashboard the ISP DNS servers are now and also in the /etc/resolv.conf

cat /etc/resolv.conf 
# Interface wan
nameserver 217.237.150.188
nameserver 217.237.151.142

Also, the dig and nslookup commands now show the ISP server everywhere.

In reForis I have this configured:

Everything is like this now without me having changed anything in Luci.
When I do a dnsleaktest on my client it also works, it is the Quad Server.

So all good but in the end my goal was that the Turris router itself not to take the ISP servers… but it does because dig and nslookup point this out.
Maybe I shouldn’t care if at least the clients use the desired DNS server.

moeller0 · January 12, 2025, 1:39pm

I would replace your resolv.conf content with the one @vcunat showed, I bet that this was changed as part of your exploration with luci. As I keep saying knot is not integrated with the luci DNS settings at all, and that likely means there are some hidden traps waiting for an adventurous soul to discover them. My gut feeling is you have been that adventurous soul.

Anyway it is pretty clear by now, that my DNS knowledge is far smaller than I believed, so I am happy to answer specific questions about my setup, but I will refrain from making bigger/bolder statements about knot/dnsmasq.

xturris · January 12, 2025, 2:33pm

One question again… which is your setting in the LAN Interface on the Gateway?

Which IP is there in your setting?

moeller0 · January 12, 2025, 2:46pm

I did not need to enter anything, this is the darkish grey that signifies an automatically filled value.
Sidenote: it is easier to compare things if you show a bit more than a single cut out line of a screenshot.