R. Daneel Olivaw

Resolved in v2fly/domain-list-community#118. You can now use these domains in config file with `geosite:google@cn`.

FYI, usage of some domains can be found in Microsoft Docs: [_Windows 10, version 2004, connection endpoints for non-Enterprise editions_](https://docs.microsoft.com/windows/privacy/windows-endpoints-2004-non-enterprise-editions)

我觉得`geolocation-cn`、`geolocation-!cn`的变更可以留到另一个issue，保留现状、修改定义、新增列表都可以。就构建流程而言这些新增功能可以接受，如果以后用户想要自行构建geosite，应该会用上这些功能。 另外想问一个无关的问题，有办法在配置文件中指定DLC中的所有列表吗？例如`geosite:all`这种特殊值？

抱歉，事务繁忙，没办法及时跟进。 哪怕不更改列表定义，#255 引入的功能也是很实用的，我觉得并没有什么问题，是需要一个人来拍板吗？ > 至于解决生成文件臃肿的问题，有一个方案：趁着 V2Ray 准备发 v5 版的东风，改造 v2ray 的路由系统，以便支持 geosite.dat 内的列表内嵌结构。意为，不需要把每个列表都拍平（不需要展开 include 的规则），直接 include 即可，而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。 考虑到许多用户在空间紧张的设备上使用，geosite文件能瘦身当然是最好的，不知道性能会不会受到影响？ 另外像 v2fly/v2ray-core#237 提到的那样，如果配置文件中有不存在的列表，提示错误后依然能正常启动，那DLC删除/移动列表会少很多束缚。

> 或者不查备案信息，去分析域名的 NS 服务器位置和解析到的 IP 结果也行，https://github.com/felixonmars/dnsmasq-china-list 好像就是这么做的。 我认为这种方法比查备案会更加精准。但都可以在分支中试试，看看哪种更优。

这个处理应该是正确的，`@cn`指的是在中国大陆有接入点，`geolocation-!cn`域名也适用。我也有在路由规则中用到`geosite:geolocation-!cn@cn`。 > ref https://github.com/shadowsocks/shadowsocks-windows/issues/2971 这正是`@cn`希望解决的问题。在配置文件中使用`geosite:blizzard@cn`可以针对这类属于暴雪但又在中国大陆存在接入点的域名进行特殊处理。

> 地理位置既不在也在中国？ 情况是这样的：`geolocation-!cn`依据列表实体的地理位置进行归类，如苹果公司、微软公司、Valve属于美国企业，则`apple`、`microsoft`、`steam`归类于`geolocation-!cn`。然而三者都有不少的域名在中国大陆存在接入点，又鉴于本项目的宗旨是不声明或暗示某一域名是否应该被代理，因此根据 #91 达成的共识，采用`@cn`对这类特例进行了标记，用户可以在路由规则中进行特殊处理，增加配置的灵活度。 然而这一功能争议较大、尚未完善、且如`google`等域名接入点情况容易产生变动，所以没有对这一功能进行宣传，仅供熟悉项目的人士测试使用。如果希望为游戏下载、应用商店下载、系统更新进行分流，可以尝试。 > 对于ss用户来说如何学习利用geosite规则？ 似乎自 #215 起开始生成新文件供其它项目使用了？缓兵之计或许是在生成文件时去除标记有`@cn`的域名。但`geolocation-!cn`与`gfwlist`的定位似乎相差较大。 P.S. 长远来说，我认为一种理想情况是针对所有域名的接入点进行标记，如`@cn`、`@!cn`甚至`@us`、`@hk`、`@sg`等，这样就能提供比`geolocation-cn`、`geolocation-!cn`高得多的精确度和灵活度，可以采用 #54 的提议进行部分自动化标记工作。当然，对工作量的要求或许过高了。

#### 一些提议： 何种情况下某主题应建立其列表： - 企业和组织应拥有其列表。子公司列表应包含在母公司列表中。 - 域名数量在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...

> 属于 **中国公司** 但 **主要对境外提供服务** 的域名 ⇒ `?` 无论连接点情况如何，都应该包含在其公司列表中，并且根据 #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`用于路由规则。...

https://github.com/duckduckgo/tracker-radar/blob/926b07b2e70489633127d4393f45890655319deb/LICENSE#L8-L9 I wonder if it's a typo or not. LICENSE says this project is licensed under CC BY-NC-ND 4.0, while in README it's CC BY-NC-SA 4.0.