dirty组的ecs存在问题 #21

weargle · 2020-05-09T13:58:57Z

我将github.com这个域名使用dirty组解析，然后在该组中添加ecs参数，使用wget获取tsdns压缩包的时候回提示未知的服务，在去掉ecs参数后能正常下载。
wget https://github.com/wolf-joe/ts-dns/releases/download/v0.13.1/ts-dns_0.13.1_Linux_x86_64.tar.gz --2020-05-09 21:54:38-- https://github.com/wolf-joe/ts-dns/releases/download/v0.13.1/ts-dns_0.13.1_Linux_x86_64.tar.gz 正在解析主机 github.com (github.com)... 失败：未知的名称或服务。 wget: 无法解析主机地址 “github.com”

dirty组参数

[groups.dirty]  # 必选分组，匹配GFWList的域名会归类到该组
  ecs = "1.2.3.0/24"
  dns = ["8.8.8.8", "1.1.1.1"]  # 如不想用socks5代理解析时推荐使用国外非53端口dns
  dot = ["1.0.0.1:853@cloudflare-dns.com"]  # dns over tls服务器
  rules = [""]

The text was updated successfully, but these errors were encountered:

wolf-joe · 2020-05-09T23:52:08Z

没有复现，请给出ts-dns运行日志。

weargle · 2020-05-10T02:39:40Z

失败运行截图

测试发现还有一种情况就是，从github.com域名成功的重定向到github-production-release-asset-2e65be.s3.amazonaws.com域名后也发生失败。

wget https://github.com/wolf-joe/ts-dns/releases/download/v0.13.1/ts-dns_0.13.1_Linux_x86_64.tar.gz
--2020-05-10 10:26:10--  https://github.com/wolf-joe/ts-dns/releases/download/v0.13.1/ts-dns_0.13.1_Linux_x86_64.tar.gz
正在解析主机 github.com (github.com)... 140.82.114.4
正在连接 github.com (github.com)|140.82.114.4|:443... 已连接。
已发出 HTTP 请求，正在等待回应... 302 Found
位置：https://github-production-release-asset-2e65be.s3.amazonaws.com/245324690/15c50c00-9222-11ea-862c-d2c28b1ad609?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200510%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200510T022612Z&X-Amz-Expires=300&X-Amz-Signature=d4f1ed8b34e02f15af9eed8ababb0b4406bc1cfe06cf4c7891548a5650f2a1ba&X-Amz-SignedHeaders=host&actor_id=0&repo_id=245324690&response-content-disposition=attachment%3B%20filename%3Dts-dns_0.13.1_Linux_x86_64.tar.gz&response-content-type=application%2Foctet-stream [跟随至新的 URL]
--2020-05-10 10:26:12--  https://github-production-release-asset-2e65be.s3.amazonaws.com/245324690/15c50c00-9222-11ea-862c-d2c28b1ad609?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200510%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200510T022612Z&X-Amz-Expires=300&X-Amz-Signature=d4f1ed8b34e02f15af9eed8ababb0b4406bc1cfe06cf4c7891548a5650f2a1ba&X-Amz-SignedHeaders=host&actor_id=0&repo_id=245324690&response-content-disposition=attachment%3B%20filename%3Dts-dns_0.13.1_Linux_x86_64.tar.gz&response-content-type=application%2Foctet-stream
正在解析主机 github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)... 失败：未知的名称或服务。
wget: 无法解析主机地址 “github-production-release-asset-2e65be.s3.amazonaws.com”

重定向成功后运行截图

weargle · 2020-05-10T03:05:44Z

完整的debug图

wolf-joe · 2020-05-10T04:06:44Z

完整的debug图

从这个日志上来看，dirty组的上游dns应该是45.90.28.135:5353。向这个dns转发了github.com的请求后出现超时错误，所以返回空。我用这个dns时并没有出现超时错误，所以没有复现。

weargle · 2020-05-10T04:40:06Z

完整的debug图

从这个日志上来看，脏组的上游DNS应该是45.90.28.135:5353。向这个DNS了转发github.com的请求后出现超时错误，所以返回空。我用这个DNS时并没有出现超时错误，所以没有复现。

测试几次dirty组没有ecs参数DNS45.90.28.135:5353没有超时情况，一旦添加会出现超时情况。

dirty组添加ecs参数的debug图

去除ecs参数的debug图

weargle · 2020-05-10T04:45:10Z

你这篇关于DNSPOD公共DNS网络连接的问题文章我试了dig @119.29.29.29 ip.cn能正常返回数据的
图

wolf-joe · 2020-05-10T04:55:19Z

你这篇关于DNSPOD公共DNS网络连接的问题文章我试了dig @119.29.29.29 ip.cn能正常返回数据的
图

不确定是网络原因还是软件原因，你这个正常返回的请求里没有包含dns cookie，而我在dig时是会发送dns cookie到dnspod的。

weargle · 2020-05-10T05:07:39Z

你这篇关于DNSPOD公共DNS网络连接的问题文章我试了dig @119.29.29.29 ip.cn能正常返回数据的
图

不确定是网络原因还是软件原因，你这个正常返回的请求里没有包含dns cookie，而我在dig时是会发送dns cookie到dnspod的。

盲猜你的vps的不是境内云服务器，拿香港的测试发现有概率出现这种情况。

rampageX · 2020-05-10T05:17:09Z

你这篇关于DNSPOD公共DNS网络连接的问题文章我试了dig @119.29.29.29 ip.cn能正常返回数据的
图

不确定是网络原因还是软件原因，你这个正常返回的请求里没有包含dns cookie，而我在dig时是会发送dns cookie到dnspod的。

盲猜你的vps的不是境内云服务器，拿香港的测试发现有概率出现这种情况。

正常编译的 dig, 9.11+ 都是默认启用 cookie 的，你这个 redhat 下面的 dig 应该是自定义了编译参数加了 nocookie 编译的。而 ts-dns 目前是不能去掉 cookie 的，119 这个服务器只要带 cookie 查询 99% 是要失败的。结论很简单，目前你用 ts-dns 就不要用 119 做上游。

weargle · 2020-05-10T05:23:48Z

你这篇关于DNSPOD公共DNS网络连接的问题文章我试了dig @119.29.29.29 ip.cn能正常返回数据的
图

不确定是网络原因还是软件原因，你这个正常返回的请求里没有包含dns cookie，而我在dig时是会发送dns cookie到dnspod的。

盲猜你的vps的不是境内云服务器，拿香港的测试发现有概率出现这种情况。

正常编译的dig，9.11+都是已启用cookie的，你这个redhat下面的dig应该是自定义了编译参数加了nocookie编译的。而ts-dns目前是不能去掉cookie的，119这个服务器只要带cookie查询99％是要失败的。某些很简单，目前你用ts-dns就不要用119做上游。

好，还有dig是使用yum安装的，没有手动下载编译安装，overture不是可以设置使用不使用cookie吗，你可以看下。如果上面那个问题实在没法复现就这样吧，我在我的上游dns加上ecs就行。

wolf-joe · 2020-05-10T05:30:55Z

找到原因了，是我在添加ecs信息没有完全遵守edns规范，在部分情况下碰到格式要求严格的dns服务器会出问题。
bug将在下个版本修复。

wolf-joe · 2020-05-10T07:08:23Z

v0.14.0发布，修复v0.11.0以来的默认添加ecs相关bug、增加no_cookie选项以兼容DNSPod(119.29.29.29)。

weargle · 2020-05-10T08:51:27Z

使用最新版的dirty组的ecs参数问题修复了。请教下no_cookie参数怎样看出有没有作用，根据我的实验发现两者好像没有差别，119DNS都是超时情况。

clean组no_cookie参数分别设置false/true各一次，使用dig请求baidu.com、bilibili.com
false的时候图

true的时候图

wolf-joe · 2020-05-10T09:45:10Z

使用最新版的dirty组的ecs参数问题修复了。请教下no_cookie参数怎样看出有没有作用，根据我的实验发现两者好像没有差别，119DNS都是超时情况。

clean组no_cookie参数分别设置false/true各一次，使用dig请求baidu.com、bilibili.com
false的时候图

true的时候图

那就应该是网络问题吧……我这边测试是正常的。

[groups]
  [groups.clean]
  no_cookie = true
  dns = ["119.29.29.29"]

time="2020-05-10T17:41:33+08:00" level=debug msg="question: [{ip.cn. 1 1}], extract: [\n;; OPT PSEUDOSECTION:\n; EDNS: version 0; flags: ; udp: 4096\n; COOKIE: 99c249055b816311]"
time="2020-05-10T17:41:33+08:00" level=debug msg="forward question [{ip.cn. 1 1}] to &{0xc000168000 119.29.29.29:53 <nil> 0xc00006af00}"
time="2020-05-10T17:41:33+08:00" level=info msg="not match gfwlist" domain=ip.cn. group=clean src=192.168.50.10 type=A
time="2020-05-10T17:41:33+08:00" level=debug msg="response: [ip.cn.\t326\tIN\tA\t198.41.215.99 ip.cn.\t326\tIN\tA\t104.16.25.99 ip.cn.\t326\tIN\tA\t198.41.214.99]"

[groups]
  [groups.clean]
  no_cookie = true
  ecs = "1.1.1.1"
  dns = ["119.29.29.29"]

time="2020-05-10T17:43:09+08:00" level=debug msg="question: [{ip.cn. 1 1}], extract: [\n;; OPT PSEUDOSECTION:\n; EDNS: version 0; flags: ; udp: 4096\n; COOKIE: cdb1c0309303dcd3]"
time="2020-05-10T17:43:09+08:00" level=debug msg="set default ecs 1.1.1.1/32/0 to msg"
time="2020-05-10T17:43:09+08:00" level=debug msg="forward question [{ip.cn. 1 1}] to &{0xc0001b0000 119.29.29.29:53 <nil> 0xc00008cf00}"
time="2020-05-10T17:43:09+08:00" level=info msg="not match gfwlist" domain=ip.cn. group=clean src=192.168.50.10 type=A
time="2020-05-10T17:43:09+08:00" level=debug msg="response: [ip.cn.\t491\tIN\tA\t198.41.214.99 ip.cn.\t491\tIN\tA\t198.41.215.99 ip.cn.\t491\tIN\tA\t104.16.25.99]"

weargle · 2020-05-10T14:47:16Z

使用最新版的dirty组的ecs参数问题修复了。请教下no_cookie参数怎样看出有没有作用，根据我的实验发现两者好像没有差别，119DNS都是超时情况。
clean组no_cookie参数分别设置false/true各一次，使用dig请求baidu.com、bilibili.com
false的时候图

true的时候图

那就应该是网络问题吧……我这边测试是正常的。

[groups]
  [groups.clean]
  no_cookie = true
  dns = ["119.29.29.29"]

time="2020-05-10T17:41:33+08:00" level=debug msg="question: [{ip.cn. 1 1}], extract: [\n;; OPT PSEUDOSECTION:\n; EDNS: version 0; flags: ; udp: 4096\n; COOKIE: 99c249055b816311]"
time="2020-05-10T17:41:33+08:00" level=debug msg="forward question [{ip.cn. 1 1}] to &{0xc000168000 119.29.29.29:53 <nil> 0xc00006af00}"
time="2020-05-10T17:41:33+08:00" level=info msg="not match gfwlist" domain=ip.cn. group=clean src=192.168.50.10 type=A
time="2020-05-10T17:41:33+08:00" level=debug msg="response: [ip.cn.\t326\tIN\tA\t198.41.215.99 ip.cn.\t326\tIN\tA\t104.16.25.99 ip.cn.\t326\tIN\tA\t198.41.214.99]"

[groups]
  [groups.clean]
  no_cookie = true
  ecs = "1.1.1.1"
  dns = ["119.29.29.29"]

time="2020-05-10T17:43:09+08:00" level=debug msg="question: [{ip.cn. 1 1}], extract: [\n;; OPT PSEUDOSECTION:\n; EDNS: version 0; flags: ; udp: 4096\n; COOKIE: cdb1c0309303dcd3]"
time="2020-05-10T17:43:09+08:00" level=debug msg="set default ecs 1.1.1.1/32/0 to msg"
time="2020-05-10T17:43:09+08:00" level=debug msg="forward question [{ip.cn. 1 1}] to &{0xc0001b0000 119.29.29.29:53 <nil> 0xc00008cf00}"
time="2020-05-10T17:43:09+08:00" level=info msg="not match gfwlist" domain=ip.cn. group=clean src=192.168.50.10 type=A
time="2020-05-10T17:43:09+08:00" level=debug msg="response: [ip.cn.\t491\tIN\tA\t198.41.214.99 ip.cn.\t491\tIN\tA\t198.41.215.99 ip.cn.\t491\tIN\tA\t104.16.25.99]"

我按照你的配置发现119DNS没有超时了，但ecs参数值写成1.1.1.0/24119DNS就会超时。

DEBU[0019] question: [{bilibili.com. 1 1}], extract: [
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 4096] 
DEBU[0019] set default ecs 1.1.1.1/32/0 to msg          
DEBU[0019] forward question [{bilibili.com. 1 1}] to &{0xc00037acb0 119.29.29.29:53 <nil> 0xc000265a10} 
DEBU[0019] forward question [{bilibili.com. 1 1}] to &{0xc00037ad20 223.5.5.5:53 <nil> 0xc000265a70} 
DEBU[0019] forward question [{bilibili.com. 1 1}] to &{0xc00037ad90 114.114.114.114:53 <nil> 0xc000265ad0} 
INFO[0019] cn/empty ipv4                                 domain=bilibili.com. group=clean src=127.0.0.1 type=A
DEBU[0019] response: [bilibili.com.     112     IN      A       120.92.174.135 bilibili.com.    112     IN      A       139.159.241.37 bilibili.com.    112     IN      A       110.43.34.66 bilibili.com. 112     IN      A       119.3.238.64 bilibili.com.      112     IN      A       119.3.70.188]

DEBU[0023] question: [{bilibili.com. 1 1}], extract: [
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 4096] 
DEBU[0023] set default ecs 1.1.1.0/24/0 to msg          
DEBU[0023] forward question [{bilibili.com. 1 1}] to &{0xc000355420 119.29.29.29:53 <nil> 0xc000267b30} 
DEBU[0023] forward question [{bilibili.com. 1 1}] to &{0xc000355490 223.5.5.5:53 <nil> 0xc000267b90} 
DEBU[0023] forward question [{bilibili.com. 1 1}] to &{0xc000355500 114.114.114.114:53 <nil> 0xc000267bf0} 
INFO[0023] cn/empty ipv4                                 domain=bilibili.com. group=clean src=127.0.0.1 type=A
DEBU[0023] response: [bilibili.com.     73      IN      A       110.43.34.66 bilibili.com.      73      IN      A       119.3.70.188 bilibili.com.      73      IN      A       119.3.238.64 bilibili.com. 73      IN      A       120.92.174.135 bilibili.com.    73      IN      A       139.159.241.37] 
ERRO[0025] query dns error: read udp 172.18.250.225:37709->223.5.5.5:53: i/o timeout 
ERRO[0025] query dns error: read udp 172.18.250.225:58804->119.29.29.29:53: i/o timeout

wolf-joe · 2020-05-15T01:05:38Z

无法复现。我这里无论设置什么ecs都能正常解析。而且ts-dns不会对某个特定ecs做特殊处理，ecs设为A正常、设为B不正常这种情况，个人更倾向于是网络波动造成的。

wolf-joe closed this as completed May 10, 2020

wolf-joe reopened this May 10, 2020

wolf-joe added the bug Something isn't working label May 10, 2020

wolf-joe closed this as completed May 15, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

dirty组的ecs存在问题 #21

dirty组的ecs存在问题 #21

weargle commented May 9, 2020 •

edited

wolf-joe commented May 9, 2020

weargle commented May 10, 2020 •

edited

weargle commented May 10, 2020

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 •

edited

weargle commented May 10, 2020

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 •

edited

rampageX commented May 10, 2020

weargle commented May 10, 2020 •

edited

wolf-joe commented May 10, 2020 •

edited

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 •

edited

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 •

edited

wolf-joe commented May 15, 2020

dirty组的ecs存在问题 #21

dirty组的ecs存在问题 #21

Comments

weargle commented May 9, 2020 • edited

wolf-joe commented May 9, 2020

weargle commented May 10, 2020 • edited

weargle commented May 10, 2020

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 • edited

weargle commented May 10, 2020

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 • edited

rampageX commented May 10, 2020

weargle commented May 10, 2020 • edited

wolf-joe commented May 10, 2020 • edited

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 • edited

wolf-joe commented May 10, 2020

weargle commented May 10, 2020 • edited

wolf-joe commented May 15, 2020

weargle commented May 9, 2020 •

edited

weargle commented May 10, 2020 •

edited

weargle commented May 10, 2020 •

edited

weargle commented May 10, 2020 •

edited

weargle commented May 10, 2020 •

edited

wolf-joe commented May 10, 2020 •

edited

weargle commented May 10, 2020 •

edited

weargle commented May 10, 2020 •

edited