问题

考虑下面这样的DNS部署结构，如果进行双线DNS解析的设备上，其中一条线路出现问题，对于公网用户的DNS影响会有多大？

DNS结构

  要解释这个问题，首先要理解互联网上DNS的工作方式和解析过程。

递归查询与迭代查询

DNS查询分为两个大类：递归查询和迭代查询
  简单来说，执行递归查询的DNS会替发起请求的用户客户端完成一系列的DNS查询，直到获取了最终结果后，返回给查询客户端。
  而迭代查询过程中，各级DNS都把自己知道的信息反馈给客户端，所有的查询过程都由发起请求的客户端自己完成。

递归查询示意图

递归查询解析过程:
Q1:用户向Local DNS发起递归请求，查询xxx.abc.com。
Q2:Local DNS向abc.com的二级域名DNS服务器发起请求，查询xxx.abc.com。
A1:二级域名DNS返回Local DNS一条CNAME记录，同时返回该CNAME对应域名的ns记录，指向实际解析服务器。
Q3:Local DNS向实际解析服务器发起请求，查询xxx.yyy.abc.com
A2:实际解析服务器根据来源地址(注意是Local DNS的IP)和线路可用情况，返回对应的A记录。
A3:Local DNS将获取到的CNAME和A记录信息反馈给终端用户。

迭代查询示意图

迭代查询解析过程:
Q1:用户向Local DNS发起递归请求，查询xxx.abc.com。
A1:Local DNS反馈用户客户端，可以向二级域名DNS服务器进行查询。
Q2:用户向abc.com的二级域名DNS服务器发起请求，查询xxx.abc.com。
A2:二级域名DNS返回用户客户端一条CNAME记录，同时返回该CNAME对应域名的ns记录，指向实际解析服务器
Q3:用户客户端向实际解析服务器发起请求，查询xxx.yyy.abc.com
A3:实际解析服务器将A记录信息反馈给终端用户。

上述步骤中，简化了Local DNS获取二级域名DNS服务器信息的过程，可能是通过DNS本身缓存的域名信息，或者向上一级/根域名服务器请求获取。

对于互联网用户，配置的用于互联网域名解析的DNS一般都支持递归查询，客户端发起DNS请求时，一般也默认采用递归查询请求。只有当DNS明确不支持或者客户端明确要求非递归查询时，才会通过迭代查询进行解析。

实例

电信DNS 联通DNS

上面两图种，使用同一台终端，分别向电信/联通的DNS进行递归的解析请求(flags:rd置位)，可以看到分别获取了两个不同的A记录结果。说明确实是由Local DNS向最终的域名解析服务器(本例中是两台LC的F5)进行了A记录请求，解析服务器根据来源IP(Local DNS)分别返回了不同的解析结果。
  我们可以看到，最终A记录的TTL分别是30秒和60秒，意味着该记录只会在Local DNS缓存这点时间(缓存时间由Local DNS配置决定，同时与该DNS上的记录容量有关，新纪录会把老记录刷新掉)，客户端本身的缓存机制更复杂一些，浏览器和操作系统分别都会有DNS缓存，大体上与收到响应中的TTL接近。(有文章说windows会任性地缓存一天，还要考证)

结论

1、当双线解析中的一条线路发生中断的时候，对于绝大部分采取递归查询Local DNS的客户端来说，在Local DNS的缓存失效(一般在几十秒到几分钟)后，再次发起请求就会从最终的DNS解析设备获取到另一条线路的A记录地址(解析设备会判断一条线路不可用，不再考虑来源地址而直接返回可用线路的地址)。因此对大部分客户端来说，应该很快能够恢复访问。
2、对于客户端终端或所配置的DNS有超长缓存的设备(如客户端通过迭代获取A记录，会根据解析设备上A记录配置的TTL时间进行缓存，许多DNS服务商或设备上默认1小时)，除非在设备上主动清除、刷新缓存，不然无法有效刷新。
3、为加速情况2中的客户端在故障情况下地切换时间，可以适当缩短解析设备上配置的TTL时间，如缩短至10分钟。