前情提要： 在另一个话题中 rt 在下午发布以后 @F-droid 提出一个相当聪明的做法 有望脱离对我自建doh依赖的访问l站方法 因此 windows端 与Linux端开发将提上日程 在另一个话题中 其实我到现在也没看懂这个思路是怎么个事 AdguardHome中这样设置的原理是 CNAME（规范名称） RFC 1034 3.6.2. Aliases and canonical names。 我们来查一下这样配置后的DNS响应： 域名 术语 linux.do 别名（alias） jsdelivr.com 规范名（canonical name） 客户端（包含浏览器的DOH实现）查询 linux.do 的 HTTPS RR （TYPE 65）到链尾，得到规范名 jsdelivr.com 及其对应的记录。 追 CNAME 链完成后浏览器做的是认领HTTPS RR，CNAME不影响TLS， jsdelivr.com 用完就扔了。至于HTTPS RR我们见下表。 字段 值 含义 NAME jsdelivr.com. 记录所属域名 TTL 1m11s 缓存有效期 TYPE HTTPS 记录类型 SvcPriority 1 服务优先级；>0 为 ServiceMode TargetName . 服务目标名； . .表示就在本域名 alpn "h3,h2" 支持的应用层协议 ipv4hint "104.21.8.91,172.67.130.104" IPv4 连接提示 ech "AEX+DQBB..." ECH 配置 ipv6hint "2606:4700:3037..." IPv6 连接提示 RFC 9460 9.4. Requiring Server Name Indication 中是这样写的： Note that the TLS SNI (and also the HTTP “Host” or “:authority”) will indicate the origin, not the TargetName. 也就是说认证的SNI应该是 origin:linux.do ，而不是 TargetName:jsdelivr.com ，CNAME和HTTPS RR都不改变TLS的SNI。在浏览器地址栏输入的原来的域名是什么进行校验的还是什么。 为什么能这么用，还需要解答一个问题： jsdelivr.com 的ech配置能用在 linux.do 上吗？答案是可以的，上面的响应中我们看到HTTPS RR中的ech字段形如 AEX+DQBB... ， 瞪眼法得出这是个base64字符串 ，但解出来是二进制数据，光base64d是不够的。 RFC 9849 4. Encrypted ClientHello Configuration 中定义了 ECHConfig structure。具体参数我这里也不给表格了，Cloudflare是个CDN厂商，它给不同域共用同一组ECH密钥，不同边缘节点部署的私钥是相同的。 6 个帖子 - 4 位参与者 阅读完整话题

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/14 22:50:10