[BUG] 没有DNS tcp劫持，导致client的TCP类型的DNS请求有可能被污染

[wdlid]

自查

• 已经关闭了DNSMASQ的DNS 重定向选项（如无此项请忽略）
• 已停止运行其他代理插件，并确认环境正常

确认

• 我已经查看过Wiki，没有找到解决办法
• 我已经搜索过Issue，没有找到相关问题
• 我使用的是通过仓库Release或Feed安装的最新版的插件
• 这确实是插件的问题，而不是核心/面板/订阅转换服务的问题
• 我提供的信息里不包含公网IPv4地址、公网IPv6地址、MAC、代理节点等敏感信息
• 我提供了正确的、有效的、可以帮助DEBUG的信息
• 我明白如果我不遵循模板填写，Issue将会被关闭
• 我是为了提交Issue才选择了上述选框，我不知道我在做什么

BUG 描述

tcp类型的DNS查询不会被mihomo接管，导致DNS污染的情况发生。
UDP类型返回的是正确的。

预期行为

客户端tcp类型的查询也应该由mihomo接管。

复现步骤

正常配置mihomo. DNS redir-host 模式。

调试信息

PS C:> ipconfig /flushdns
PS C:> dig www.google.com.hk
www.google.com.hk. 31 IN A 142.251.175.94 >>>>>>> 正确回复

PS C:> dig www.google.com.hk +tcp
www.google.com.hk. 11 IN A 31.13.106.4 >>>>> 被污染到了twitter的地址。

插件日志

无

核心日志

无

附加信息

No response

[morytyann]

接管不了，核心的DNS只监听UDP，只支持UDP的DNS请求，如果想在不引入其它DNS工具的情况下处理，只能默认开启TUN，使用TUN来处理。

[wdlid]

感谢。
为了不会有污染的结果，我让TCP强制转到1053了，失败也比污染强。
至少tcp不成功，client自动就用udp了，嗯，我说的就是Chrome。

[morytyann]

MetaCubeX/mihomo#1792

看看这个PR能不能合并吧，如果合并的话我改下防火墙规则就可以劫持TCP了，这样比用TUN来劫持要方便一些。

[morytyann]

上游大佬没有合并我的PR，但是还是实现了TCP的监听，我在v1.17.4更新了核心并在防火墙劫持了TCP请求。