Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

莫名其妙的丢一些 DNS 解析 #1730

Open
betaxab opened this issue Apr 26, 2024 · 23 comments
Open

莫名其妙的丢一些 DNS 解析 #1730

betaxab opened this issue Apr 26, 2024 · 23 comments

Comments

@betaxab
Copy link

betaxab commented Apr 26, 2024

问题现象

目前使用 SS 连接这台服务器使用，这台服务器作为我的代理服务器。服务器用着用着，访问一些网站时，DNS 解析记录就消失了，这些域名并不固定，也不知道具体是赶上了哪个。就比如日志里，这次赶上了 dynamic.t0.tiles.ditu.live.com。

等个10分钟过去以后，这域名解析记录就恢复正常了，有时候等不及，重启 smartdns 服务，也能让它访问正常。

我试过打开 cache-persist，不关这里的事，开了也同样遇到相同情况。

我在以前用 release 43 的时候，相同的配置，并没有遇到这种很奇怪的问题。

运行环境

  1. Debian 12

  2. AWS Lightsail 日本

  3. 最新的 release 45

  4. smartdns.conf 文件

conf-file blacklist.conf
conf-file nf.conf

bind 127.0.0.1:53
cache-size 32768
cache-persist no
cache-file /tmp/smartdns.cache
prefetch-domain yes
serve-expired yes
serve-expired-ttl 30
serve-expired-reply-ttl 30
force-qtype-SOA 65,28
rr-ttl 300
rr-ttl-min 60
rr-ttl-max 600
rr-ttl-reply-max 60
log-level info

log-file /var/log/smartdns/smartdns.log
log-size 128k
log-num 1
audit-enable yes
audit-file /var/log/smartdns/smartdns-audit.log
audit-size 128k
audit-num 1

server 100.100.100.100:53 -group nf -exclude-default-group
server 1.1.1.1
server 1.0.0.1
server 8.8.8.8
server 8.8.4.4

重现步骤

  1. 不知道如何重现，也不知道怎么看。毕竟不是固定的域名。我觉得吧，开一台 AWS LS 作为代理，用上一段时间，可能会复现。

信息收集

  1. 将/var/log/smrtdns.log日志作为附件上传(注意去除个人相关信息)。

log:

[2024-04-26 21:10:40,261][ INFO][     dns_server.c:2390] result: dynamic.t0.tiles.ditu.live.com, client: 127.0.0.1, qtype: 28, id: 4708, group: default, time: 0ms
[2024-04-26 21:10:40,261][ INFO][     dns_server.c:4478] result: dynamic.t0.tiles.ditu.live.com, client: 127.0.0.1, qtype: 1, id: 36631, group: default, time: 0ms
[2024-04-26 21:10:40,261][ INFO][     dns_server.c:2390] result: dynamic.t0.tiles.ditu.live.com.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 28, id: 62097, group: default, time: 0ms
[2024-04-26 21:10:40,261][ INFO][     dns_server.c:4478] result: dynamic.t0.tiles.ditu.live.com.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 1, id: 20822, group: default, time: 0ms
[2024-04-26 21:10:40,267][ INFO][     dns_server.c:2390] result: dynamic.t0.tiles.ditu.live.com, client: 127.0.0.1, qtype: 28, id: 52194, group: default, time: 0ms
[2024-04-26 21:10:40,267][ INFO][     dns_server.c:4478] result: dynamic.t0.tiles.ditu.live.com, client: 127.0.0.1, qtype: 1, id: 58689, group: default, time: 0ms
[2024-04-26 21:10:40,267][ INFO][     dns_server.c:2390] result: dynamic.t0.tiles.ditu.live.com.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 28, id: 2819, group: default, time: 0ms
[2024-04-26 21:10:40,267][ INFO][     dns_server.c:4478] result: dynamic.t0.tiles.ditu.live.com.ap-northeast-1.compute.internal, client: 127.0.0.1, qtype: 1, id: 18120, group: default, time: 0ms

audit log:

[2024-04-26 21:09:03,848] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:03,880] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:03,910] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:03,929] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:03,982] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:03,986] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:04,029] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:04,059] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:04,067] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:04,107] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result 
[2024-04-26 21:09:04,118] 127.0.0.1 query dynamic.t0.tiles.ditu.live.com, type 1, time 0ms, speed: -0.1ms, result
  1. 进程无异常
@PikuZheng
Copy link
Contributor

猜测是查询循环，向上游查询时被劫持，但是劫持了的目标又是自己

@pymumu
Copy link
Owner

pymumu commented Apr 26, 2024

用最新代码看看有没有问题

@betaxab
Copy link
Author

betaxab commented Apr 26, 2024

还是不行，这次卡到 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, result

smartdns 1.2024.04.27-0055 (Release45-13-g9642dc4)

@pymumu
Copy link
Owner

pymumu commented Apr 27, 2024

把1.1.1.1和1.0.0.1去掉看看

@betaxab
Copy link
Author

betaxab commented Apr 27, 2024

@pymumu 去掉了 1111 和 1001 DNS，用了一天，好像不出问题了，这么神奇的吗？想知道这是什么情况。

@pymumu
Copy link
Owner

pymumu commented Apr 28, 2024

可能你的客户端启用了ecs，1.1.1.1这种情况下可能会返回空结果

@betaxab
Copy link
Author

betaxab commented Apr 28, 2024 •
edited

并没有，从 43 直接升级到 45 什么都没有动。在服务器上直接 dig 也是一样，有时候得不到解析，甚至有时候影响到 debian 的 repo，apt install 软件下载不了，再一看 DNS 解析没了。我在另外一个非 aws 服务器上，采用完全一模一样的配置，倒是没有遇到解析问题。
之前用 43 以及更早版本的时候，也没有遇到这种问题。我以后aws的话，都不能用1111了么？

update:

在一台瓦工日本vps、德国linode也遇到了相同的丢解析情况。

@pymumu
Copy link
Owner

pymumu commented Apr 29, 2024

那你吧blacklist.conf注释掉看看
还有打开debug，获取一下域名第一次出问题的log

@betaxab
Copy link
Author

betaxab commented May 5, 2024 •
edited

我附上一份完整的 log，DEBUG 模式，测试机是瓦工日本。

smartdns.log
smartdns-audit.log

目前没有作为代理机，只是执行了一个流媒体测试脚本，用于模拟访问多个域名的情况。

具体日志里可以观察 www.youtube.com ，在服务器上执行脚本时，DNS解析直接丢失。

如果有进一步的测试需要，我可以提供 ROOT 密码。

@PikuZheng
Copy link
Contributor

我附上一份完整的 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
Copy link
Author

betaxab commented May 5, 2024

目前还是考虑网络问题

/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
Copy link
Contributor

也就是说，只有smartdns与1.1.1.1、1.0.0.1的udp搭配会有问题 😅

@pymumu
Copy link
Owner

pymumu commented May 6, 2024

老版本，跑一下，发一下debug log

@betaxab
Copy link
Author

betaxab commented May 6, 2024

目前附件中传的是，使用 Release 43 的 debug 模式的 log 结果。

在版本 43 中，测试没有任何 DNS 解析结果丢失。

smartdns.log
smartdns-audit.log

@pymumu
Copy link
Owner

pymumu commented May 6, 2024

之前版本查询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
Copy link
Author

betaxab commented May 6, 2024

这真的就十分困惑了，因为 resolv.conf 直接填 1111 没问题。

我把 ssh 登录信息通过alipay捐赠发给你了，你可以登录研究一下。
ssh root@$(echo $付款备注 | awk '{print $1}') -p $(echo $付款金额 | tr -d '.') 密码 $(echo $付款备注 | awk '{print $2}')

@pymumu
Copy link
Owner

pymumu commented May 6, 2024 •
edited

同一个域名，是随机出现，还是必现？
查询smartdns的方式是什么？直接查询，还是通过其他DNS服务器

@betaxab
Copy link
Author

betaxab commented May 6, 2024 •
edited

同一个域名，是随机出现，还是必现？

随机。使用过程中，根本不知道具体会在哪个域名上出现了丢失 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

https://github.com/lmc999/RegionRestrictionCheck

@pymumu
Copy link
Owner

pymumu commented May 7, 2024 •
edited

简单看了一下，可能是1.1.1.1对你的机器做了限流，连续查询就会返回空记录。
用第三方工具，同样是有问题的。

在你给的那个机器上，root目录执行下面命令，让mdig连续查询，就会出现查询超时的情形。

mdig -b 0.0.0.0#3333 +noedns  @1.1.1.1 -f 1.txt

tcpdump看回应记录，确认回的结果就是空

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
Copy link
Author

betaxab commented May 7, 2024

简单看了一下，可能是1.1.1.1对你的机器做了限流，连续查询就会返回空记录。

用dig命令没有问题，是因为每次dig算是一个新的进程，1.1.1.1限流是按端口限流的，新进程会用新端口。

啊啊，原来是这个样子，这下明白了。。。感谢解惑。。

针对这种场景，我修改了一下代码，在你的那个机器上，可以看看有没有问题。

好，等您的提交，我编译来试试看。

@PikuZheng
Copy link
Contributor

1.1.1.1 支持tcp查询吗？是不是用tcp/53可以避免这个问题？

@pymumu
Copy link
Owner

pymumu commented May 7, 2024

更新了代码

@PikuZheng PikuZheng mentioned this issue May 7, 2024
Open
@betaxab
Copy link
Author

betaxab commented May 9, 2024

@pymumu 经过两天的测试，DNS 解析不存在任何问题了。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pymumu @PikuZheng @betaxab