dnsmasq on openwrt gets stuck while making TCP connections

[chetan-kumar-nagra-com]

Openwrt version: 18.06.8 https-dns-proxy package Version: 2020-11-25-1 (obtained from opkg info https-dns-proxy) Dnsmasq version 2.80

Description: I have installed https-dns-proxy on my Linksys router with openwrt (by doing opkg install https-dns-proxy). https-dns-proxy is configured to use my custom DOH server and as I understood, https-dns-proxy becomes the server that dnsmasq will use.

https-dns-proxy is configured with following commands:

while uci -q delete https-dns-proxy.@https-dns-proxy[0]; do :; done

uci set https-dns-proxy.dns="https-dns-proxy"

uci set https-dns-proxy.dns.bootstrap_dns=8.8.8.8

uci set https-dns-proxy.dns.resolver_url=

uci set https-dns-proxy.dns.listen_addr=127.0.0.1

uci set https-dns-proxy.dns.listen_port=5053

I observe that the dnsmasq somehow gets stuck and doesn't respond to the DNS requests anymore randomly. the issue sometimes happens more when i reboot the router. the only way to recover from this situation is that I have to restart the dnsmasq service.

/etc/init.d/dnsmasq restart

I tried to debug the issue and here are my findings:

Whenever the issue happened, I could see that there were attempts from some clients in the network to do DNS resolution with TCP. As https-dns-proxy doesn't support TCP connections, dnsmasq will fail making a connection and reports an error in the log.

Nov 28 11:30:03 dnsmasq[12438]: config error is REFUSED

However, the issue is not reproducible always with this. I tried to force TCP DNS resolutions with dig and it doesn't always cause the dnsmasq to get stuck.

I tried to tcpdump the packets with port 53 on the loopback interface when the issue happens and I see there are some malformed DNS packets.

Questions:

1. is there a roadmap to support TCP DNS requests in the https-dns-proxy?
2. are there any known issues of this sort?
3. what happens when a client tries to establish a TCP connection to https-dns-proxy? I see that some of the packets which are TCP based are also getting a reply (not many, but a few are).
4. surprisingly, when using google DOH Server dns.google as the resolver for https-dns-proxy, the issue is not reproducible. what I observe is, there are not a lot of TCP based DNS requests, when I use google DOH server.

[baranyaib90]

Hi, I understand your issue and it's valid. I wrote my answers according my knowledge. (I'm not speaking in @aarond10 name.)

1. There is no plan to support TCP DNS requests.
2. No, it seems like TCP DNS request issues were not written before.
3. The client can not establish TCP connection to https-dns-proxy, since the proxy does not listen on TCP port, just on UDP. So the client will receive connection error.
4. This is strange. Since TCP is used, when the DNS reply can not fit into the UDP DNS response limit (512 byte). It seems like dns.google strips the response to fit into the limit. The other resolver service might work differently.

This is an area I'm not familiar with. It would be great if dnsmasq could be configured to disable TCP DNS as well and hopefully the clients can work in UDP only mode.

[aarond10]

Sorry for being a bit absent for the past N months. I'll try to be a bit more responsive going forward. When I first wrote this software there was no DNS-Over-HTTPS standard and the defacto standard involved parsing JSON. I used UDP just because that was generally the default.

With standardization, protocol translation to/from JSON wasn't required so things got a lot simpler. I have wondered a few times if just migrating to TCP would be a good idea. My hesitation has been about breaking existing users who may or may not be using a caching proxy with this. I'll have a think a bit more and see how much work it would be.