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

1.??????用戶發出www.sina.com.cn的域名解析請求，首先查詢本地緩存中是否有該域名對應的IP，如果有直接返回，否則，進行第二步；

2.??????本地緩存服務器向根域名服務器發起DNS查詢請求，根域名服務器會發送一個回復說，.cn的域名我已經委派給.cn這臺域名服務器了，給你這臺服務器的地址，你去哪里查吧。

3.??????本地緩存服務器收到這個答復后又向.cn域名服務器查詢，如此迭代，最后.sina.com.cn的DNS服務器會收到這個請求，返回域名的實際IP給本地緩存服務器。

4.??????本地緩存服務器收到這個答復后，會將這條記錄返回給客戶端，同時將該記錄寫入自己的緩存中，以便備查。

?●●●

DNS調度原理

現在，大部分應用和業務都采用域名作為服務的入口，因此用DNS來負載均衡和區域調度是非常普遍的做法，網易云也有著一套基于DNS的調度系統。某些用戶在進行直播推流時用的并不是網易云的直播SDK，而是一些第三方的推流軟件，如obs，這樣就不能使用我們的GSLB全局調度服務器來調度。對于這些用戶，我們使用DNS調度的方式，對不同地域的請求返回不同解析結果，將請求調度到離用戶最近的服務器節點，從而減少延遲訪問。

咋一看，DNS調度這么簡單方便，那為什么不讓所有的用戶都走DNS調度呢？想知道原因？來，我們繼續講。

?●●●

地理位置調度不準確

在DNS解析過程中，與權威服務器通信的只有dns緩存服務器，所以權威服務器只能根據dns緩存服務器的IP來進行調度。因此DNS調度有一個前提：假定用戶使用的緩存DNS與用戶本身在同個網絡內，即至少在同一個AS(自治域)內，在該前提下，DNS的解析才是準確的。通常情況下，用戶使用ISP提供的本地緩存(簡稱localDNS)，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不變而不受影響。

?●●●

總結

所以推薦大家用我們網易云的直播SDK，接入更加精準的調度系統，保證用戶體驗。

?

——【特別推薦】——

短信效果不好？試試這幾招

總結

以上是生活随笔為你收集整理的DNS调度原理解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。