发布于

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。


发布于

DNS 控制面异常处理思考与实践

这个国庆假期互联网最大的新闻就是某不存在的公司 Facebook 全线业务宕机了 7 个小时，这其中有一个不起眼但是很关键的原因是其权威 DNS 节点在检测到部分网络异常（可以理解为控制面异常）后进行自我剔除操作，所有 DNS 节点“集体自杀”，从而导致 Facebook 自身及其他使用其权威 DNS 服务的业务全线异常。

这里会简单聊聊 DNSPod权威 DNS 的控制面异常时是如何处理的，包括曾经的思考与当前的实践经验，如何保障在出现类似问题的情况下尽量保障 DNS 服务的连续性，最终方案其实很简单，一点都不高大上，但好在简单实用。

权威 DNS 的控制面最主要的工作是同步用户记录的修改，不管是通过私有协议还是域传送，一旦控制面异常，边缘的 DNS 节点在故障期间无法同步用户最新的记录修改数据，终端用户就可能解析到旧的 IP 上，对业务造成一定影响，所以控制面故障时主要要解决的问题就是如何防止故障节点继续响应过期记录。

当前权威 DNS 大多使用多个 IP 同时提供服务，可能是 Anycast 集群，或者单地域集群，或者混合部署，都可以提供一定的容灾和负载均衡能力。而递归 DNS 对多个不同的权威 DNS 服务 IP 一般是通过 SRTT 方式来选择使用哪一个 IP 进行请求，可以自动剔除（减少请求）故障的权威 IP，一般只要权威的 IP 列表中有可用的 IP 且容量足够就可以正常进行递归解析。

所以最简单的处理方式就是直接踢掉控制面异常的权威 DNS 节点，即可保证递归不会解析到过期的数据，但是就是这最简单的踢掉故障节点的操作，其实也会涉及到很多的思考和实践经验，下面从头开始介绍。

控制面故障影响范围分类

按照影响 DNS 节点范围和处理方式来区分控制面故障的类型，主要就是两种类型，部分节点受影响和全部节点受影响。

  1. 部分节点受影响

这里可能有多种原因，最常见的如 DNS 节点与控制中心之间的网络异常，或者部分控制中心从节点故障，只影响少部分边缘的 DNS 节点的控制面数据同步，那么这时候故障 DNS 节点自救做自我剔除，将自己从服务集群中摘除貌似完全没有影响，然后自动/手动切换到其他正常的控制节点或者等待故障的控制节点恢复，再恢复 DNS 节点的对外服务即可。

当然这里没有影响是有一个前提的，那就是剩余节点必须有足够的服务能力，而故障节点本身因为控制面故障形成了一个孤岛节点，是没有足够的信息进行相关判断的，可见即使只有部分节点受影响，故障节点也是不能轻易进行自我剔除操作的。

  1. 全部节点受影响

这里最大的可能原因是控制中心节点故障，如控制中心主节点宕机，或者网络故障导致所有从节点数据同步落后，此时如果故障 DNS 节点还进行自我剔除，所有 DNS 节点“集体自杀”了，后果严重，就是这次 Facebook 事件中 DNS 节点服务器的操作了。

如何解决

从上面的分析可以得出一个结论：权威 DNS 节点在控制面故障时一定不能做自我剔除的操作，因为孤岛节点是没有足够的信息，无法得出正确的结论，是否应该进行自我剔除 ，下面是前两年时讨论这个问题的一个截图，当然这个结论在很多年前其实就已经分析得出了。

故障 DNS 节点能做的是告警、尝试切换寻找正常的控制节点等操作，很多时候故障节点已经可以自动恢复，比如单独某个控制从节点故障自动切换即可恢复。但是也有时候无法自动恢复，如 DNS 节点本身内网故障的时候，而且这时候节点本身的告警也是无法正常发出来的^_^。

那就只能通过权威 DNS 节点及控制面之外的外围监控来进行处理，目前 DNSPod 的实践经验是这样的：

控制面故障监控

  1. 在多个地区多个运营商部署了监控节点，对所有的权威 DNS 的 LB VIP 以及 RS 的物理 IP 持续进行拨测；
  2. 每一轮拨测前通过 API 对拨测域名添加一条 TXT 记录，记录值为当前拨测点当前时间戳；
  3. 正常情况下 DNSPod 所有的权威 DNS 节点的数据同步都是秒级的，所以一旦拨测结果与最新设置的记录值不一致，则可以判断该节点数据同步落后，并可以计算出落后的时长，汇总统计所有数据同步落后节点后发出告警，实现对 DNS 节点控制面是否正常的监控。
  4. 该监控可以同时对 DNS 节点的数据面是否能够正常解析进行监控告警。

控制面故障处理

接下来就需要对控制面故障的 DNS 节点进行处理，此处可以有多种处理方式，自动或手动，DNSPod 目前主要还是手动处理，主要由以下几个原因：

  1. 目前外部的监控节点对 DNS 服务器做的是完全黑盒拨测，很难自动判断 DNS 节点控制面故障的真实原因，从而无法确定处理方式。
  2. 监控节点无法直接控制 DNS 服务器的行为，而通过控制中心处理的话，但是此时控制面已经异常了，可能会陷入死锁无法处理，还是比如故障节点内网中断的这个场景。
  3. 大部分异常节点已经可以自动恢复，无法自动恢复的告警发生频率很低。

不同场景处理方式

本节列出几个常见的控制面故障场景，以及对应的处理方式

节点本身内网故障

此时故障节点处于一个网络孤岛，内网中断，外网因为安全原因禁止登陆，根据不同情况可以由以下几种处理方式：

  1. 如果只是 LB + RS 集群中单独某台 RS 故障，优先通过 LB 剔除；
  2. 如果LB异常或没有LB（如直接的 OSPF 集群），有带外，可以通过带外方式登陆服务器，将该服务器剔除，剔除方式优先选择停止 OSPF，如果没有 OSPF，则可以考虑封禁数据面 53 端口的请求以及停止服务程序等方式；
  3. 没有带外或者带外故障，如果该故障节点是 Anycast 节点，可以选择在交换机等处取消 BGP 广播下掉整个节点，需要能够快速联系到网络交换机相关负责人，且不会影响其他业务。
  4. 直接通过防护系统（宙斯盾）或运营商防护接口在某地域或全地域封禁该IP，此时虽然对应节点的 IP 不可用，但是 LocalDNS 可以通过文章开头提到的 SRTT 机制去其他正常节点请求，不影响总体解析。
  5. 前面的处理方式都有一个前提，就是其他节点容量足够，但是如果剩余节点容量不足怎么办，此时处理方案是不对 DNS 节点进行下线处理，虽然可能导致部分 DNS 请求会解析到过时的记录，但是有变化的记录毕竟是少数，需要优先保证整个大盘的解析正常。此场景在某些极端情况下有一定的出现的可能，比如整个平台遭受持续超大量的 DDoS 攻击时，同时这台服务器出现了控制面故障，根据具体情况评估影响后可能采取此不处理下线的方式。
  6. 在权威解析控制台及注册局（商）出删除该 IP，因为 TTL 很长，一般不考虑。

控制中心完全故障导致所有节点控制面故障

类似此次的 Facebook 的最初始故障，如判断确实是控制中心就是无法连接，无法同步数据，那么也只能降级服务，不对 DNS 节点进行下线处理，等待控制中心恢复。

参考阅读

https://www.thousandeyes.com/blog/facebook-outage-analysis