背景

2016 年 10 月 21 日，DNS 服务商 dyn 的服务器遭遇黑客大流量的 ddos 攻击，使得美国大量互联网公司如 twitter，github等都出现解析失败，无法提供服务。如下图可见，该事件造成了美国东海岸的网络瘫痪，媒体当时形容此次危机为“史上最大DDoS攻击”。该事件影响及其恶劣，直接对人们的生活造成了影响，唤起了广大互联网用户对 DNS 稳定性的重视。

图片来自维基百科

权威 DNS 容灾

【DNS 解析流程】

1. 用户向递归 DNS 请求 www.test.com 的解析
2. 递归 DNS 向权威 DNS 请求 www.test.com 的解析
3. 权威 DNS 将 www.test.com. 的解析 1.1.1.1 返回给递归 DNS
4. 递归 DNS 将 www.test.com. 的解析 1.1.1.1 返回给用户

【单权威 DNS】

单权威 DNS 架构，存在单点，单点故障，权威 DNS 收不到请求或不能正常返回域名解析结果，如果域名解析配置丢失且没有备份，恢复时间会更长。

【多权威 DNS】

多权威 DNS 架构，具有以下优点：
 容灾备份： 其中一个权威 DNS 故障，其他权威 DNS 可继续提供域名解析服务；
 负载均衡，流量均摊：多个权威 DNS 同时对外提供解析服务时，可以达到流量负载均衡的效果；
 提升解析效率: 递归 DNS 通过 SRTT 优选策略，选择返回结果最快的权威 DNS，提升域名解析效率；
github.com就是多权威 DNS 模式，同时使用了 dyn 和 asw 的权威 DNS。

多权威 DNS 架构，存在以下问题：
 重复配置：域名配置更改，需要在所有权威 DNS 都配置一遍，费时费力易出错。

【DNS自动数据同步】

RFC 标准协议通过 MASTER-SLAVE 架构，NOTIFY + XFR 机制实现数据自动同步，用户只需要在主服务器上更改域名，更改信息便可自动同步到从服务器

1、用户在 MASTER 上动态修改域名解析记录（如 NSUPDATE），修改成功后，域名所在 ZONE 的版本号加 1。
test.com 初始配置：

初始 SOA 序列号：

NSUPDTA 新增记录：

最新 SOA 序列号

2、MASTER 向其配置的 SLAVE 节点发送 NOTIFY（一般是 UDP 报文），NOTIFY 信息中包含了修改域名所在的 ZONE 和该 ZONE 最新的版本号。
NOTIFY 消息：

3、SLAVE 在收到 NOTIFY 消息后，进行以下操作：
(1) SLAVE 在收到 NOTIFY 消息后会给 MASTER 发送一个响应表示收到了 NOTIFY;
(2) SLAVE 比较 NOTIFY 中的 ZONE 的版本号和本地的 ZONE 的版本号，如果本地的版本号不低于 NOTIFY 中的版本号，SLAVE 不做任何操作;
(3) 如果 SLAVE 本地的版本号低于 NOTIFY 中的版本号，表示本地的 ZONE 数据已经落后，SLAVE 向 MASTER 发送 IXFR 请求; SLAVE 根据 REFRESH（定义在 ZONE 的 SOA 记录中）定时向 MASTER 发送 IXFR 请求，作为当 NOTIFY 的报文因为某些原因无法发送到 SLAVE 时的一种补偿机制。
(4) 如果 IXFR 失败，会转向 AXFR;

4、MASTER 根据 SLAVE 请求的 XFR 类型返回对应的数据
IXFR 返回格式和结果：

AXFR 返回结果：

云解析辅助 DNS

多DNS部署方案是一个成本较大的DNS容灾策略，在此建议使用阿里云辅助DNS。辅助DNS是“云解析DNS”为使用自建DNS或第三方DNS的用户提供的DNS容灾备份服务。自建 DNS 或第三方 DNS 做主，云解析 DNS 做辅。我们基于RFC标准协议，在主DNS和辅DNS之间建立区域数据传输机制，当主DNS遇到故障或者服务中断时，辅DNS仍可以继续提供解析服务。保障您的业务在全球范围内稳定运行。