@szzys 怪不得广东移动 IPv4 还有一大堆单向绕路的段反而先把 IPv6 的广州双向出口调通，看来目前的策略都是优先保障 IPv6 了

最关键是里面有没有涉及到 AS9808 （中国移动内地段）？如果涉及到了搞出这些东西不也很正常，毕竟看看联通电信的策略只要不买亚洲区的天价 transit 涉及中国大陆的流量统统绕美

@xusp onedns 应该是限制了白名单域名只对国内域名开启 ECS ，且 DNS 缓存策略存在严重问题居然是按来源 IP 缓存而不是按提交的 ECS 缓存，基本可以划进不支持的范畴

dig @117.50.11.11 o-o.myaddr.l.google.com txt +subnet=111.28.0.0/24
;; BADCOOKIE, retrying.

; <<>> DiG 9.16.23-RH <<>> @117.50.11.11 o-o.myaddr.l.google.com txt +subnet=111.28.0.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40138
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 32ab13ed74df629e0100000064df3c805b5e806dc81e6943 (good)
; CLIENT-SUBNET: 111.28.0.0/24/0
;; QUESTION SECTION:
;o-o.myaddr.l.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 40 IN TXT "117.50.11.11"

;; Query time: 43 msec
;; SERVER: 117.50.11.11#53(117.50.11.11)
解析谷歌域名不支持 ECS

今天一测大部分 cloudflare IPv6 切回美西，不过无所谓只要还有到香港的段就可以”优化“
同时 WARP 已恢复

好消息：广东移动到 cloudflare IPv6 都直连香港了延迟 10ms+速度大概有 20-30M （普通家宽）好过到美西经常只有 10M 以下
坏消息：IPv6 的 WARP 被彻底封禁（疑似 2606:4700:d0::/48 、2606:4700:d1::/48 这两个段的全部 UDP 端口被封，TCP 正常)

@zenghx 不是说了只要后端递归服务器在国内就不可能没有污染，但只会有墙的污染不会有运营商加的料（即不会像其他帖子里运营商 DNS 把 cloudflare 和 github 解析到 127.0.0.1 的情况），海外情况我暂时没能力测试

@JAYDEN96 移动现在貌似只会在多次请求失败的情况下才会劫持 DNS 应答”保障用户体验“，而且 ipv6 完全没有劫持情况，加密 DNS 出现之后再搞大范围劫持也没什么意义了

@872517414 dnspod 不是无法正确返回而是它不会直接向权威提交 ipv6 的 ECS 而是转为提交和 IPv6 同运营商同地区的 ipv4 地址，这样可以减小缓存 IP 段的数量节约成本

阿里只是在三大运营商网内的后端不支持 ECS （即不会向权威提交 ECS 地址解析准确度全靠后端在国内覆盖地区的数量）但入口是支持的，假如你提交的 IP 不属于三大运营商阿里就会转发到支持 ECS 后端进行查询

dig @2400:3200::1 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24

; <<>> DiG 9.16.23-RH <<>> @2400:3200::1 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11909
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1408
; CLIENT-SUBNET: 101.6.6.0/24/24
;; QUESTION SECTION:
;o-o.myaddr.l.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60 IN TXT "47.106.126.96"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 42.83.199.0/25"

;; Query time: 197 msec
;; SERVER: 2400:3200::1#53(2400:3200::1)

百度和阿里类似但它的后端在任何情况都不会向权威提交 ECS 这点确实考虑的不够好，但百度连教育网都有覆盖后端比阿里覆盖还广人家确实这样做有底气
dig @180.76.76.76 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24

; <<>> DiG 9.16.23-RH <<>> @180.76.76.76 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20126
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;o-o.myaddr.l.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 190 IN TXT "222.199.191.4"

;; Query time: 108 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)

国内彻底不支持 ECS 的公共 dns 有 114 、cnnic dns 、onedns 等，支持但有重大问题的是 360 （学习阿里和百度的做法但它后端递归服务器少且不向权威提交 ECS 导致会出现解析跨省结果，且不支持 IPv6 ECS 如果提交不管哪里的 IPv6 都是解析至河南）

@yyzh 国内的互联网公司也就只有他们两家提供，国内的 NTP 主力还是靠教育网及海外服务器

登录页面就有 https 了，但之前建行还在用 RSA 这种没有前向保密的密钥交换方式我也是服了，刚刚去看了一下终于用上了 ECDHE 这个安全密钥交换方式了，但就是不用 X25519 椭圆曲线还在用 P256 ，不知道这条曲线疑似有 NSA 后门？

是的，Linux 默认都不开启隐私地址默认只使用 EUI64 地址，如需开启隐私地址（ RFC4941 ）可以根据发行版查询对应的开启方式，一般都需要修改配置文件
ROS 的 IPv6 防火墙必须完整匹配，但可以根据 @neroxps 提供的脚本自动更新前缀达到匹配完整地址的目的 https://github.com/neroxps/RouterOS-Script/blob/master/update_wan_ip_to_firwall_address_list.rsc

更新，gcore.jsdelivr.net 解析出的 IP 已变更为指向 CloudFlare ，看来是真的停止合作了

dig @8.8.4.4 aaaa gcore.jsdelivr.net

; <<>> DiG 9.16.27-Debian <<>> @8.8.4.4 aaaa gcore.jsdelivr.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11502
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gcore.jsdelivr.net. IN AAAA

;; ANSWER SECTION:
gcore.jsdelivr.net. 3340 IN CNAME gcore.jsdelivr.net.cdn.cloudflare.net.
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5914
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5614
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5714
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5514
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5814

;; Query time: 72 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Jul 06 16:47:56 CST 2023
;; MSG SIZE rcvd: 235

@aa51513 又不用非常精确，只要把移动 IDC 的 IP 段全放进去把家宽和其他运营商的 IP 段排除不就行了，普通人拿不到这些 IP 段不就没法利用免流漏洞了

安装 chrome 或者更新 webview 都要先装一个对应版本的 trichrome library 静态库再安装本体才能正常使用 64 位（ apkmirror 上面每个版本都有一套静态库+本体 aab 安装包，aab 可以用 SAI 安装），否则只能用 32 位的 chrome/webview ，如果嫌麻烦那只能用 play 安装，但 8G 内存以下的设备 play 也只会安装 32 位版本

你那里电信 iptv 只要十块一个月？广州电信肯定不给装
广东有线（广东广电广州）的宽带除了没有 ipv6 其他方面还好吧，我们这边已经改了光纤，通过测试发现访问热门 cdn 不用跨网用的是和联通共建的服务器（奇怪的是广东联通并不用），应该不会卡顿吧，不过不太确定高峰期的情况因为没买它家的宽带只装了电视随便测了一下怕产生扣费
广州移动你只要用它的手机每个月再给 20-30 就有 100-300M 的宽带（不限制主套餐，但 8 元不容易办低价+高速率估计是有规定），比广州电信动辄 100+的融合套餐要优惠多了，除了自带的 dns 会将不存在的网站指向移动的广告网站还有上行只给 30M 其他方面没发现大问题（反正不用它的 dns ）

不知道那些说手机流量 MTU 是 1500 的结论是怎么来的，反正广东移动、联通的手机流量 MTU 都不是 1500 ，移动是 1420 联通是 1400 ，不过楼主说的结论也确实不成立这些 MTU 值应该都被判定为代理但实际没有

@zx900930 法国运营商确实挺牛的，连谷歌都不愿意 peer ，但不买他们的 transit 问题也不大到隔壁的 DE-CIX 、LINX 、AMS-IX 去交换不就行了最多延迟高点，这也许是法国境内没有知名 ix 的原因吧

通过测试来看没有一个递归 dns （包括谷歌、cloudflare 等国外知名 dns ）能完整返回 100 个记录，我这里阿里和百度都返回了 SERVFAIL ，结果不一样应该是阿里 dns 不同区域的后端采用了不一样处理的方式，除了 114 其他国内外正常应答的 dns 应答个数都在合理上限以上（一般都是 50 个左右，dnspod 应答了 27 个应该满足最低限度），值得注意的是 dnspod 返回的状态码不正常（ status: BADVERS ），查了一下意思是 EDNS 版本的错误扩展机制应该没有多大的问题

其实还有一个重要原因我看没人说，就是因为国内环境决定了内容商 99%与运营商的互联靠的是买 IP transit 而不是国外主流的对等 peer ，造成运营商的大部分公网 IPv4 需保留给互联网企业开展业务留给用户的只有很少一部分，运营商除了给内容商公网 IPv4 还要给每个宽带用户分配公网 IPv4 除了美国的运营商没一个国家能做到吧？