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

权威 DNS 容灾
【DNS 解析流程】

_1_2

用户向递归 DNS 请求 www.test.com 的解析
递归 DNS 向权威 DNS 请求 www.test.com 的解析
权威 DNS 将 www.test.com. 的解析 1.1.1.1 返回给递归 DNS
递归 DNS 将 www.test.com. 的解析 1.1.1.1 返回给用户
【单权威 DNS】
_1_3

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

【多权威 DNS】
_1_4

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

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

【DNS自动数据同步】
RFC 标准协议通过 MASTER-SLAVE 架构，NOTIFY + XFR 机制实现数据自动同步，用户只需要在主服务器上更改域名，更改信息便可自动同步到从服务器
图片说明
1、用户在 MASTER 上动态修改域名解析记录（如 NSUPDATE），修改成功后，域名所在 ZONE 的版本号加 1。
test.com 初始配置：
_1_7

初始 SOA 序列号：
_1_8

NSUPDTA 新增记录：
_1_9

最新 SOA 序列号
图片说明

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

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 返回格式和结果：
_1_12
_1_13

AXFR 返回结果：
图片说明

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

作者：kimi_nyn

原文链接：https://yq.aliyun.com/articles/720843?utm_content=g_1000083374

本文为云栖社区原创内容，未经允许不得转载。