《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

本文爲雲棲社區原創內容，未經容許不得轉載。