8000 能否增加选项：clean组dns返回IP中包含非CN IP时，直接转发到dirty组dns（略过gfwlist判断步骤）？ · Issue #25 · wolf-joe/ts-dns · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

能否增加选项：clean组dns返回IP中包含非CN IP时，直接转发到dirty组dns（略过gfwlist判断步骤）？ #25

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
Closed
liuxb opened this issue Jun 10, 2020 · 13 comments
Closed

能否增加选项：clean组dns返回IP中包含非CN IP时，直接转发到dirty组dns（略过gfwlist判断步骤）？ #25

liuxb opened this issue Jun 10, 2020 · 13 comments
Labels
enhancement New feature or request

Comments

@liuxb
Copy link
liuxb commented Jun 10, 2020

能否增加一个选项：clean组dns返回IP中包含非CN IP时，直接转发到dirty组dns（略过gfwlist判断步骤）？
为了配合上面选项，建议查询时，clean组dns（筛选出来的最快的那一个）和dirty组dns能进行并发查询，这样，如果解析中包含国外IP，可以直接采用dirty组dns 返回结果。

原有的基于gfwlist的也继续保留，这样配置起来更灵活。

最后，问个配置的问题
[groups.dirty] 这一项下面支持不支持concurrent，rules，rules_file啊？因为看到ts-dns-full.toml中没有写，只是[groups.clean]中有。

谢谢。
@wolf-joe
Copy link
Owner

关于配置：所有group的配置都是通用的。ts-dns-full.toml只是示例。
关于dirty组dns同时查询：clean组dns设为国内公共dns时，查询成本只有几十毫秒甚至几毫秒，我觉得同时查询dirty组dns带来的效果并不明显。

@liuxb
Copy link
Author
liuxb commented Jun 11, 2020

明白了。
另外，能不能出32位版的，windows的32位版本的？
谢谢。

@gubiao
Copy link
gubiao commented Jun 18, 2020

建议gfwlist为可选项.
目前我的做法：
gfwlist_b64 = false
echo '||*' > gfwlist.txt

@zdm9981
Copy link
zdm9981 commented Nov 5, 2020 •
edited
Loading

问下如果一个被污染域名未被添加到gfwlist中,如何配置可以让其自动使用境外dns解析?

@wolf-joe
Copy link
Owner
wolf-joe commented Nov 9, 2020

问下如果一个被污染域名未被添加到gfwlist中,如何配置可以让其自动使用境外dns解析?

将其加到dirty组的rules内

@kousyougi
Copy link
kousyougi commented Dec 13, 2020 •
edited
Loading

问下如果一个被污染域名未被添加到gfwlist中,如何配置可以让其自动使用境外dns解析?

将其加到dirty组的rules内

请问可不可以新加一个功能：
非dirty组 时，查询境内DNS。查回来不是CNIP 的话，跟 port 443 握手检查证书(直连)。
　证书检查(直连)成功的话，加进不检查证书的cahce，下次查询时不检查证书。
　证书检查(直连)失败的话，就暂用dirty组解析，解析完走socks5跟port 443 握手检查证书。
　　证书检查(socks5)成功的话，将域名加入dirty组list，下次查询直接走dirty组。
　　证书检查(socks5)失败的话，解析结果为原始境内DNS查询的原IP，加进不检查证书的cahce，下次查询时不检查证书。

简单的说就是遇到外国IP就自动检查443的证书判断要不要加入gfwlist。判断完记录起来，下次不重复判断。

谢谢

@wolf-joe
Copy link
Owner
wolf-joe commented Feb 9, 2021

时隔半年再次诈尸……遇到非CN IP时直接转发到dirty组DNS这个需求已在开发中，将于近期上线。本质上是将gfwlist和CN IP做成两个可配置的DNS重定向器（而不是写死规则）。

@NagaseKouichi
Copy link

时隔半年再次诈尸……遇到非CN IP时直接转发到dirty组DNS这个需求已在开发中，将于近期上线。本质上是将gfwlist和CN IP做成两个可配置的DNS重定向器（而不是写死规则）。

不知道这个功能是否已经上线呢？chinadns等类似的DNS分组器是只要遇到非CN IP就直接使用可信的上游DNS服务器解析结果，这样一些不在gfwlist里面的被污染域名也可以直接防污染（貌似现在国内污染DNS还都是解析到国外的IP），也不需要手动一条一条添加规则。

在路由器上同时使用SSR+和DNS分组器的时候，其实gfwlist里的域名已经会通过SSR+的通道翻墙访问了，不存在污染问题，DNS分组器这时更多是用于不在gfwlist里的域名的防污染。

辛苦大佬了

@fox85
Copy link
fox85 commented Nov 12, 2022

时隔半年再次诈尸……遇到非CN IP时直接转发到dirty组DNS这个需求已在开发中，将于近期上线。本质上是将gfwlist和CN IP做成两个可配置的DNS重定向器（而不是写死规则）。

轻轻催更一下，希望大佬继续更新！谢谢 🍡

@wolf-joe
Copy link
Owner

时隔半年再次诈尸……遇到非CN IP时直接转发到dirty组DNS这个需求已在开发中，将于近期上线。本质上是将gfwlist和CN IP做成两个可配置的DNS重定向器（而不是写死规则）。

轻轻催更一下，希望大佬继续更新！谢谢 🍡

感谢催更，在写了😂

@fox85
Copy link
fox85 commented Nov 25, 2022

时隔半年再次诈尸……遇到非CN IP时直接转发到dirty组DNS这个需求已在开发中，将于近期上线。本质上是将gfwlist和CN IP做成两个可配置的DNS重定向器（而不是写死规则）。

轻轻催更一下，希望大佬继续更新！谢谢 🍡

感谢催更，在写了😂

哈哈，谢谢大佬还在保持更新，期待下一个release的发布

@wolf-joe
Copy link
Owner

即将发布的v1.0版本（#41）将支持这个特性。配置示例：

[groups.clean]
redirector = "oversea_ip2dirty"

[redirectors.oversea_ip2dirty]
# 解析后如发现ip地址不匹配cnip，则重定向到dirty组解析
type = "mismatch_cidr"
rules_file = "cnip.txt"
dst_group = "dirty"

新版本重构了大量代码，配置文件相比v0略有改动，欢迎大家review

@wolf-joe wolf-joe mentioned this issue Nov 30, 2022
Closed
@wolf-joe
Copy link
Owner
77AF wolf-joe commented Dec 7, 2022

v1.0.0已发布

@wolf-joe wolf-joe closed this as completed Dec 7, 2022
@wolf-joe wolf-joe added the enhancement New feature or request label Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@liuxb @gubiao @zdm9981 @fox85 @kousyougi @NagaseKouichi @wolf-joe
0