发布于

DNS 解析中的搜索引擎线路那些事儿

本文不会贴出任何搜索引擎蜘蛛实际的测试数据，仅作理论分析，感兴趣的同学可以根据一些公开的第三方工具和文章中提到的一些技术方案自行分析。

首先简单介绍下 DNS 解析中搜索引擎线路的作用，当代权威 DNS 的基本功能都包括分线路解析（也有智能解析、view、geo 等等名字） ，其中很多权威 DNS 服务商会提供针对搜索引擎蜘蛛抓取的线路（包括搜索引擎线路、SEO 优化、搜索引擎回源等等名字），主要目的是对普通用户返回 CDN 或其他通用的地址，而准对搜索引擎蜘蛛的抓取则直接返回源站的地址，可以提高权重、收录等目的。

搜索引擎蜘蛛在抓取网页前，首先要进行域名解析，获取目标域名的 IP 地址之后再进行抓取，此处需要涉及到蜘蛛使用的 LocalDNS 和目标域名使用的权威 DNS 两个部分的解析过程，首先介绍权威 DNS 解析过程。

权威 DNS 解析过程

权威 DNS 主要是依靠 LocalDNS 发送的 DNS 请求中的 IP 地址来进行分线路的解析的，而携带 IP 地址主要有两个位置，分别进行说明。

DNS 请求源地址

一个标准的 DNS 请求不管是 UDP 还是 TCP 协议，都必然要有其源 IP 地址，权威 DNS 服务器可以通过获取该地址来查询 IP 库和线路设置情况来进行分线路解析。

edns_client_subnet(ECS) 选项中携带 IP 地址

DNS 扩展协议中的 ECS 段可以在 DNS 请求包额外携带 IP 地址来供权威 DNS 获取并依此进行分线路解析，主要用于提升节点分布于全球的公共 DNS 来提升解析准确度，但是 ECS 的现状是大量权威 DNS 已经实现了对 ECS 的支持，但是 LocalDNS 对 ECS 的支持情况则很不乐观，除了 Google Public DNS 和 OpenDNS 有相对比较完整的支持外，其他包括运营商 DNS 和大部分其他公共 DNS 并没有很完整的支持 ECS 协议（ECS 协议支持情况可以参考之前的一篇文章《国内主要公共 DNS 支持 ECS 情况测试 – 20210315》）。

当然可知目前绝大部分的搜索引擎蜘蛛使用的 LocalDNS 也都是不支持 ECS 协议的，而权威 DNS 要正确解析蜘蛛访问的域名的线路主要就依赖蜘蛛使用的 LocalDNS 本身的外网出口 IP 来判断。下面再讨论蜘蛛使用的 LocalDNS 几种不同的场景。

蜘蛛使用的 LocalDNS

蜘蛛使用的 DNS 可能分为几种情况：

1. 使用蜘蛛独占的网段搭建 LocalDNS 进行解析

这种情况是对权威 DNS 的搜索引擎线路最友好的方式，该网段为蜘蛛独占，不与其他业务混用，尤其是公共DNS，目标域名的权威 DNS 只需要定期收集更新其蜘蛛使用的 LocalDNS 的外网出口 IP 即可达到很好的优化效果。

如果蜘蛛 IP 和 LocalDNS 的外网出口 IP 地址位于相同网段，通过搜索引擎官网公布或第三方收集的蜘蛛 IP、蜘蛛的 UA、IP 段的反解析结果等收集、验证、更新蜘蛛 IP 段即可。

如果 LocalDNS 的外网出口 IP 地址与蜘蛛 IP 位于不同网段，但是只要该网段依然是蜘蛛独占，可以通过一些技术手段来收集这些 LocalDNS 的外网出口 IP，如向 LocalDNS 请求 whoami.ip.dnspod.net，则返回结果即为该 LocalDNS 的外网出口 IP，如果 LocalDNS 支持 ECS，则会同时返回 LocalDNS 请求的源 IP 和携带的 ECS IP。

类似可以检测 LocalDNS 的外网出口 IP 的域名现网有多家大厂都有提供，仅返回结果的展示方式不一致。

但是想想就知道，蜘蛛全部独占相关的网段的可能性有多低，现网的相关测试数据也完全证明蜘蛛使用的网段大部分是也有其他业务在使用， 其实大部分其他业务复用蜘蛛 IP 段不会对搜索引擎线路优化有什么影响 ，除了公共 DNS。

2. 蜘蛛 LocalDNS 的外网出口 IP 网段和公共 DNS 网段重合

这种场景对同时提供搜索引擎服务和公共 DNS 服务的厂商是非常常见的，此处也不再进行举例说明，仅说明存在的问题。

目前从各种渠道获取到的蜘蛛 IP（包括其使用的 LocalDNS 外网出口 IP）在 IPv4（IPv6 本文不额外讨论） 中一般精度可达到 C 段 IP（/24），非常难达到非常准确的 /32 精度，这就导致权威 DNS 无法区分来访问的 IP 到底是蜘蛛来访问的还是普通用户使用公共 DNS 来访问的，从而无法给双方都解析到准确的结果，只能折衷选取一种策略。

举例说明，目前腾讯云 DNSPod 的解析策略是对此类 IP 不添加到蜘蛛 IP 库中，结果是蜘蛛很大概率无法获取搜索引擎线路设置的特定结果，但是也不会造成普通用户错误的获取到蜘蛛线路的解析结果，尤其是在其公共 DNS 服务的普通用户体量巨大的时候。

3. 直接使用公共 DNS 进行解析

公开的 LocalDNS 包括运营商 DNS 和其他公共 DNS，因为运营商 DNS 大多有源 IP 段必须为本运营商的限制，对于可能分布于各地的蜘蛛来说不是很好的选择，公共 DNS 则可以作为主要选择。

蜘蛛可以直接使用这些公共 DNS 进行解析或者自建的缓存 LocalDNS 本身不进行递归查询，只是将解析请求转发至公共 DNS 并缓存解析结果。

此类场景在蜘蛛中也是比较常见的，因为可以节省大量的 LocalDNS 的部署维护成本，导致的结果和策略选择也与第二种场景一致。

解决方案

如果想让权威 DNS 的搜索引擎线路更有效，解决目前存在的问题，可以考虑 2 种方案，但是都存在相同的问题，虽然理论上是有一定的可操作性的，但是实际中确较难达成，主要维护成本或资源成本，且依赖搜索引擎的部署策略，与权威 DNS 不是一家的^_^。

  1. 蜘蛛及其 LocalDNS 使用 IP 段不要与公共 DNS 复用
  2. 蜘蛛使用支持完整 ECS 的递归 DNS

方案 1 主要针对蜘蛛自建 LocalDNS ，实施难度本身不大，主要是在部署自己的 LocalDNS 时能够和公共 DNS 隔离即可，需要更多的IP段资源，且在后续变更时需要注意一直维护该策略不变才可。

方案 2 主要针对直接使用或者转发到公共 DNS 的蜘蛛，因为完整的 ECS 在 LocalDNS 中对域名的解析结果会按照网段进行缓存，即使蜘蛛与普通用户复用相同 DNS 也不会造成很大的影响，仅对蜘蛛 IP 同网段的其他业务可能产生一定的影响，范围非常有限，不会影响到大量的普通用户的访问。

此方案存在的问题主要是公共 DNS 支持完整 ECS 的少之又少，尤其是在国内短期内不一定会有长期持续而稳定支持完整 ECS 的公共 DNS，而 Google Public DNS 和 OpenDNS 则对国内使用者非常不友好，可操作性不如方案 1。


发布于

IOS14对使用8.8.8.8进行DNS(CDN)调度的影响

2023-12-21更新：虽然8.8.8.8对MX、CAA以及其他类型等依然不支持ecs（符合RFC标准），但是在cname链中已经不会对A/AAAA等其他记录类型造成影响，看上去像是单独处理了，已经修复了该问题。

但是依然存在ecs失效的可能，比如8.8.8.8的递归到权威的请求偶发超时、请求权威跨国且请求了同权威IP被污染的域名等场景，依然可能造成递归判断权威的IP不支持ecs，导致后续一段时间内的ecs失效，暂无太好的办法。

2021-04-02 更新: Google 公共 DNS 已经对 HTTPS 和 SVCB 支持了 ECS，其他类型正在评估，测试正常。

2021-03-26 更新：标准化组织正在对该问题进行讨论，大体方案可能为：

  1. 如果递归 DNS 准备解析 HTTPS 记录指向的域名，并且在返回给客户端的应答附加段中添加 A/AAAA 记录，则递归在向权威请求HTTPS 记录时应携带 /0，表示递归支持 ECS，但对 HTTPS 记录类型禁用，此时权威在响应时不能在附加段中添加相关 A/AAAA 记录，以便递归 DNS 携带正常的 ECS 进行 A/AAAA 记录的请求。
  2. 如果递归 DNS 不准备执行上面的方案，则递归在向权威进行 HTTPS 类型的请求时应携带与请求 A/AAAA 类型相同的 ECS。

方案1实现较复杂，递归 DNS 需要对 HTTPS 记录类型进行单独处理，此处也要注意 HTTPS 记录类型也包括对应的 CNAME，但是可以减轻缓存压力；方案2简单粗暴，对应增加的就是递归 DNS 的缓存压力。

具体信息可以参考： https://issuetracker.google.com/issues/181593657 和 https://github.com/MikeBishop/dns-alt-svc/pull/308

我们一直的观点是在国内不要使用 Google 的公共 DNS（8.8.8.8），这里再从技术层面讨论下 IOS 14 更新后使用 8.8.8.8 进行 DNS 解析对 CDN 调度的影响。

结论

  1. 在国内任意地区都不应该系统上直接设置或转发到 8.8.8.8 进行 DNS 解析，这个结论依然有效。
  2. IOS 14 更新后会对域名自动发出 TYPE HTTPS (TYPE65) 类型的请求，这会导致 8.8.8.8 对于包含 CNAME 记录的解析结果 ECS 判断失效的情况极大增多，调度不准确的情况会远多于 IOS 14 更新之前，CDN 调度受影响比较严重。
  3. 仅限于当前时间（2021.03.04）有效，如果后续相关 DNS 请求行为有变化，则结论可能不再准确。

解析过程

公共 DNS 的解析准确度一般是通过在尽量多的地区和运营商部署递归节点，以及是通过 ECS (EDNS Client Subnet，常简称为 EDNS) 技术来提示解析准确度，最主要的使用场景就是 CDN 的调度，所以一旦 ECS 失效，对 CDN 调度的影响也是最大的。

虽然任何 DNS 都不能保证完全解析准确，但是此前 8.8.8.8 做的还是不错的，但是从 20 年 IOS 14 更新后，解析准确度每况愈下，尤其是对部分使用 CDN 进行调度的域名影响较大，经常发生国内解析到国外、不同地区使用多家 CDN 时解析结果不符合预期等问题，下面分析下 IOS 14 对该现象的具体影响过程。

假设在权威 DNS 上对typehttps.example.com配置以下记录， 并且权威 DNS 对 ECS 的支持正确，8.8.8.8 的自动检测也可以正确检测到权威 DNS 是支持 ECS 的。

typehttps   默认  600 CNAME   test1.example.com.
typehttps   境外  600 CNAME   test2.example.com.
test1       默认  600 A       8.8.8.8
test2       默认  600 A       8.8.4.4

当我们从国内向 8.8.8.8 请求 typehttps.example.com或携带国内IP（如 119.29.0.0/24）的 ECS IP 时，正常过程是这样的，

dig @8.8.8.8 typehttps.example.com +subnet=119.29.0.0/24

正常的结果应该是类似这样的，因为权威 DNS 是根据 8.8.8.8 请求时携带的119.29.0.0/24进行解析的,

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 119.29.0.0/24/24
;; QUESTION SECTION:
;typehttps.example.com.           IN      A
​
;; ANSWER SECTION:
typehttps.example.com.  550 IN  CNAME   test1.example.com.
test1.example.com       600 IN  A       8.8.8.8

但是现在你有很大概率拿到会是以下的错误结果，

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 119.29.0.0/24/24
;; QUESTION SECTION:
;typehttps.example.com.           IN      A
​
;; ANSWER SECTION:
typehttps.example.com.  590 IN  CNAME   test2.example.com.
test1.example.com       600 IN  A       8.8.4.4

解析到了境外的 CNAME 及其 IP，以前虽然也可能出现这种解析错误的情况，但是相对少很多，那是什么原因呢，此时如果我们指定请求 CNAME 类型再来看下有什么区别，

dig @8.8.8.8 typehttps.example.com +subnet=119.29.0.0/24 CNAME
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 119.29.0.0/24/0
;; QUESTION SECTION:
;typehttps.example.com.           IN      CNAME
​
;; ANSWER SECTION:
typehttps.example.com.  590 IN  CNAME   test2.example.com.

此时可以看到 ECS 段中的 scope 为 0，这就表示 8.8.8.8 的缓存中将境外线路的 CNAME 记录作为全局结果缓存了，那为什么会出现这种错误的解析和缓存结果呢？

通过抓包分析可以发现，8.8.8.8 对权威 DNS 发起的查询请求中，即使权威是支持 ECS 的，8.8.8.8 也并不会对所有类型的请求记录携带 ECS 段，大部分常见的请求类型，如 A 记录（IPv4）、AAAA 记录（IPv6）、CNAME 记录等并不会出现问题，但是有部分请求类型则不会携带 ECS 进行请求，而这其中有部分类型可能会返回 CNAME 记录，比如 MX 、CAA 以及 HTTPS 类型，权威 DNS 就会按照 8.8.8.8 的递归 DNS 的 IP 所在地返回境外线路的 CNAME 记录，而后 8.8.8.8 就会按照全局 /0 的 scope 缓存该 CNAME。

所以这里就破案了，具体过程是如下两图所示，

A 记录请求过程
HTTPS 记录请求过程
  1. IOS14 升级后会支持 TYPE HTTPS 的记录类型，解析一个域名时应同时请求 A/AAAA/HTTPS 记录类型。
  2. 则 A 和 AAAA 记录可以正常获得境内的 CNAME 和 IP 并正常按照 119.29.0.0/24 的 IP 段缓存，但该缓存仅对该 IP 段有效.
  3. HTTPS 类型的返回的错误 CNAME 结果就会因为上述原因作为全局 /0 的缓存。
  4. 后续所有非119.29.0.0/24网段 请求都会命中全局缓存的错误 CNAME 记录，然后再对 CNAME 记录进行正常的递归查询，客户端最后拿到的就是错误的境外结果。
  5. 虽然 MX 、CAA、HTTPS 类型都会造成此问题，但是在实际的网络环境中，普通域名的 MX 和 CAA 记录类型都是很少被请求到的，所以 8.8.8.8 虽然一直存在类似的问题，但是并不严重。直到 IOS14 更新后， HTTPS 记录类型默认被请求，该问题就变得比较严重了。

影响范围

对不同地区设置了不同 CNAME 记录的域名会有较大影响，一般常见于 CDN，所以对 CDN 影响比较大，具体分析话大概是这样的，

  1. 如果境内和境外使用了不同的 CNAME 记录，如国内使用国内的 CDN，国外使用国外的 CDN，则国内使用 8.8.8.8 会大概率解析到国外线路的 CNAME，很可能解析到国外节点影响访问体验。
  2. 如果未设置其他国家、大洲、境外等线路，只是不同省份运营商使用不同的 CNAME 记录进行负载均衡，则国内使用 8.8.8.8 会大概率会解析到默认线路上，虽然会造成负载均衡效果不符合预期，但在客户端的访问体验上总体影响不大。
  3. 对境外用户影响有限，因为虽然也存在一样的 ECS 失效问题，但根据递归 DNS IP 获取到的 CNAME 结果范围不会差距很大。

规避方法

  1. 在国内避免使用 8.8.8.8，当然这里有部分运营商已经帮忙搞定这一步了，移动端则可以考虑使用 HTTPDNS 等技术手段规避。
  2. 如果条件允许，不同地区应使用相同的 CNAME，如果必须使用不同的CNAME，则需要关注默认和境外相关线路的容量等问题，如境外线路的 CDN 能提供境内 CDN 节点则可以很大的缓解该问题。

其他公共DNS

  1. OpenDNS 208.67.222.222 仅 CAA 记录可能存在此问题；腾讯云/DNSPod 119.29.29.29，各请求类型均不受影响；阿里云 223.5.5.5 不受影响。
  2. 1.1.1.1、9.9.9.9、180.76.76.76、114.114.114.114，默认未支持 ECS ，仅能通过后端递归节点的部署进行调度，不涉及该问题。

参考资料

draft-ietf-dnsop-svcb-httpssvc-03.