DNS，現(xiàn)代互聯(lián)網(wǎng)發(fā)展最不可或缺的服務(wù)之一，我們從訪問網(wǎng)頁到發(fā)送電子郵件，無時(shí)不刻都使用著DNS為我們提供的服務(wù)。大家都知道，DNS的核心工作就是將域名翻譯成計(jì)算機(jī)IP地址，一個(gè)完整的DNS解析過程如下:

1.??????用戶發(fā)出www.sina.com.cn的域名解析請(qǐng)求，首先查詢本地緩存中是否有該域名對(duì)應(yīng)的IP，如果有直接返回，否則，進(jìn)行第二步；

2.??????本地緩存服務(wù)器向根域名服務(wù)器發(fā)起DNS查詢請(qǐng)求，根域名服務(wù)器會(huì)發(fā)送一個(gè)回復(fù)說，.cn的域名我已經(jīng)委派給.cn這臺(tái)域名服務(wù)器了，給你這臺(tái)服務(wù)器的地址，你去哪里查吧。

3.??????本地緩存服務(wù)器收到這個(gè)答復(fù)后又向.cn域名服務(wù)器查詢，如此迭代，最后.sina.com.cn的DNS服務(wù)器會(huì)收到這個(gè)請(qǐng)求，返回域名的實(shí)際IP給本地緩存服務(wù)器。

4.??????本地緩存服務(wù)器收到這個(gè)答復(fù)后，會(huì)將這條記錄返回給客戶端，同時(shí)將該記錄寫入自己的緩存中，以便備查。

?●●●

DNS調(diào)度原理

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

咋一看，DNS調(diào)度這么簡(jiǎn)單方便，那為什么不讓所有的用戶都走DNS調(diào)度呢？想知道原因？來，我們繼續(xù)講。

?●●●

地理位置調(diào)度不準(zhǔn)確

在DNS解析過程中，與權(quán)威服務(wù)器通信的只有dns緩存服務(wù)器，所以權(quán)威服務(wù)器只能根據(jù)dns緩存服務(wù)器的IP來進(jìn)行調(diào)度。因此DNS調(diào)度有一個(gè)前提：假定用戶使用的緩存DNS與用戶本身在同個(gè)網(wǎng)絡(luò)內(nèi)，即至少在同一個(gè)AS(自治域)內(nèi)，在該前提下，DNS的解析才是準(zhǔn)確的。通常情況下，用戶使用ISP提供的本地緩存(簡(jiǎn)稱localDNS)，local DNS一般與用戶在同個(gè)網(wǎng)絡(luò)內(nèi)，這時(shí)候DNS調(diào)度是有效的。

但近些年，不少互聯(lián)網(wǎng)廠商推廣基于BGP Anycast的公共DNS (Public DNS)，而這些 Anycaset IP的節(jié)點(diǎn)一般是遠(yuǎn)少于各個(gè)ISP的節(jié)點(diǎn)，例如可能廣州電信用戶使用了某公共DNS，但該公共DNS里用戶最近的是上海電信節(jié)點(diǎn)，甚至更極端的如Google DNS 8.8.8.8，在中國大陸沒有節(jié)點(diǎn)(最近的是臺(tái)灣)。而不幸的是國內(nèi)有不少用戶使用了Google DNS，這其實(shí)降低了他們的網(wǎng)絡(luò)訪問體驗(yàn)。總的來說，使用公共DNS，實(shí)際上破壞了上文的前提，導(dǎo)致DNS區(qū)域調(diào)度失效，用戶以為得到了更快更安全的DNS解析，但實(shí)際得到了錯(cuò)誤的解析，增加了網(wǎng)絡(luò)訪問延遲。

傳統(tǒng)DNS協(xié)議的區(qū)域調(diào)度過程示例如下圖，假定某業(yè)務(wù)以foo.163.com對(duì)外提供服務(wù)，在北京和東京各有一個(gè)節(jié)點(diǎn)，業(yè)務(wù)期望國內(nèi)大陸的用戶訪問北京節(jié)點(diǎn)，而非大陸用戶則訪問東京節(jié)點(diǎn)。因?yàn)闄?quán)威是根據(jù)DNS緩存來決定返回的結(jié)果，所以當(dāng)用戶使用不用的DNS緩存時(shí)，可能會(huì)解析到不同的結(jié)果。

2011年，Google為首的幾家公司在提出了一個(gè)DNS的擴(kuò)展方案edns-client-subnet(以下簡(jiǎn)稱ECS)，該擴(kuò)展方案的核心思想是通過在DNS請(qǐng)求報(bào)文里加入原始請(qǐng)求的IP(即client的IP)，使得權(quán)威能根據(jù)該信息返回正確的結(jié)果。目前，該方案仍處于草案階段。該方案很好地解決了上述提到的remote DNS導(dǎo)致解析不準(zhǔn)確的問題，但也帶了一些問題：

• 至少需要 cache 和權(quán)威都支持，才能完成完整的 ECS 解析；

• ECS 給 cache 增加了很大的緩存壓力，因?yàn)槔碚撋峡赡苄枰獮槊總€(gè)IP段分配空間去緩存解析結(jié)果

?●●●

規(guī)則變更生效時(shí)間不確定

當(dāng)緩存服務(wù)器向權(quán)威服務(wù)器查詢得到記錄之后，會(huì)將其緩存起來，在緩存有效期內(nèi)，如果收到相同記錄的查詢，緩存服務(wù)器會(huì)直接返回給客戶端，而不需要再次向權(quán)威查詢，當(dāng)有效期過后，緩存則是需要再次發(fā)起查詢。這個(gè)緩存有效期即是TTL。

雖然 DNS 的緩存機(jī)制在大多數(shù)情況下縮短了客戶端的記錄解析時(shí)間，但緩存也意味著生效同步的延遲。當(dāng)權(quán)威服務(wù)器的記錄變更時(shí)，需要等待一段時(shí)間才能讓所有客戶端能解析到新的結(jié)果，因?yàn)楹芸赡芫彺娣?wù)器還緩存著舊的記錄。

我們將權(quán)威的記錄變更到全網(wǎng)生效這個(gè)過程稱為 propagation，它的時(shí)間是不確定的，理論上的最大值即是TTL的值，對(duì)于記錄變更或刪除，這個(gè)時(shí)間是記錄原本的TTL，對(duì)于記錄新增則是域的nTTL值。

如果一個(gè)域名記錄原本的TTL是18000，可以認(rèn)為，變更該記錄理論上需要等待5個(gè)小時(shí)才能保證記錄能生效到全網(wǎng)。假設(shè)該域名的業(yè)務(wù)方希望縮短切換的時(shí)間，正確的做法是，至少提前5個(gè)小時(shí)修改記錄，僅改小TTL，例如改為5分鐘，等待該變更同步到全網(wǎng)之后，再進(jìn)行修改指向的操作，確認(rèn)無誤再將TTL修改為原本的值。

雖然DNS協(xié)議標(biāo)準(zhǔn)里建議緩存服務(wù)器應(yīng)該記住或者縮短TTL的值，但實(shí)際上，有一些DNS緩存會(huì)修改權(quán)威服務(wù)器的TTL，將其變大，這在國內(nèi)幾大運(yùn)營(yíng)商中是很常見的。例如，某域記錄的TTL值實(shí)際上設(shè)置為60，但在運(yùn)營(yíng)商的DNS緩存上，卻變成600或者更大的值，甚至還有一些DNS緩存是不遵循TTL機(jī)制。這些都會(huì)影響域名的實(shí)際生效時(shí)間。

●●●?

高可用

為避免受DNS緩存的影響，需要保證DNS中A記錄的IP節(jié)點(diǎn)高可用性。對(duì)此，網(wǎng)易云DNS調(diào)度系統(tǒng)采用的方案是在同一區(qū)域的多臺(tái)直播服務(wù)器節(jié)點(diǎn)之間做負(fù)載均衡，對(duì)外只暴露一個(gè)虛IP，這樣，即使某臺(tái)服務(wù)器宕機(jī)，負(fù)載均衡能迅速感知到，排除故障節(jié)點(diǎn)，而對(duì)DNS而言，因?yàn)樘揑P不變而不受影響。

?●●●

總結(jié)

所以推薦大家用我們網(wǎng)易云的直播SDK，接入更加精準(zhǔn)的調(diào)度系統(tǒng)，保證用戶體驗(yàn)。

?

——【特別推薦】——

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。