TCP support

[prajaybasu]

I'm wondering if https-dns-proxy will consider supporting TCP.

I am trying to have a setup like this:

https-dns-proxy <---> dnsmasq <---> DNS over TLS proxy <---> My devices

It is quite easy to terminate TCP with TLS with nginx once acme is already setup, however, dnsmasq has a quirk where if you query via TCP, it will also only query the upstream via TCP. Since https-dns-proxy does not support TCP, it just fails, unless the domain has already been queried via UDP and cached before the TCP request to dnsmasq.

I'm looking at implementing a DoT proxy because most browsers do not use ESNI if DNS is not encrypted. https-dns-proxy is very lightweight, almost gets the job done and if it adds TCP support, will allow for a very lightweight DoT setup on LAN with nginx while preventing third parties snooping on the SNI.

This behavior also affects usage regardless of DoT, any application querying dnsmasq via TCP with https-dns-proxy as the only upstream for dnsmasq will fail.

[baranyaib90]

Hi, there were plenty requests before to support TCP as well, but it has been always denied.
It is a great chance for new contributors to send a pull request for it.
Br, Balázs

[aarond10]

Yeah, I'm not against it but life and kids have left me with not too much room to dedicate to this at the moment. If you have the tech skills to contribute, happy to entertain a patch.

…

On Sun, 15 Jun 2025 at 19:51, baranyaib90 ***@***.***> wrote: *baranyaib90* left a comment (aarond10/https_dns_proxy#186) <#186 (comment)> Hi, there were plenty requests before to support TCP as well, but it has been always denied. It is a great chance for new contributors to send a pull request for it. Br, Balázs — Reply to this email directly, view it on GitHub <#186 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTOXWXI7G44ZRKPRMXT3D3DU6YJAVCNFSM6AAAAAB5QCJZ5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNZTGYZDKMRSGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[baranyaib90]

Hi @prajaybasu, I started to implement TCP and it looks working.
Would you like to give it a try before I send the pull request to master?
Find the changes here: https://github.com/baranyaib90/https_dns_proxy/commits/master/

[prajaybasu]

Hi @baranyaib90, I tested TCP via dig, it works just fine for the very specific scenario in my case as I would be relying on Dnsmasq to only query via TCP. I won't be able to test directly with OpenWrt/Dnsmasq for a while though.

However, it will never be used by any other clients properly because it does not check the DNS response size in https_resp_cb and return a UDP response with the truncate bit set.

Some DNS clients will error out with the current behavior of https-dns-proxy where it will send large DNS response over UDP and disregard the 512-byte limit, or the hint sent by EDNS0 supported clients (previously 4096; currently 1232 since DNS Day 2020)

You can see the behavior of other servers when you try dig with a large response and +qr (I use dig microsoft.com txt +qr as a test).

Dig can handle UDP responses larger than the default EDNS0 1232 response size limit hint and Dnsmasq probably can also handle the same since there's been no issues related to failing queries yet but that is undocumented behavior. Over the wire (instead of loopback), responses exceeding the MTU might also cause issues depending on how the client was written since the packet can be fragmented which is why the default EDNS0 limit is set below IPv6 MTU.

Of course, it's going to add a bit of complexity to manipulate the response packets (or generate a new one) to set the truncate bit and likely cause a regression for clients that rely on the undocumented behavior currently since it'll now take 2 requests for some queries if the truncate bit is sent.

[baranyaib90]

Hi @prajaybasu, OK, I got your point.
Within a few days I can implement to truncate larger UDP responses to 512-byte or to proposed EDNS0 UDP buffer size.
I would appreciate if you could test that as well.

[baranyaib90]

Hi @prajaybasu, I have implemented the UDP truncation on my master branch. Please test it if you have the time. Thank you!

[prajaybasu]

Hi @prajaybasu, I have implemented the UDP truncation on my master branch. Please test it if you have the time. Thank you!

Thanks, that was quick. It works as expected when I tried some basic commands with dig +qr +bufsize=.