sing-box DNS监听端口循环问题分析与解决方案

问题背景

在sing-box 1.11-beta.20版本中，用户报告了一个关于DNS服务循环解析的问题。当配置一个监听53端口的direct类型入站(inbound)用于提供局域网DNS服务时，系统会出现DNS请求无限循环的现象，导致大量日志输出和系统资源消耗。

问题现象

用户配置如下inbound用于DNS服务：

{
  "type": "direct",
  "tag": "dns-in",
  "listen": "::",
  "listen_port": 53
}

配合路由规则：

{
  "inbound": "dns-in",
  "action": "resolve"
}

启动服务后，系统立即产生大量日志，显示DNS请求在本地回环，不断向自身IP地址(192.168.144.120和IPv6地址)的53端口发起请求。

问题分析

根本原因

1. 协议未明确限制：原始配置中未指定network字段，导致同时监听TCP和UDP端口。DNS协议通常使用UDP，但TCP回退机制会导致问题复杂化。

2. 路由解析循环：当DNS请求进入direct类型的inbound后，resolve动作会再次将请求发往本地DNS端口，形成无限循环。

3. 自动嗅探机制：sing-box的协议自动嗅探功能在检测到DNS协议流量后，会再次触发resolve动作，加剧了循环问题。

解决方案

最佳实践配置

通过明确指定network字段为"udp"，可以彻底解决问题：

{
  "type": "direct",
  "tag": "dns-in",
  "listen": "::",
  "listen_port": 53,
  "network": "udp"
}

方案优势

1. 协议明确：仅监听UDP端口，避免TCP带来的复杂性。
2. 性能优化：UDP协议更适合DNS查询场景，减少连接开销。
3. 避免循环：UDP无连接特性天然避免了请求回环问题。

技术原理深入

sing-box DNS处理流程

1. 入站接收：网络请求首先到达配置的inbound。
2. 协议识别：系统自动嗅探或根据配置识别协议类型。
3. 路由决策：根据路由规则决定如何处理请求(resolve/hijack等)。
4. 出站转发：将请求发送到指定服务器或执行特定动作。

循环产生机制

在原始配置中，流程变为：

1. DNS请求进入direct inbound
2. 被识别为DNS协议
3. 路由规则触发resolve动作
4. resolve再次将请求发往本地53端口
5. 重复步骤1-4，形成无限循环

配置建议

对于类似网络服务监听场景，建议：

1. 明确指定协议类型(network字段)
2. 对于DNS服务优先使用UDP协议
3. 在路由规则中考虑添加额外条件避免循环
4. 测试环境先启用debug日志观察流量走向

版本兼容性说明

此问题在sing-box 1.11-beta.20版本中发现，但解决方案具有向后兼容性，适用于大多数版本。用户在升级版本时应注意：

1. 检查路由规则语法变化
2. 验证DNS功能是否正常
3. 监控系统资源使用情况

通过以上分析和解决方案，用户可以稳定地在sing-box上部署DNS服务，避免循环解析问题。