[Bug Report] 似乎 DAED/DAE 并未正确处理 SRV DNS 记录

[CallMeR]

Checks

• I have searched the existing issues
• I have read the documentation
• Is it your first time sumbitting an issue

Current Behavior

DNS 规则如下 (其中 127.0.0.1:8053 为本地 smartdns )：

upstream {
  local:  'udp://114.114.114.114:53'
  remote: 'udp://127.0.0.1:8053'
}
routing {
  request {
    qname(geosite:category-ads-all) -> reject

    qname(geosite:china-list) -> local
    qname(geosite:apple-cn) -> local
    qname(geosite:google-cn) -> local

    qname(geosite:cn) -> local

    fallback: remote
  }
}

最近发现日志中存在如下日志：

level=info msg="localhost:59609 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=5 mac="xx:xx:xx:xx:xx:e2" network="udp4(DNS)" outbound=direct pid=760 pname=smartdns policy=fixed qtype=SRV
level=info msg="localhost:49493 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=5 mac="xx:xx:xx:xx:xx:e2" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="x.x.x.5:54725 <-> 127.0.0.1:8053" _qname="_https._tcp.pkgs.tailscale.com." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="x.x.x.5:47464 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="x.x.x.5:32983 <-> 127.0.0.1:8053" _qname="_https._tcp.pkgs.tailscale.com." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="x.x.x.5:43202 <-> 127.0.0.1:8053" _qname="_https._tcp.pkgs.tailscale.com." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="x.x.x.5:39599 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="x.x.x.5:50338 <-> 127.0.0.1:8053" _qname="_https._tcp.pkgs.tailscale.com." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="x.x.x.5:46805 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="localhost:38006 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=5 mac="xx:xx:xx:xx:xx:e2" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=SRV
level=info msg="localhost:59427 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=5 mac="xx:xx:xx:xx:xx:e2" network="udp4(DNS)" outbound=direct pid=2808 pname=smartdns policy=fixed qtype=SRV

发现形如 _https._tcp.pkgs.tailscale.com 类型为 SRV 的域名均发送到了 127.0.0.1:8053 进行处理。

_https._tcp.pkgs.tailscale.com 域名处理应该符合规则，但 _https._tcp.mirrors.ustc.edu.cn 似乎处理的不正确。

为了判断是否为 Geo 数据库分流导致的问题，手动在 dns 规则中增加规则：

qname(suffix:_https._tcp.mirrors.ustc.edu.cn) -> local

得到如下告警：

level=warning msg="DomainMatcher: skip bad suffix domain: _https._tcp.mirrors.ustc.edu.cn: unexpected chat: 95"

进一步尝试：

qname(full:_https._tcp.mirrors.ustc.edu.cn) -> local

得到如下告警：

time="Dec 07 11:15:58" level=warning msg="[Reload] Received reload signal; prepare to reload"
time="Dec 07 11:15:58" level=warning msg="[Reload] Load new control plane"

time="Dec 07 11:15:59" level=warning msg="DomainMatcher: skip bad full domain: _https._tcp.mirrors.ustc.edu.cn: unexpected chat: 95"

time="Dec 07 11:16:00" level=warning msg="[Reload] Stopped old control plane"
time="Dec 07 11:16:00" level=warning msg="[Reload] Serve"
time="Dec 07 11:16:00" level=warning msg="[Reload] Finished"
time="2023-12-07T11:16:01+08:00" level=warning msg="dangerous converting: may exceeds graphQL int32 range" name=SoMarkFromDae type=uint32
time="2023-12-07T11:16:01+08:00" level=warning msg="dangerous converting: may exceeds graphQL int32 range" name=SoMarkFromDae type=uint32

这么看来是 DomainMatcher 对域名处理异常导致。

Expected Behavior

_https._tcp.mirrors.ustc.edu.cn 这类域名的 DomainMatcher ，应该被正确处理。

• 如果 Geo 数据库可以判断这类域名的分流，则按照 dns 配置文件中的 Geo 规则处理
• 如果手动指定 dns 出口，发送到指定的上游 dns 服务器，例如 _https._tcp.mirrors.ustc.edu.cn 发往 local dns

其他种类的 DNS 请求 （Domain Name System (DNS) Parameters）, 还在进一步观察

Steps to Reproduce

No response

Environment

• Daed version : latest rc
• OS (e.g cat /etc/os-release) : Debian 12 latest
• Kernel (e.g. uname -a) : 6.1.0-13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/Linux
• Others:

Anything else?

No response

[dae-prow]

Thanks for opening this issue!

[CallMeR]

翻看了一下 dae 的相关代码，根据 component/routing/domain_matcher/ahocorasick_slimtrie.go

合法域名符号中并未包含 _ 字符

var ValidDomainChars = trie.NewValidChars([]byte("0123456789abcdefghijklmnopqrstuvwxyz-.^"))

附带找到的资料：

https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it

[mzz2017]

@CallMeR https://github.com/daeuniverse/daed/actions/runs/7183875087 修了，可以来测试一下吗

[CallMeR]

@CallMeR https://github.com/daeuniverse/daed/actions/runs/7183875087 修了，可以来测试一下吗

试了一下，现在版本号为 frontier-54bc339.a7252d9.8d8d5ff

在 DNS 设置里面分别设置了：

## domain suffix
qname(suffix:_https._tcp.mirrors.ustc.edu.cn) -> local

## or full domain
qname(full:_https._tcp.mirrors.ustc.edu.cn) -> local

在 DAED 的重载/重启过程中，不会报 warning 了。

但 _https._tcp.mirrors.ustc.edu.cn 域名的请求还是被发送给了 127.0.0.1:8053 而非指定的 local dns

分别进行手动解析和 apt update 触发该域名解析，日志如下：

time="Dec 13 10:22:42" level=info msg="xx.xx.xx.5:39896 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=A
time="Dec 13 10:22:43" level=info msg="xx.xx.xx.5:58881 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=AAAA
time="Dec 13 10:26:31" level=info msg="xx.xx.xx.5:40108 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=A
time="Dec 13 10:26:31" level=info msg="xx.xx.xx.5:39990 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=AAAA
time="Dec 13 10:27:10" level=info msg="xx.xx.xx.5:48784 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=A
time="Dec 13 10:41:00" level=info msg="xx.xx.xx.5:52468 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=A
time="Dec 13 10:41:00" level=info msg="xx.xx.xx.5:52823 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=0 mac="xx:xx:xx:xx:xx:a1" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qtype=AAAA

time="Dec 13 10:53:17" level=info msg="localhost:60754 <-> 127.0.0.1:8053" _qname="_https._tcp.mirrors.ustc.edu.cn." dialer=direct dscp=5 mac="xx:xx:xx:xx:xx:e2" network="udp4(DNS)" outbound=direct pid=805 pname=smartdns policy=fixed qtype=SRV

time="Dec 13 10:53:17" level=info msg="localhost:60754 <-> 114.114.114.114:53" _qname=mirrors.ustc.edu.cn. dialer=direct dscp=5 mac="xx:xx:xx:xx:xx:e2" network="udp4(DNS)" outbound=direct pid=805 pname=smartdns policy=fixed qtype=AAAA
time="Dec 13 10:53:17" level=info msg="localhost:60754 <-> 114.114.114.114:53" _qname=mirrors.ustc.edu.cn. dialer=direct dscp=5 mac="xx:xx:xx:xx:xx:e2" network="udp4(DNS)" outbound=direct pid=805 pname=smartdns policy=fixed qtype=A

[mzz2017]

https://github.com/daeuniverse/dae/actions/runs/7362811384?pr=388

抱歉迟来的补救，我已确信此问题被修复，麻烦帮忙确认一下，谢谢 🙏。 @CallMeR

[CallMeR]

https://github.com/daeuniverse/dae/actions/runs/7362811384?pr=388

抱歉迟来的补救，我已确信此问题被修复，麻烦帮忙确认一下，谢谢 🙏。 @CallMeR

感谢支持！ 不过这次 ci 编译出来的 dae 版本，我目前用的还是 daed 环境 :)

Daed 新版发布了我应该能进一步测试这个问题了 @mzz2017