背景
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 機制實作資料自動同步，使用者隻需要在主伺服器上更改域名，更改資訊便可自動同步到從伺服器
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仍可以繼續提供解析服務。保障您的業務在全球範圍内穩定運作。