《DNS稳定保障系列1--服务双保障“辅助DNS”产品介绍》

背景

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

图片来自维基百科

权威 DNS 容灾

【DNS 解析流程】

用户向递归 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】

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

【多权威 DNS】

多权威 DNS 架构，具备如下优势：

 容灾备份： 其中一个权威 DNS 故障，其余权威 DNS 可继续提供域名解析服务；

 负载均衡，流量均摊：多个权威 DNS 同时对外提供解析服务时，能够达到流量负载均衡的效果；

 提高解析效率: 递归 DNS 经过 SRTT 优选策略，选择返回结果最快的权威 DNS，提高域名解析效率；

github.com就是多权威 DNS 模式，同时使用了 dyn 和 asw 的权威 DNS。

多权威 DNS 架构，存在如下问题：

 重复配置：域名配置更改，须要在全部权威 DNS 都配置一遍，费时费力易出错。

【DNS自动数据同步】

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

一、用户在 MASTER 上动态修改域名解析记录（如 NSUPDATE），修改为功后，域名所在 ZONE 的版本号加 1。

test.com 初始配置：

初始 SOA 序列号：

NSUPDTA 新增记录：

最新 SOA 序列号

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

NOTIFY 消息：

三、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;

四、MASTER 根据 SLAVE 请求的 XFR 类型返回对应的数据

IXFR 返回格式和结果：

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

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