关于 apple，google 的一些站点分流逻辑问题

[rampageX]

使用目前的配置，查询 a100.phobos.apple.com，得不到国内 IP。而这个地址应该是包含在 geosite.dat:apple-cn 里面的：

https://github.com/felixonmars/dnsmasq-china-list/blob/51948e34ab9378fc7c9479784a00a185fff09aa0/apple.china.conf#L98

查询日志：

2021-12-22T07:55:16.938+0800    debug   cache   cache/cache.go:109  skipped {"query": "a100.phobos.apple.com. IN A 64617 1 192.168.2.1:44677"}
2021-12-22T07:55:17.566+0800    debug   remote_upstream bundled_upstream/bundled_upstream.go:68 response received   {"query": "a100.phobos.apple.com. IN A 64617 1 192.168.2.1:44677", "from": "udp://127.0.0.1:4433"}
2021-12-22T07:55:17.567+0800    debug   dns_handler/server_handler.go:94    entry returned  {"query": "a100.phobos.apple.com. IN A 64617 1 192.168.2.1:44677", "status": "responded"}

mosdns-cn 并未从 local_upstream 查询？

注释掉： #remote_domain: ['/root/cfg/geosite.dat:geolocation-!cn'] 则可以返回国内 IP。

目前不知道 a100.phobos.apple.com 在 geosite.dat:geolocation-!cn 和 geosite.dat:apple-cn 中是怎么个包含关系，导致 mosdns-cn 会直接用 remote_upsteam 查询。

mosdns-cn 配置片段：

local_upstream: [127.0.0.1:533]
local_ip: ['/root/cfg/geoip-only-cn-private.dat:cn']
local_domain: ['/root/cfg/geosite.dat:cn', '/root/cfg/geosite.dat:apple-cn', '/root/cfg/geosite.dat:google-cn']
local_latency: 10
remote_upstream: [127.0.0.1:4433]
remote_domain: ['/root/cfg/geosite.dat:geolocation-!cn']

说明： 之前我并没有使用 '/root/cfg/geosite.dat:apple-cn', '/root/cfg/geosite.dat:google-cn' 这两个列表，发现有问题，添加了，也没解决。

geosite 说明：

@felixonmars/dnsmasq-china-list/apple.china.conf 加入到 geosite:geolocation-!cn 类别中（如希望本文件中的 Apple 域名直连，请参考下面 geosite 的 Routing 配置方式） @felixonmars/dnsmasq-china-list/google.china.conf 加入到 geosite:geolocation-!cn 类别中（如希望本文件中的 Google 域名直连，请参考下面 geosite 的 Routing 配置方式）

geosite:apple-cn：包含 @felixonmars/dnsmasq-china-list/apple.china.conf 文件里的域名，供希望 Apple 域名直连（不走代理）的用户使用。 geosite:google-cn：包含 @felixonmars/dnsmasq-china-list/google.china.conf 文件里的域名，供希望 Google 域名直连（不走代理）的用户使用。

mosdns-cn 目前分流逻辑：

分流模式中上游的转发顺序:

非 A/AAAA 类型的请求将直接使用 --local-upstream 本地上游。 如果请求的域名匹配到 --local-domain 本地域名。则直接使用 --local-upstream 本地上游。 如果请求的域名匹配到 --remote-domain 远程域名。则直接使用--remote-upstream 远程上游。 同时转发至本地上游获取应答。 如果本地上游的应答包含 --local-ip 本地 IP。则直接采用本地上游的结果 否则使用远程上游。

按照这个顺序，"同时转发至本地上游获取应答。" 如果指的是无论是否匹配到 --local-domain和--remote-domain 都会执行，那么即使不添加 geosite.dat:apple-cn , 应该也可以返回国内 IP的？ 还是这个 " 同时转发至本地上游获取应答。" 只发生在请求域名不匹配两个列表的情况下才会执行？ 实际日志中并没有 local_upsteam 的查询动作。

[IrineSistiana]

这个域名 --local-domain 没匹配到。跳过 step.2 。被 --remote-domain 匹配了。就直接用 --remote-upstream 了。

[IrineSistiana]

至于为什么 --local-domain 没匹配到。估计要拆包 geosite.dat:apple-cn 看

[IrineSistiana]

geosite.dat:apple-cn 的问题。全是 full 匹配。

full:a1.mzstatic.com
full:a2.mzstatic.com
full:a3.mzstatic.com
full:a4.mzstatic.com
full:a5.mzstatic.com
full:adcdownload.apple.com.akadns.net
full:adcdownload.apple.com
full:appldnld.apple.com
full:appldnld.g.aaplimg.com
full:apps.apple.com
full:apps.mzstatic.com
full:cdn-cn1.apple-mapkit.com
full:cdn-cn2.apple-mapkit.com
full:cdn-cn3.apple-mapkit.com
full:cdn-cn4.apple-mapkit.com
full:cdn.apple-mapkit.com
full:cdn1.apple-mapkit.com
full:cdn2.apple-mapkit.com
full:cdn3.apple-mapkit.com
full:cdn4.apple-mapkit.com
full:cds-cdn.v.aaplimg.com
full:cds.apple.com.akadns.net
full:cds.apple.com
full:cl1-cdn.origin-apple.com.akadns.net
full:cl1.apple.com
full:cl2-cn.apple.com
full:cl2.apple.com.edgekey.net.globalredir.akadns.net
full:cl2.apple.com
full:cl3-cdn.origin-apple.com.akadns.net
full:cl3.apple.com
full:cl4-cdn.origin-apple.com.akadns.net
full:cl4-cn.apple.com
full:cl4.apple.com
full:cl5-cdn.origin-apple.com.akadns.net
full:cl5.apple.com
full:clientflow.apple.com.akadns.net
full:clientflow.apple.com
full:configuration.apple.com.akadns.net
full:configuration.apple.com
full:cstat.apple.com
full:dd-cdn.origin-apple.com.akadns.net
full:download.developer.apple.com
full:gs-loc-cn.apple.com
full:gs-loc.apple.com
full:gsp10-ssl-cn.ls.apple.com
full:gsp11-cn.ls.apple.com
full:gsp12-cn.ls.apple.com
full:gsp13-cn.ls.apple.com
full:gsp4-cn.ls.apple.com.edgekey.net.globalredir.akadns.net
full:gsp4-cn.ls.apple.com.edgekey.net
full:gsp4-cn.ls.apple.com
full:gsp5-cn.ls.apple.com
full:gsp85-cn-ssl.ls.apple.com
full:gspe19-cn-ssl.ls.apple.com
full:gspe19-cn.ls-apple.com.akadns.net
full:gspe19-cn.ls.apple.com
full:gspe21-ssl.ls.apple.com
full:gspe21.ls.apple.com
full:gspe35-ssl.ls.apple.com
full:iadsdk.apple.com
full:icloud-cdn.icloud.com.akadns.net
full:icloud.cdn-apple.com
full:images.apple.com.akadns.net
full:images.apple.com.edgekey.net.globalredir.akadns.net
full:images.apple.com
full:init-p01md-lb.push-apple.com.akadns.net
full:init-p01md.apple.com
full:init-p01st-lb.push-apple.com.akadns.net
full:init-p01st.push.apple.com
full:init-s01st-lb.push-apple.com.akadns.net
full:init-s01st.push.apple.com
full:iosapps.itunes.g.aaplimg.com
full:iphone-ld.apple.com
full:is1-ssl.mzstatic.com
full:is1.mzstatic.com
full:is2-ssl.mzstatic.com
full:is2.mzstatic.com
full:is3-ssl.mzstatic.com
full:is3.mzstatic.com
full:is4-ssl.mzstatic.com
full:is4.mzstatic.com
full:is5-ssl.mzstatic.com
full:is5.mzstatic.com
full:itunes-apple.com.akadns.net
full:itunes.apple.com
full:itunesconnect.apple.com
full:mesu-cdn.apple.com.akadns.net
full:mesu-china.apple.com.akadns.net
full:mesu.apple.com
full:music.apple.com
full:ocsp-lb.apple.com.akadns.net
full:ocsp.apple.com
full:oscdn.apple.com
full:oscdn.origin-apple.com.akadns.net
full:pancake.apple.com
full:pancake.cdn-apple.com.akadns.net
full:phobos.apple.com
full:prod-support.apple-support.akadns.net
full:reserve-prime.apple.com
full:s.mzstatic.com
full:stocks-sparkline-lb.apple.com.akadns.net
full:store.apple.com.edgekey.net.globalredir.akadns.net
full:store.apple.com.edgekey.net
full:store.apple.com
full:store.storeimages.apple.com.akadns.net
full:store.storeimages.cdn-apple.com
full:support-china.apple-support.akadns.net
full:support.apple.com
full:swcatalog-cdn.apple.com.akadns.net
full:swcatalog.apple.com
full:swcdn.apple.com
full:swcdn.g.aaplimg.com
full:swdist.apple.com.akadns.net
full:swdist.apple.com
full:swscan-cdn.apple.com.akadns.net
full:swscan.apple.com
full:updates-http.cdn-apple.com.akadns.net
full:updates-http.cdn-apple.com
full:updates.cdn-apple.com
full:valid.apple.com
full:valid.origin-apple.com.akadns.net
full:www.apple.com.edgekey.net.globalredir.akadns.net
full:www.apple.com.edgekey.net
full:www.apple.com

[rampageX]

@IrineSistiana 那么匹配流程实际就是命中2，3，就跳过4了？

[IrineSistiana]

对。

[rampageX]

感觉本地上游解析出本地IP，应该是优先级最高。当然我不知道别人有什么应用场景（防止本地ISP探测？），所以能否做一个开关实现这个？

[IrineSistiana]

没必要。

地域分流最根本的原理就是IP。只有IP才是按地域分配的。域名可以随便申请。所以域名只是辅助数据。

最简单的方法就是不使用域名表。

我感觉geosite应该用domain匹配而不是full。我不确定。你可以去看看开个issue。

[rampageX]

"最简单的方法就是不使用域名表。" :) 妈的老了，我咋没想到，以前也没这些个表~

[IrineSistiana]

~chinadns 的年代有啥域名表全是 apnic 一张ip表解决一切~

[dyxushuai]

目前的解决方案是：去掉 domain 列表吗

[bluaze]

v2ray-china-list 有人做了这个项目，应该能解决这个问题

[abigchopstick]

v2ray-china-list 有人做了这个项目，应该能解决这个问题

能说说如何在mosdns中用吗？

[bluaze]

v2ray-china-list 有人做了这个项目，应该能解决这个问题

能说说如何在mosdns中用吗？

就是这个项目的geosite里的apple.china类别是普通的domain，而不是full，直接在mosdns里引用即可