{
"log": {
"level": "trace",
"output": "/var/log/singbox.log"
},
"dns": {
"disable_cache": true,
"reverse_mapping": true,
"final": "google-dns",
"rules": [
{
"rule_set": "geosite-cn",
"action": "route",
"server": "ali-dns"
}
],
"servers": [
{
"tag": "google-dns",
"type": "udp",
"server": "8.8.8.8",
"detour": "proxy"
},
{
"tag": "ali-dns",
"type": "tls",
"server": "223.5.5.5",
"detour": "direct"
}
]
},
"route": {
"rules": [
{
"inbound": "dns-in",
"action": "hijack-dns"
}
],
"rule_set": [
{
"tag": "geosite-cn",
"type": "remote",
"format": "binary",
"url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-cn.srs"
}
]
},
"inbounds": [
{
"tag": "dns-in",
"type": "direct",
"listen": "127.0.0.1",
"listen_port": 10053
}
],
"outbounds": [
{
"tag": "direct",
"type": "direct",
"domain_resolver": "ali-dns"
}
]
}
Operating system
Others
System version
FreeBSD 14.3
Installation type
Original sing-box Command Line
If you are using a graphical client, please provide the version of the client.
No response
Version
Description
it seems sing-box returns CNAME responses to the client (or system), which then triggers a new DNS query that goes through the routing matching process again.
which usually breaks user's intention if the initial DNS query and the following recursive query are routing to different geolocation DNS server.
also I noticed commit 3016338 include the logic which query CNAME targets with same transport in a loop.
sing-box/dns/client.go
Lines 155 to 189 in 3016338
looks like what I'm reporting in this issue, but it got commented out.
Reproduction
Minimum config:
Details
dig www.tesla.cnoutput:Logs
Details
Supporter
Integrity requirements