domain-list-community
domain-list-community copied to clipboard
v2fly
关于域名分类数据的讨论
geolocation-cn 文件里有这么一段话：
# The following domains are carried over from geosite:cn.# TODO: Decide how to deal with these domains
这下面的域名没有分类，只是按照字典序排列在一起，其实是非常不利于利用和维护的。
首先很多时候数个域名其实都归属于同一个平台，硬按照字典序打乱了夹在其他域名中间——不利于阅读分析，且在这个服务/平台下线的时候可能会删不干净，这是维护上的困难（本来这么庞大的列表就应该包含了很多访问量极小的站点，里面有些站也许只是昙花一现）
其次现在 @attr 还没有得到充分的应用，未来如果这个数据库进一步扩展，那这里提到的未分类域名都将非常不适合就地添加上 @attr（试想当你只想屏蔽某一特定平台的广告，结果这个平台的域名放在了 geolocation-cn 下，和其他被打了 @ads 属性的未分类域名混在一起）——这是利用上的困难
所以我觉得让 geolocation-cn 下尽量多一些 include:，少一些未分类域名，是最好的发展方向——而这就是我希望拿出来讨论的点了，因为其实就在刚才我的一个 PR#25 才得到了滥用分类的评价，所以这里一定是有协作者之间的看法差异的。
希望能早点讨论出一个共识，避免在需要拐弯的时候给已经十分庞大的历史遗留问题进一步「添砖加瓦」。
我觉得我这个倡议不利于执行的一点在于目前 main.go 域名去重的能力非常羸弱——算了实话说吧，我觉得就是没有（
我参与贡献的另外几个类似的项目，有 dnscrypt-proxy 下的域名黑名单，也有 @felixonmars/dnsmasq-china-list，还有 @Loyalsoldier/v2ray-rules-dat
在我看来这三者都很快实现了较完善的域名去重功能，而这一功能在本项目中发挥作用的场景包括不同分类下域名会有重叠的问题。
举例来说该项目已经有一个 netease 的分类数据，今天我再去做一个 category-mooc-cn 的分类数据，study.163.com 域名我是加还是不加？ 除了这样目前还没有规定下来的原则问题，这个例子里还在要求贡献者自己人脑去重一遍，很不友好，而且也违背了这个项目给域名分类的初衷。
那如果要把上述的几点都抓全，就势必得接受分类后的域名互相之间存在重叠的问题——我担心这个重叠以后会越发展越厉害，而 geosite.dat 无谓的肥大也许会影响匹配效率、肯定会影响更新用时、说不定会妨碍在单片机上玩 v2ray 的用户流畅体验。
首先很多时候数个域名其实都归属于同一个平台，硬按照字典序打乱了夹在其他域名中间——不利于阅读分析，且在这个服务/平台下线的时候可能会删不干净，这是维护上的困难（本来这么庞大的列表就应该包含了很多访问量极小的站点，里面有些站也许只是昙花一现）
当初 geolocation-!cn 也是像 geolocation-cn 一样乱糟糟的，所以非常欢迎为 geolocation-cn 进行分类并提交 PR。不是不能新建 category 分类，而是建议先在 geolocation-cn 内部进行分类，当一个分类里域名数量累计得足够成为一个类别的时候（十几二十个），再独立出来比较合适，否则就是滥用 category 了。
另外，@attr 现在似乎有 bug，而且目前似乎 v2ray-core 并没有人力关注这个 bug，导致优先级不高（我是乐于修复这个 bug，但是看核心源码不是那么容易上手，一时半会也解决不了）。
我觉得我这个倡议不利于执行的一点在于目前 main.go 域名去重的能力非常羸弱
域名去重的问题，我晚点处理。
不是不能新建
category分类，而是建议先在geolocation-cn内部进行分类，当一个分类里域名数量累计得足够成为一个类别的时候（十几二十个），再独立出来比较合适
同意这一句，所以先收集再分类好了，已经分类的就保留。
一些提议：
何种情况下某主题应建立其列表：
-
企业和组织应拥有其列表。子公司列表应包含在母公司列表中。
-
域名数量在20个以上才应建立对应分类。
列表名称：
-
category-cn-*及category-!cn-*比category-*-cn及category-*-!cn更易于维护。 -
仅于名称与其属性之间使用连字符。若企业或组织的名称多余一个单词，不使用连字符。
例如category-cn-dinner、archiveofourown和atom-data-ads。（如果名称原本就拥有连字符，可弹性处理）
列表格式：
-
使用评论和标签对不同服务或项目进行分类。
-
列表之初为
include:，顶级域名其次，keyword:和domain:居中，regex:和full:随后。不属于列表实体的CDN域名放置于列表末尾。 -
以字母表顺序排列，包括评论和标签。（可对特殊情况弹性处理）
-
应允许添加子域名以对不同服务或项目进行分类。
例如：
include:category-!cn-fish
include:category-!cn-meat
# TLDs
drink
food
# Drink
chocolate.com
coffee.com
# Food
dumpling.com
pasta.com
# Fruit
fruit.com @fruit
fruit.com.vegan @fruit
## Apple
apple.fruit.com @apple @fruit
## Banana
banana.fruit.com @banana @fruit
# Vegetable
vegetable.com
vegetable.com.vegan
regex:^drink-cdn\d\.akamaized\.net$
regex:^food-cdn\d\.akamaized\.net$
full:drink-delivery.akamaized.net
full:food-delivery.akamaized.net
欢迎各位提出建议。
更多讨论内容 https://github.com/v2fly/domain-list-community/pull/88 和 https://github.com/v2fly/domain-list-community/issues/91
如果我们以中国大陆境内用户作参考.
如果以接入点 IP 分类大致可以分成如下 4 种情况:
- 仅有中国接入点. 毫无疑问归类于
geolocation-cn
中国 DNS -> 中国 IP
境外 DNS -> 中国 IP
- 仅有境外接入点. 无论是否可以直连, 我们都应当将其归类于
geolocation-!cn
域名 -> 中国 DNS -> 境外 IP
域名 -> 境外 DNS -> 境外 IP
- 境内外均有接入点且境外接入点可直连.
域名 -> 中国 DNS -> 中国 IP
域名 -> 境外 DNS -> 境外 IP (可直连)
- 境内外均有接入点但境外接入点不可直连.
域名 -> 中国 DNS -> 中国 IP
域名 -> 境外 DNS -> 境外 IP (不可直连)
也有可能存在其他情况, 例如中国 DNS 解析出境外 IP 但境外 DNS 解析出中国 IP. ~~(这种情况是域名管理者故意搞事儿我们就不算在内了...)~~
1 和 2 如何分类没什么问题, 但 3 和 4 我们应当如何处理?
因为每一个用户处理 DNS 解析的方式都不同, 且用户的需求不同. 3 和 4 分类有误的话可能会造成不同的问题.
如果以公司主体所属国家分类大致可以分成如下 4 种情况:
- 属于 中国公司 且 主要对中国提供服务 的域名 ⇒
geolocation-cn - 属于 中国公司 但 主要对境外提供服务 的域名 ⇒
? - 属于 境外公司 但 提供中国接入点 的域名 ⇒
?- 且境外接入点可直连
- 但境外接入点不可直连
- 属于 境外公司 且 不提供中国接入点 的域名 ⇒
geolocation-!cn
2 和 3 我们应当如何分类?
2 是否应当被 1 的公司列表 include:? (例 alibabacloud)
3.1 由于某些公司对不同 IP 的用户提供不同的服务内容, 需要做区分.
3.2 由于用户 DNS 解析处理方式不同, 可能会引起问题, 需要做区分.
属于 中国公司 但 主要对境外提供服务 的域名 ⇒
?
无论连接点情况如何，都应该包含在其公司列表中，并且根据 #91 的讨论结果，使用@!cn或新建列表进行区分，提供geolocation-cn@!cn或list-!cn用于路由规则。
属于 境外公司 但 提供中国接入点 的域名 ⇒
?且境外接入点可直连
不太熟悉“某些公司对不同 IP 的用户提供不同的服务内容”这种使用场景。但如此前回复，我曾设想本项目应允许添加子域名，并使用评论和标签区分不同服务，以针对服务选择对应的路由规则。如data/apple中可包含music.apple.com @music、mail.me.com @mail、developer.apple.com @dev等。
在@attr尚未修复时，data/apple-dev就是起到类似功能的列表，其域名虽然提供大陆连接点，但速度较慢，因此单独独立成列表进行比较灵活的路由配置。
https://github.com/v2fly/domain-list-community/blob/cb6080a3c0696115b4fe144a814b9fd082c93a09/data/apple-dev#L6-L15
如今我建议，默认包含在geolocation-!cn中，以@cn标记或新建列表进行区分，提供geolocation-!cn@cn或list-cn用于路由规则。
属于 境外公司 但 提供中国接入点 的域名 ⇒
?但境外接入点不可直连
与第3种情况相同，并且不额外包含在geolocation-cn中，避免出现连接问题。
在维护域名分类的时候我还是遇到了一些问题，我认为有必要讨论一下。
根据 #91 可以为域名提供 @cn 或者 @!cn 的属性，但是也有一些仅靠地理属性无法区分开的情况。
我举个例子来说明。
某中国境外VPS -> 境外IP
root@debian~# dig i0.hdslb.com.cdn20.com @8.8.8.8
; <<>> DiG 9.16.8-Debian <<>> i0.hdslb.com.cdn20.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59254
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;i0.hdslb.com.cdn20.com. IN A
;; ANSWER SECTION:
i0.hdslb.com.cdn20.com. 59 IN A 157.185.146.132
;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Dec 13 09:12:00 UTC 2020
;; MSG SIZE rcvd: 67
某中国境内机器 -> 境内IP
root@ubuntu:~$ dig i0.hdslb.com.cdn20.com @223.5.5.5
; <<>> DiG 9.16.1-Ubuntu <<>> i0.hdslb.com.cdn20.com @223.5.5.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21956
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;i0.hdslb.com.cdn20.com. IN A
;; ANSWER SECTION:
i0.hdslb.com.cdn20.com. 56 IN A 218.1.70.82
i0.hdslb.com.cdn20.com. 56 IN A 115.223.11.151
i0.hdslb.com.cdn20.com. 56 IN A 59.63.80.118
i0.hdslb.com.cdn20.com. 56 IN A 115.223.12.46
i0.hdslb.com.cdn20.com. 56 IN A 58.221.32.29
i0.hdslb.com.cdn20.com. 56 IN A 59.54.253.76
i0.hdslb.com.cdn20.com. 56 IN A 122.228.237.75
i0.hdslb.com.cdn20.com. 56 IN A 58.222.45.12
;; Query time: 15 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: 日 12月 13 17:23:00 CST 2020
;; MSG SIZE rcvd: 168
同样的域名DNS给出的解析分别来自境外和境内，在这种情况下仅仅添加 @cn 或者 @!cn 似乎并不能很好的让用户选择最好的方式来连接。
并且在很多的时候，维护者其实很难去判断一个 CDN 域名是否同时能提供境外和境内两种接入点。
针对这样的域名，我们无法从域名来确定最好的接入方式。最好是交由本地的DNS来解析，仅通过路由规则来进行分类。
针对这个问题，我认为增加 @local 和 @remote 这样一对 attr 比较合适。
语义上 @local 代表应该交由本地 DNS 解析
@remote 代表应该交由远程 DNS 来解析
如果增加这样的一对 attr 无论用户的地理位置如何，都可以交由本地 DNS 来确定最合适的连接方式。
不知道大家对这个问题有什么样的看法？
只对域名分类，不表达该如何使用 所以我认为适用于所属公司的地理位置
我理解要维持主要分类方法的必要性，但显然我们遇到了一些问题。 项目本身虽然要求不应该指示或者暗示某个域名应该被代理或者屏蔽，但是项目的目标始终是根据需要生成正确的路由。
目前针对一部分域名只单纯的按照单一地理位置分类无法准确的生成路由。
比如： 中国银行系列的网站
中国银行官网 -> 指向大陆服务器
中银香港 -> 指向香港服务器
目前版本中对于这两个域名的处理方法只有
include:boc
这样的处理显然是有一些问题的。
#256 提出了这样的解决方案
boc:
boc.cn @cn
bochk.com @hk
geolocation-cn:
include:boc@cn
geolocation-!cn:
include:boc@!cn
但是似乎目前没有实装，并且其实无法处理CDN上遇到的问题。
就像我之前提到的例子一样。
处理cdn20.com这样的域名的时候，这个域名属于大陆企业，拥有大陆的接入点，但同时也有境外的接入点（不止一处）。
单纯的处理为
cdn20.com @cn
这或许对大陆用户是合乎常理的选择，但是境外用户在生成使用路由的时候，就只能放弃境外的接入点绕回大陆的接入点。
这样处理路由是不够准确的。
目前实际上@cn是一个很模糊的概念，并不是单纯指企业的地理位置，也包括服务器有一个甚至多个在大陆的意思。
针对这个问题我觉得需要有所改善。
@attr这种解决方案的出现，按照我的理解attr应该是可以有多个的，既同一个域名可以有多种不同的属性存在。
所以我觉得可以单纯的把@cn明确为企业所在地，对于在多国存在很多接入点的域名，可以增加一个属性来描述存在多国接入点。
之前我提出增加@local和@remote这么一对属性也是出于解决问题的需要，并且增加@attr也不会破坏现有的按照地理位置域名分类结构。
如果认为@local过于暗示操作方向，那么也可以更换一些其他词汇。
比如：
@route : 交由后续路由处理此域名。
@anycast : 表示域名存在多个国家的接入点。
处理cdn20.com这样的域名的时候就可以写成
wangsu:
cdn20.com @cn @anycast
geolocation-cn:
include:wangsu@cn
include:wangsu@anycast
geolocation-!cn:
include:wangsu@anycast
我认为如果这样处理的话对于生成路由是非常有帮助的，后续如果要考虑兼容更多的用法也会比较有利，所以我觉得不妨来讨论一下。
多(混合)属性是个很好的方向，虽然目前不清楚对性能的影响，但值得一试
我们需要选一些标签名
性能方面的话，我是认为产生的开销都在生成路由的时候，处理一个@cn和同时处理更多的标签带来的开销应该是没有区别很大，毕竟我们也不可能真添加几百种属性。
而且导出的时候也可以加上命令行参数只生成具有某种attr的路由，所以性能我觉得应该不是一个大问题。
我这边的话是建议
@anycast 代表具有多国接入点的意思
如果要考虑兼容GFWList之类的用法，也可以考虑加上
@gfw 代表域名被GFW污染
支持多(混合)属性。
然后引用资源就可以成这样了 geosite:!cn&ads geosite:google|apple|facebook。想要哪些域名，可以根据 attr 自由拼凑。
pb 的country_code分类也可以去除了，只保留 attr 标签。反正现在分类已经不是country code了。这样其他程序使用资源也方便了。
虽然目前不清楚对性能的影响，但值得一试
除了载入时会稍微慢一点点，(理论上会，但实际上无法察觉)，运行时性能应该不会有格外影响。
多(混合)属性是个很好的方向，虽然目前不清楚对性能的影响，但值得一试 我们需要选一些标签名
性能方面的话，我是认为产生的开销都在生成路由的时候，处理一个
@cn和同时处理更多的标签带来的开销应该是没有区别很大，毕竟我们也不可能真添加几百种属性。而且导出的时候也可以加上命令行参数只生成具有某种attr的路由，所以性能我觉得应该不是一个大问题。
我这边的话是建议
@anycast 代表具有多国接入点的意思如果要考虑兼容GFWList之类的用法，也可以考虑加上
@gfw 代表域名被GFW污染
@cn
@!cn
@anycast
@gfw
@ads
I think these several attributes are good enough. And we need manpower to apply these attributes to the rules.
只有1个域名的文件应当合并到同一个文件，当超过规定数量(e.g. 5)即分离到独立文件。
other-!cn
domain:example.com @example
other-cn
domain:example.cn @example @cn
root@ubuntu:~$ dig i0.hdslb.com.cdn20.com @223.5.5.5
; <<>> DiG 9.16.1-Ubuntu <<>> i0.hdslb.com.cdn20.com @223.5.5.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21956 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;i0.hdslb.com.cdn20.com. IN A
;; ANSWER SECTION: i0.hdslb.com.cdn20.com. 56 IN A 218.1.70.82 i0.hdslb.com.cdn20.com. 56 IN A 115.223.11.151 i0.hdslb.com.cdn20.com. 56 IN A 59.63.80.118 i0.hdslb.com.cdn20.com. 56 IN A 115.223.12.46 i0.hdslb.com.cdn20.com. 56 IN A 58.221.32.29 i0.hdslb.com.cdn20.com. 56 IN A 59.54.253.76 i0.hdslb.com.cdn20.com. 56 IN A 122.228.237.75 i0.hdslb.com.cdn20.com. 56 IN A 58.222.45.12
;; Query time: 15 msec ;; SERVER: 223.5.5.5#53(223.5.5.5) ;; WHEN: 日 12月 13 17:23:00 CST 2020 ;; MSG SIZE rcvd: 168 DNS
