domain-list-community
domain-list-community copied to clipboard
v2fly
Community managed domain list. Generate geosite.dat for V2Ray.
There are some non-standard domains in [`private`](https://github.com/v2fly/domain-list-community/blob/20220813040114/data/private). How about creating new categories (some possible keywords: `non-standard`, `internal`, `router`, `connectivity-check`) for them and keeping the [original purpose](https://github.com/v2fly/domain-list-community/commit/9dee54e2e47338fa95b81319759aae0e890b7f6f) (?) of `private`? :thinking:...
首先 `services.googleapis.cn` 这个域名会被 `domain:cn` 这条记录兜底，所以在我看来解决问题的思路只有一种，那就是标记这个域名进黑名单（e.g. `@gfw`）。以此来保证下游代理软件使用本项目的规则时，会代理这个域名。 我不希望改变 `domain:googleapis.cn` 的标记，正如 Issue #398 里的检测结果展示的那样，应该可以认定这个域名及其子域名的记录都是国内的 IP。 所以这就导致合理的标记 `services.googleapis.cn` 的结果变成这样： ``` full:services.googleapis.cn @cn @gfw ``` 这样的域名记录目前无法被 geosite.dat 的生成过程很好地处理，所以期待社区其他人的建议。
关于域名分类数据的讨论
`geolocation-cn` 文件里有这么一段话： > `# The following domains are carried over from geosite:cn.` > `# TODO: Decide how to deal with these domains` 这下面的域名没有分类，只是按照字典序排列在一起，其实是非常不利于利用和维护的。 首先很多时候数个域名其实都归属于同一个平台，硬按照字典序打乱了夹在其他域名中间——不利于阅读分析，且在这个服务/平台下线的时候可能会删不干净，这是维护上的困难（本来这么庞大的列表就应该包含了很多访问量极小的站点，里面有些站也许只是昙花一现） 其次现在 `@attr` 还没有得到充分的应用，未来如果这个数据库进一步扩展，那这里提到的未分类域名都将非常不适合就地添加上 `@attr`（试想当你只想屏蔽某一特定平台的广告，结果这个平台的域名放在了 `geolocation-cn` 下，和其他被打了...
The following line should not be included by default, as it could ruin the out-of-box experience for the people who most likely need this category. Fix #674
我在 issues #28 中提出了基于多种 attr 共存的想法。 现在过了一段时间，我认为从讨论结果上看，社区整体对多种 attr 共存的方案接受程度比较高，我们基本上可以达成共识。 同时为了更好的实践多重属性的方案，```include```语法势必要进行扩展。 如同 issues #256 中提到的语法扩展方案。 只不过我个人认为 ```include:filename@attribute``` 这样的语法还是略有不足。 我个人认为改为 ``` include:filename @attribute1 @attribute2``` 这样的形式会更加灵活，也更简单。 那么为了实践多重属性的方案，我在这里想重新归纳整理一下对于 ```@attr``` 语法的改变，同时我会提出 PR 来实践。 1. 支持为一个域名设置多种属性...
我昨天实现了将 `geolocation-cn` 完全展开，将 include 的各级子分类数据写回 `geolocation-cn` 文件的代码。 我想先请教大家的意见，看这样生成的域名列表是否要发布出来（考虑到其他人也许可以拿去转 PAC 或者别的什么用途），还是说仅作为定时校验时的中间文件，不发布。 然后有了共同的决定以后，还需要有人实现一下调用现有的域名备案信息 API，验证展开后的 `geolocation-cn` 文件中，是否包含查询不到备案信息的域名。（然后一种可能的处理方式是产生提示，让维护者审阅，决定是否删除） PR #53 里就可以看到之前 `geolocation-cn` 是错误包含了不该包含的域名的，我觉得这种事不能完全依赖人工检验，自动化检验势在必行。
重构构建流程并添加新功能
随着本项目的成长和影响力的扩大，在过去一年左右的时间里，本项目出现了几个问题： - `@cn` 属性的存在，导致 `geolocation-!cn` 类别里出现了很多“大陆域名”（隶属于非大陆企业，但在大陆有接入点的域名） - 每个列表的域名规则无法去重（如 `geolocation-!cn` 包含大量顶级域，可以通过树去重，以减少生成文件的体积） 现在此提议，在构建流程中引入多种选项和特性： - 自动按优先级查找 `data` 文件夹的位置（命令行选项） - 可自定义生成文件的输出目录（命令行选项） - 可自定义用哪个列表来生成 `gfwlist.txt` 文件（命令行选项。`geolocation-cn` 或者 `cn` 即为白名单，`geolocation-!cn` 即为黑名单） - 可自定义去除带有特定属性的规则（命令行选项）：生成文件时，去除带有某些特定属性的规则，如：`geolocation-!cn` 列表去除 `@cn` 属性的规则；`geolocation-cn`...
