How can I prevent kresd from listening on 853 (DNS-over-TLS)? I found documentation referring to a net.listen setting in /etc/knot-resolver/kresd.conf, but this doesn’t exist on Omnia and I assume all the config should be down by UCI anyway (/etc/config/…). I can’t discover any setting to disable this using UCI. I want kresd to listen only on 53 on the internal network (forwarding requests upstream).
Yes, there’s currently no option on Turris for disabling that.
I can’t see a nice approach here now. In any case, I’m interested in why you dislike it providing DNS-over-TLS.
EDIT: by the way, current Turris OS (5.1.x) doesn’t do what you describe, if I look right. (It was pushed back to 5.2.x, I suppose.)
I don’t want to disable it permanently. I’m trying to diagnose a problem I’m having with DNS and I wanted to do tcpdump on the br-lan interface to analyse in Wireshark to see the DNS request/responses over the wire, but I can only do that if I force everything on the network to use port 53. My preferred way is to prevent kresd listening on 853, but if not possible I can of course just reject packets to 853 in the input firewall chain, which is what I’ll have to do.
AHA!! So that’s the reason DNS started to behave very strangely! I was on HBL (5.3) since I got my Omnia and even while trying to diagnose the DNS problem earlier today. Just a couple of hours ago I reverted to HBK (5.2) and you’re right, kresd does not listen to 853 on UDP there. (It listens on TCP 853 but I guess most things use UDP for DNS requests).
In that case, there seems to be a incompatibility or bug between DNS-over-TLS on the internal network and forwarding the queries to an upstream provider. I was getting ERR_NAME_NOT_RESOLVED all over the place. So there seems to be some regression there (I spent all afternoon battling with it)…
Eh, this is all very confusing. UDP on 853 is not implemented (DNS-over-DTLS… basically noone does that); DNS-over-TLS is built on TCP port 853. Also, processing for upstream and downstream is decoupled in Knot Resolver, i.e. it shouldn’t matter how the request came, it’s processed (almost) the same way.
I haven’t really been following what’s going on in HBK and HBL, but in any case, usually we have best DNS debugging results from inspecting verbose logs: https://wiki.turris.cz/doc/en/howto/dnsdebug#gather_the_data
Hm, yes, you’re right regarding UDP 853. I did a netstat -tupln while on HBL and kresd was definitely listening on 853, but I couldn’t remember whether UDP or TCP. Thinking about it, TLS over UDP is a bit strange. I also just checked the tcpdump pcap files I made and yes, it’s TCP. My Android phone was doing DNS-over-TLS and was failing DNS resolutions.
Anway, I spoke too soon. I’m now on HBK, and with DNS forwarding it’s still failing DNS resolution - only on my Android phone though, which according the pcap dumps is doing DNS-over-TLS. Disabling forwarding fixes it, but honestly I have no idea what’s going on.
EDIT: I’ll try the verbose logging you mentioned.
Well, they certainly are verbose. And weird.
I’m sending the output of “Start resolver debugging”, with lots of strange lookups, many of which fail. For example www.google.com returns status: SERVFAIL and no IP address: https://cd.wedos.com/s/4pA4sLGqjZXe4bs
I’m also sending the output of the debug log itself. I ran the debug immediately after a reboot and ran for 15sec from the time I clicked Start (approx 20:23:30 UTC) to Stop (20:23:52). I tried accessing bbc.com from my phone at 20:23:39, which failed with ERR_NAME_NOT_RESOLVED. The log is very verbose with plenty of errors, and I don’t really understand it: https://cd.wedos.com/s/F65QaKDXHeAcY7Y
Any ideas what’s wrong?
(The logs are so long they won’t fit here).
So… in the end I downgraded all the way down to HBT. kresd is only listed on 53 now. I have re-enabled DNS forwarding and DNS look ups from my phone work again.
I expect your IPv6 doesn’t normally work. For some reason the resolver gets stuck trying IPv6 addresses all the time without touching IPv4 (your config is TLS-forwarding to Google’s public DNS).
Workaround for now should be fixing your IPv6 or editing
/etc/config/resolver, in section
config resolver 'common' override
option net_ipv6 '1' to zero. Another way would be to uncheck forwarding (DNS tab in (re)Foris); that mode should have improved detection of IPv6 brokenness.
@pepe: FYI, I suspect this is a regression in kresd 5.3.0 (HBK+ ATM); we’ll be looking into it upstream.
Thanks Vladimir Hmm, fixing IPv6? Easier said than done
Yes, I understand it’s hard for many end-users.
My universal solution to “fixing” IPv6 is:
sysctl -w net.ipv6.conf.all.disable_ipv6=1
but I’m scared to do that on the Omnia.
I don’t think it would help this case. And IIRC something radical like that does happen if you disable IPv6 in (re)Foris WAN tab.
OK thanks. So I think I’ll go back to HBK (I’m on HBT now) and have Knot do resolving itself instead of forwarding. BTW, IPv6 in WAN is disabled (my ISP doesn’t support it).
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.