PikuZheng
commented
2 months ago 猜测是查询循环，向上游查询时被劫持，但是劫持了的目标又是自己
Open betaxab opened 2 months ago
PikuZheng
commented
2 months ago 猜测是查询循环，向上游查询时被劫持，但是劫持了的目标又是自己
pymumu
commented
2 months ago 用最新代码看看有没有问题
betaxab
commented
2 months ago 还是不行，这次卡到 cloudfront 一个域名上了。
[2024-04-27 01:24:31,407][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 28, id: 1294, group: default, time: 0ms
[2024-04-27 01:24:31,407][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 1, id: 11106, group: default, time: 0ms
[2024-04-27 01:24:31,407][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 28, id: 49383, group: default, time: 0ms
[2024-04-27 01:24:31,407][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 1, id: 30296, group: default, time: 0ms
[2024-04-27 01:24:31,411][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 28, id: 53765, group: default, time: 0ms
[2024-04-27 01:24:31,411][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 1, id: 3136, group: default, time: 0ms
[2024-04-27 01:24:31,411][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 28, id: 62503, group: default, time: 0ms
[2024-04-27 01:24:31,411][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 1, id: 43455, group: default, time: 0ms
[2024-04-27 01:24:31,564][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 1, id: 2339, group: default, time: 0ms
[2024-04-27 01:24:31,564][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 28, id: 2414, group: default, time: 0ms
[2024-04-27 01:24:31,564][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 28, id: 38427, group: default, time: 0ms
[2024-04-27 01:24:31,564][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 1, id: 45011, group: default, time: 0ms
[2024-04-27 01:24:31,568][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 28, id: 11813, group: default, time: 0ms
[2024-04-27 01:24:31,569][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net, client: 127.0.0.1, qtype: 1, id: 25725, group: default, time: 0ms
[2024-04-27 01:24:31,569][ INFO][ dns_server.c:2393] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 28, id: 41869, group: default, time: 0ms
[2024-04-27 01:24:31,569][ INFO][ dns_server.c:4488] result: d1upatzsvnpphr.cloudfront.net.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 1, id: 20863, group: default, time: 0ms[2024-04-27 01:23:09,103] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:09,125] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:14,301] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:14,303] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:14,459] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:14,459] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:31,149] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:44,616] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:44,756] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:23:44,760] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:24:31,407] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:24:31,411] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:24:31,564] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, result
[2024-04-27 01:24:31,569] 127.0.0.1 query d1upatzsvnpphr.cloudfront.net, type 1, time 0ms, speed: -0.1ms, group default, resultsmartdns 1.2024.04.27-0055 (Release45-13-g9642dc4)
pymumu
commented
2 months ago 把1.1.1.1和1.0.0.1去掉看看
betaxab
commented
2 months ago @pymumu 去掉了 1111 和 1001 DNS，用了一天，好像不出问题了，这么神奇的吗？想知道这是什么情况。
pymumu
commented
2 months ago 可能你的客户端启用了ecs，1.1.1.1这种情况下可能会返回空结果
betaxab
commented
2 months ago 并没有，从 43 直接升级到 45 什么都没有动。在服务器上直接 dig 也是一样，有时候得不到解析，甚至有时候影响到 debian 的 repo，apt install 软件下载不了，再一看 DNS 解析没了。我在另外一个非 aws 服务器上，采用完全一模一样的配置，倒是没有遇到解析问题。 之前用 43 以及更早版本的时候，也没有遇到这种问题。我以后aws的话，都不能用1111了么？
update:
在一台瓦工日本vps、德国linode也遇到了相同的丢解析情况。
pymumu
commented
2 months ago 那你吧blacklist.conf注释掉看看 还有打开debug，获取一下域名第一次出问题的log
betaxab
commented
1 month ago 我附上一份完整的 log，DEBUG 模式，测试机是瓦工日本。
smartdns.log smartdns-audit.log
目前没有作为代理机，只是执行了一个流媒体测试脚本，用于模拟访问多个域名的情况。
具体日志里可以观察 www.youtube.com ，在服务器上执行脚本时，DNS解析直接丢失。
如果有进一步的测试需要，我可以提供 ROOT 密码。
PikuZheng
commented
1 month ago 我附上一份完整的 log，DEBUG 模式，测试机是瓦工日本。
同服主机（？），但是一用https就被封端口，搞得我都不敢用了。
result is truncated, www.youtube.com qtype: 1, rcode: 0, id: 34762, retry. 这个现象看起来和 #1690 相似，目前还是考虑网络问题
有没有试过到8.8.8.8或1.1.1.1用tls？
betaxab
commented
1 month ago 目前还是考虑网络问题
/etc/resolv.conf 无论是直接填 nameserver 1.1.1.1 还是 nameserver 1.0.0.1，不会出现问题。这些服务器都在国外，不存在网络故障、丢包亦或者配置错误。更不考虑被墙的情况（只是在服务器本机上使用，不经过国内）。
我遇到出问题的厂商有：AWS（东京、首尔、德国、英国）、Linode（德国）、瓦工（大阪）。这些都很出名，绝对是不会是因为网络问题导致这种现象。要说一家网络是坏的，那么列出的这些厂商不可能全不行。我尝试过重装服务器，重新开新的服务器，都是一样的通病。我换成旧版本的 smartdns，也不存在这种现象。我之前一直在用 release 43 或者更早版本，是近期才换到 45 版本的。43 版本及之前没有发生过这种问题。
有没有试过到8.8.8.8或1.1.1.1用tls？
将上面 DNS 配置去掉 1.1.1.1/1.0.0.1，只使用 8.8.8.8/8.8.4.4，没发现出毛病。
刚刚经过测试，将 1.1.1.1/1.0.0.1 换成 tls://1.1.1.1:853 与 tls://1.0.0.1:853 DoT，其它不动，不出问题。
PikuZheng
commented
1 month ago 也就是说，只有smartdns与1.1.1.1、1.0.0.1的udp搭配会有问题 😅
pymumu
commented
1 month ago 老版本，跑一下，发一下debug log
betaxab
commented
1 month ago 目前附件中传的是，使用 Release 43 的 debug 模式的 log 结果。
在版本 43 中，测试没有任何 DNS 解析结果丢失。
pymumu
commented
1 month ago 之前版本查询1.1.1.1也是有问题，不过忽略了查询错误。返回的其实是其他DNS的结果。 看log
qdcount = 1, ancount = 0, nscount = 0, nrcount = 0, len = 46, id = 37986, tc = 1, rd = 1, ra = 1, rcode = 0, payloadsize = 1232这里tc=1一般数据都有缺失。
我这里看1.1.1.1，不会有tc = 1的情况，不清楚你网络有什么不同？
betaxab
commented
1 month ago 这真的就十分困惑了，因为 resolv.conf 直接填 1111 没问题。
我把 ssh 登录信息通过alipay捐赠发给你了，你可以登录研究一下。
ssh root@$(echo $付款备注 | awk '{print $1}') -p $(echo $付款金额 | tr -d '.') 密码 $(echo $付款备注 | awk '{print $2}')
pymumu
commented
1 month ago 同一个域名，是随机出现，还是必现？ 查询smartdns的方式是什么？直接查询，还是通过其他DNS服务器
betaxab
commented
1 month ago 同一个域名，是随机出现，还是必现？
随机。使用过程中，根本不知道具体会在哪个域名上出现了丢失 DNS 解析。且丢失 DNS 解析的域名不止一个。
查询smartdns的方式是什么？
步骤：
将 nameserver 1.1.1.1 填入 smartdns.conf，并设置监听 bind 127.0.0.1:53（配置文件可见一楼）。然后将 nameserver 127.0.0.1 填入 /etc/resolv.conf。然后直接使用这台服务器。
设置完毕后，可在服务器上，直接执行该测试脚本，测试在一段时间内，查询多个域名的情况：
bash <(curl -L -s check.unlock.media) -M 4
pymumu
commented
1 month ago 简单看了一下，可能是1.1.1.1对你的机器做了限流，连续查询就会返回空记录。 用第三方工具，同样是有问题的。
在你给的那个机器上，root目录执行下面命令，让mdig连续查询，就会出现查询超时的情形。
mdig -b 0.0.0.0#3333 +noedns @1.1.1.1 -f 1.txttcpdump看回应记录，确认回的结果就是空
23:13:58.510361 eth0 In IP 1.1.1.1.53 > xx.xx.xx.xx.3333: 51281| 0/0/0 (33)
0x0000: 4510 003d eca5 4000 3b11 eab2 0101 0101 E..=..@.;.......
0x0010: xxxx xxxx 0035 0d05 0029 00bf c851 8380 -N8..5...)...Q..
0x0020: 0001 0000 0000 0000 0377 7777 0779 6f75 .........www.you
0x0030: 7475 6265 0363 6f6d 0000 0100 01 tube.com.....你用resolv.conf没有问题，是因为查询失败会用tcp查询，用dig命令没有问题，是因为每次dig算是一个新的进程，1.1.1.1限流是按端口限流的，新进程会用新端口。
你可以用你家里的机器看看有没有问题。
因为smartdns目前查询失败，不会自动fallback到tcp。
针对这种场景，我修改了一下代码，在你的那个机器上，可以看看有没有问题。
betaxab
commented
1 month ago 简单看了一下，可能是1.1.1.1对你的机器做了限流，连续查询就会返回空记录。
用dig命令没有问题，是因为每次dig算是一个新的进程，1.1.1.1限流是按端口限流的，新进程会用新端口。
啊啊，原来是这个样子，这下明白了。。。感谢解惑。。
针对这种场景，我修改了一下代码，在你的那个机器上，可以看看有没有问题。
好，等您的提交，我编译来试试看。
PikuZheng
commented
1 month ago 1.1.1.1 支持tcp查询吗？是不是用tcp/53可以避免这个问题？
pymumu
commented
1 month ago 更新了代码
betaxab
commented
1 month ago @pymumu 经过两天的测试，DNS 解析不存在任何问题了。
问题现象
目前使用 SS 连接这台服务器使用，这台服务器作为我的代理服务器。服务器用着用着，访问一些网站时，DNS 解析记录就消失了，这些域名并不固定，也不知道具体是赶上了哪个。就比如日志里，这次赶上了 dynamic.t0.tiles.ditu.live.com。
等个10分钟过去以后，这域名解析记录就恢复正常了，有时候等不及，重启 smartdns 服务，也能让它访问正常。
我试过打开 cache-persist，不关这里的事，开了也同样遇到相同情况。
我在以前用 release 43 的时候，相同的配置，并没有遇到这种很奇怪的问题。
运行环境
Debian 12
AWS Lightsail 日本
最新的 release 45
smartdns.conf 文件
重现步骤
信息收集
log:
audit log: