【網易雲信】DNS 調度原理解析

DNS 簡介

DNS，現代互聯網發展最不可或缺的服務之一，咱們從訪問網頁到發送電子郵件，無時不刻都使用着DNS爲咱們提供的服務。你們都知道，DNS的核心工做就是將域名翻譯成計算機IP地址，一個完整的DNS解析過程以下:

一、用戶發出 www.sina.com.cn 的域名解析請求，首先查詢本地緩存中是否有該域名對應的IP，若是有直接返回，不然，進行第二步；
二、本地緩存服務器向根域名服務器發起 DNS 查詢請求，根域名服務器會發送一個回覆說，.cn 的域名我已經委派給.cn 這臺域名服務器了，給你這臺服務器的地址，你去哪裏查吧。
三、本地緩存服務器收到這個答覆後又向.cn 域名服務器查詢，如此迭代，最後.sina.com.cn 的 DNS 服務器會收到這個請求，返回域名的實際IP給本地緩存服務器。
四、本地緩存服務器收到這個答覆後，會將這條記錄返回給客戶端，同時將該記錄寫入本身的緩存中，以便備查。

DNS 調度原理

如今，大部分應用和業務都採用域名做爲服務的入口，所以用 DNS 來負載均衡和區域調度是很是廣泛的作法，網易雲也有着一套基於 DNS 的調度系統。某些用戶在進行直播推流時用的並非網易雲的直播 SDK，而是一些第三方的推流軟件，如obs，這樣就不能使用咱們的 GSLB 全局調度服務器來調度。對於這些用戶，咱們使用 DNS 調度的方式，對不一樣地域的請求返回不一樣解析結果，將請求調度到離用戶最近的服務器節點，從而減小延遲訪問。

咋一看，DNS 調度這麼簡單方便，那爲何不讓全部的用戶都走 DNS 調度呢？想知道緣由？來，咱們繼續講。

• 地理位置調度不許確

在 DNS 解析過程當中，與權威服務器通訊的只有 DNS 緩存服務器，因此權威服務器只能根據 DNS 緩存服務器的IP來進行調度。所以 DNS 調度有一個前提：假定用戶使用的緩存DNS與用戶自己在同個網絡內，即至少在同一個 AS(自治域)內，在該前提下，DNS 的解析纔是準確的。一般狀況下，用戶使用 ISP 提供的本地緩存(簡稱 local DNS)，local DNS 通常與用戶在同個網絡內，這時候 DNS 調度是有效的。
但近些年，很多互聯網廠商推廣基於 BGP Anycast 的公共 DNS (Public DNS)，而這些
Anycaset IP 的節點通常是遠少於各個ISP的節點，例如可能廣州電信用戶使用了某公共 DNS，但該公共 DNS 裏用戶最近的是上海電信節點，甚至更極端的如 Google DNS 8.8.8.8，在中國大陸沒有節點(最近的是臺灣)。而不幸的是國內有很多用戶使用了 Google DNS，這其實下降了他們的網絡訪問體驗。總的來講，使用公共 DNS，實際上破壞了上文的前提，致使 DNS 區域調度失效，用戶覺得獲得了更快更安全的 DNS 解析，但實際獲得了錯誤的解析，增長了網絡訪問延遲。
傳統 DNS 協議的區域調度過程示例以下圖，假定某業務以 foo.163.com 對外提供服務，在北京和東京各有一個節點，業務指望國內大陸的用戶訪問北京節點，而非大陸用戶則訪問東京節點。由於權威是根據 DNS 緩存來決定返回的結果，因此當用戶使用不用的 DNS 緩存時，可能會解析到不一樣的結果。

2011 年，Google 爲首的幾家公司在提出了一個 DNS 的擴展方案 edns-client-subnet (如下簡稱 ECS)，該擴展方案的核心思想是經過在 DNS 請求報文里加入原始請求的 IP(即 client 的 IP)，使得權威能根據該信息返回正確的結果。目前，該方案仍處於草案階段。該方案很好地解決了上述提到的 remote DNS 致使解析不許確的問題，但也帶了一些問題：

• 至少須要 cache 和權威都支持，才能完成完整的 ECS 解析
• ECS 給 cache 增長了很大的緩存壓力，由於理論上可能須要爲每一個IP段分配空間去緩存解析結果

• 規則變動生效時間不肯定

當緩存服務器向權威服務器查詢獲得記錄以後，會將其緩存起來，在緩存有效期內，若是收到相同記錄的查詢，緩存服務器會直接返回給客戶端，而不須要再次向權威查詢，當有效期事後，緩存則是須要再次發起查詢。這個緩存有效期便是 TTL。
雖然 DNS 的緩存機制在大多數狀況下縮短了客戶端的記錄解析時間，但緩存也意味着生效同步的延遲。當權威服務器的記錄變動時，須要等待一段時間才能讓全部客戶端能解析到新的結果，由於極可能緩存服務器還緩存着舊的記錄。
咱們將權威的記錄變動到全網生效這個過程稱爲 propagation，它的時間是不肯定的，理論上的最大值便是 TTL 的值，對於記錄變動或刪除，這個時間是記錄本來的 TTL，對於記錄新增則是域的 nTTL 值。
若是一個域名記錄本來的 TTL 是 18000，能夠認爲，變動該記錄理論上須要等待 5 個小時才能保證記錄能生效到全網。假設該域名的業務方但願縮短切換的時間，正確的作法是，至少提早5個小時修改記錄，僅改小 TTL，例如改成5分鐘，等待該變動同步到全網以後，再進行修改指向的操做，確認無誤再將 TTL 修改成本來的值。
雖然 DNS 協議標準裏建議緩存服務器應該記住或者縮短 TTL 的值，但實際上，有一些DNS緩存會修改權威服務器的 TTL，將其變大，這在國內幾大運營商中是很常見的。例如，某域記錄的 TTL 值實際上設置爲 60，但在運營商的 DNS 緩存上，卻變成 600 或者更大的值，甚至還有一些 DNS 緩存是不遵循 TTL 機制。這些都會影響域名的實際生效時間。

• 高可用

爲避免受 DNS 緩存的影響，須要保證 DNS 中 A 記錄的 IP 節點高可用性。對此，網易雲
DNS 調度系統採用的方案是在同一區域的多臺直播服務器節點之間作負載均衡，對外只暴露一個虛 IP，這樣，即便某臺服務器宕機，負載均衡能迅速感知到，排除故障節點，而對 DNS 而言，由於虛 IP 不變而不受影響。

總結

如今，你們應該知道了 DNS 調度的利弊了吧，因此推薦你們仍是用咱們網易雲的直播 SDK 哦，接入更加精準的調度系統，保證用戶體驗。若是您說您就是喜歡用第三方的推流軟件，那請不要使用公共 DNS 服務已避免調度結果不許確。

---

隨着音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易 MC 官方博客以及微信公衆號：

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網

官網微信公衆號：