我們正在研究的下一代智能媒體網(wǎng)絡課題中德澈，網(wǎng)絡傳輸環(huán)節(jié)有一個問題需要解決，即終端如何能夠就近接入分布在全球各地的媒體節(jié)點，這用到了HTTP DNS這項技術(shù)蕴侣。恰好在阿里云棲社區(qū)上柑晒，讀到一篇關(guān)于DNS域名解析優(yōu)化的文章锄弱，對此講解的挺清楚。寫一篇學習筆記辱志，一些文字或圖片引自該問斬個虐急。原文鏈接：《移動互聯(lián)網(wǎng)時代箱残，如何優(yōu)化你的網(wǎng)絡 —— 域名解析篇》
域名(Domain Name)是由一串用點分隔的名字組成的某臺計算機或某組計算機的標識，域名通過DNS（Domain Name System）服務轉(zhuǎn)化為服務器的IP地址戏仓，以便應用通過IP進行尋址和通信疚宇，這個過程稱之為域名解析
作為互聯(lián)網(wǎng)絡通信的最前端環(huán)節(jié)，域名解析非常重要赏殃。在基于傳統(tǒng)瀏覽器的B/S場景下敷待，域名解析由瀏覽器內(nèi)核實現(xiàn)，應用不用關(guān)心域名解析的細節(jié)仁热。也正因為這種透明性榜揖，一旦域名解析系統(tǒng)出現(xiàn)問題，甚至遭到黑客的劫持抗蠢，應用開發(fā)者幾乎無計可施
而進入移動互聯(lián)網(wǎng)時代（包括基于瀏覽器的富客戶端應用）举哟，實際上是一種C/S架構(gòu)，這賦予了應用開發(fā)者較大的定制空間迅矛。開發(fā)者甚至可以滲透到應用底層網(wǎng)絡實現(xiàn)當中妨猩，對域名解析環(huán)節(jié)的優(yōu)化變?yōu)榱丝赡?/p>
一些DNS中的關(guān)鍵概念
樹狀域名結(jié)構(gòu)
DNS系統(tǒng)采用樹狀管理結(jié)構(gòu)，以blog.csdn.net為例秽褒，.net是頂級域名壶硅，csdn為二級域名，blog為三級域名销斟，以此類推
權(quán)威DNS
權(quán)威DNS是最終決定解析結(jié)果的服務器庐椒，是解析結(jié)果的權(quán)威，可以在權(quán)威DNS上配置蚂踊、更改约谈、刪除具體域名的解析結(jié)果。比如阿里云解析就是權(quán)威DNS服務提供商
遞歸DNS
遞歸DNS又稱為Local DNS犁钟，它沒有域名解析的決定權(quán)棱诱，但能夠代理用戶向權(quán)威DNS進行域名解析的請求。遞歸DNS上有緩存模塊特纤，當緩存中包含解析目標并且TTL未過期時（TTL是域名的有效生存時間军俊，若緩存時間超過TTL，遞歸DNS需要重新向權(quán)威DNS獲取解析結(jié)果）捧存，遞歸DNS會返回緩存結(jié)果粪躬，否則遞歸DNS會逐級查詢各個層級域名的權(quán)威DNS担败，直至獲取最終完整域名的解析結(jié)果
公共DNS
公共DNS是遞歸DNS的一種特例，它是一種向全網(wǎng)開放的遞歸DNS服務镰官，而傳統(tǒng)的遞歸DNS信息一般由運營商分發(fā)給用戶（還記得曾經(jīng)手工在IP配置中指定DNS地址么）提前。一個比較典型的公共DNS是Google提供的的8.8.8.8（看來老外也喜歡吉利的數(shù)字），可以通過在操作系統(tǒng)配置文件中用公共DNS來代替Local DNS完成域名解析流程
注：在實際的使用過程中泳唠，我們通常不需要手工指定Local DNS地址狈网。運營商會通過DHCP協(xié)議將Local DNS地址分配給我們的計算機
以訪問“www.csdn.net”為例，一次域名的遞歸查詢解析的具體過程如下：
1）終端向Local DNS發(fā)起“www.csdn.net”的訪問請求
2）Local DNS收到請求后笨腥，從Root Hints獲取根域名服務器地址拓哺，并向“Root DNS Server”發(fā)起解析請求，Root DNS Server返回“net”頂級域名服務器IP地址
3）Local DNS向“Net DNS Server”發(fā)起域名解析請求脖母，Net DNS Server返回“csdn.net”二級域名服務器IP地址
4）Local DNS向“CSDN DNS Server”發(fā)起域名解析請求士鸥，CSDN DNS Server返回最終的“www.csdn.net”的IP地址
5）Local DNS將遞歸查詢獲取的IP地址返回給終端
注：Local DNS服務器包含緩存模塊，在實際域名解析過程中Local DNS服務器會首先查詢緩存谆级，緩存命中且解析結(jié)果TTL未過期的情況下直接返回烤礁，否則才啟動遞歸查詢的流程
傳統(tǒng)域名解析（Local DNS）可能存在的問題
第一、域名劫持：本來域名A應該返回的DNS解析結(jié)果的IP1被惡意替換為了IP2肥照，導致對A的訪問失敗或訪問了一個不安全的站點脚仔。有兩種可能的劫持方式：
1）攻擊Local DNS周邊：一方面，黑客侵入了寬帶路由器并將終端用戶指定的Local DNS篡改為黑客自己偽造的Local DNS舆绎；另一方面鲤脏，由于DNS解析主要是基于UDP協(xié)議，攻擊者可以監(jiān)聽終端用戶的域名解析請求吕朵，并在Local DNS返回正確結(jié)果之前將偽造的DNS解析響應傳遞給終端用戶凑兰，進而控制終端用戶的域名訪問行為
2）攻擊Local DNS緩存：最常碰到的域名劫持現(xiàn)象是緩存污染。由于Local DNS在接收到域名解析請求時首先會查找緩存边锁，如果命中就會直接返回緩存結(jié)果，不再進行遞歸DNS查詢波岛。如果黑客將緩存結(jié)果指向第三方的廣告頁茅坛，就會導致用戶的訪問請求被引導到這些廣告頁地址上
第二種針對Local DNS緩存的污染往往能帶來更明顯的群體傷害，比如某個省份某個運營商的用戶群可能因為該地區(qū)Local DNS的緩存污染而導致群體性訪問服務異常则拷。而且這類緩存污染行為往往是間歇性贡蓖、局部性發(fā)生的，沒有明顯的規(guī)律煌茬，導致開發(fā)者很難對其進行量化斥铺、評估、預防
第二坛善、調(diào)度不精準：有這樣一種場景晾蜘，為了應用后續(xù)的訪問性能邻眷，用戶希望的初始的DNS解析結(jié)果帶有地域或運營商性質(zhì)，比如CDN剔交。傳統(tǒng)的域名解析方式可能存在兩類問題：
1）部分Local DNS供應商為了降低運營成本肆饶，會將發(fā)給自己的域名解析請求轉(zhuǎn)發(fā)給其他供應商的Local DNS節(jié)點，如下圖所示岖常，用戶請求解析的是cdn.aliyun.com驯镊，分配給用戶的是Local DNS A，該DNS節(jié)點為了節(jié)省成本竭鞍，把該次請求轉(zhuǎn)發(fā)給了另一運營商的Local DNS B板惑。而最終的權(quán)威DNS在進行域名解析時可能會根據(jù)Local DNS的IP信息進行智能調(diào)度（比如采用地理位置就近接入的調(diào)度策略），分配與Local DNS B 78.29.29.1相同運營商并且地理位置最近的CDN節(jié)點78.29.29.2偎快，然而這個CDN節(jié)點對于終端135.35.35.1并不是最優(yōu)的CDN節(jié)點冯乘，他們分屬不同的運營商，并且地理位置上可能相隔很遠滨砍。這類解析轉(zhuǎn)發(fā)行為會嚴重影響域名解析的精準性并對用戶業(yè)務訪問延遲帶來影響
2）除了解析轉(zhuǎn)發(fā)對調(diào)度精準性帶來的影響外往湿，Local DNS的布署情況同樣影響著域名智能解析的精準性。受成本因素制約惋戏，部分運營商Local DNS部署分布并不均勻领追，比如在東部地區(qū)部署比較密集，在西部地區(qū)部署比較稀疏响逢。當一位西藏用戶準備訪問CDN節(jié)點時绒窑，我們預期他應該會被調(diào)度到西藏的CDN節(jié)點A上以實現(xiàn)就近接入和訪問加速。但由于Local DNS的資源有限舔亭，西部地區(qū)的終端用戶被統(tǒng)一調(diào)度到青海的Local DNS B上些膨，這時候權(quán)威DNS根據(jù)Local DNS B的IP進行CDN域名的智能解析，并將青海的CDN節(jié)點B返回給西藏用戶钦铺，導致西藏地區(qū)用戶的網(wǎng)絡訪問延遲上升订雾。另一種情況是Local DNS的分配甚至并非遵循就近原則，比如有實際案例顯示西藏用戶甚至被分配了北京的Local DNS節(jié)點C矛洞，導致西藏的用戶在進行CDN資源訪問時被調(diào)度到了北京的CDN節(jié)點C上洼哎，類似的由于調(diào)度精度的缺失帶來的訪問體驗的影響是非常嚴重的
第三、解析生效滯后：
Local DNS是由各個地區(qū)不同運營商獨立部署的沼本，服務質(zhì)量參差不齊噩峦。在對域名解析緩存的處理上，各個獨立節(jié)點的實現(xiàn)策略也有區(qū)別抽兆，比如部分節(jié)點為了節(jié)省開支忽略了域名解析結(jié)果的TTL時間限制识补，導致用戶在權(quán)威DNS進行解析變更，但解析結(jié)果在全網(wǎng)生效的周期非常漫長（最長生效時間甚至高達48小時）辫红。部分業(yè)務場景下開發(fā)者對域名解析結(jié)果變更的生效時間非常敏感凭涂，比如當業(yè)務服務器受到攻擊時祝辣，我們需要最快速地將業(yè)務IP切換到另一組集群上，如果全網(wǎng)解析生效不夠迅速导盅，可能直接導致用戶業(yè)務訪問的異常较幌，造成嚴重事故
第四、延遲大：
DNS首次查詢或緩存過期后的查詢白翻，需要遞歸遍歷多個DNS服務器以獲取最終的解析結(jié)果乍炉，這增加了網(wǎng)絡請求的前置延時時間。特別是在移動互聯(lián)網(wǎng)場景下滤馍，移動網(wǎng)絡質(zhì)量參差不齊岛琼，弱網(wǎng)環(huán)境的RTT時間可能高達數(shù)百毫秒，對于一次普通的業(yè)務請求而言巢株，上述延時是非常沉重的負擔槐瑞。另一方面，弱網(wǎng)環(huán)境下的解析超時阁苞、解析失敗等現(xiàn)象屢見不鮮困檩，如何合理優(yōu)化DNS解析對于整體網(wǎng)絡訪問質(zhì)量的提升至關(guān)重要
域名解析的解決方案：HTTP DNS
HTTP DNS使用HTTP協(xié)議進行域名解析，代替現(xiàn)有Local DNS基于UDP的DNS協(xié)議那槽。域名解析請求直接發(fā)送到HTTP DNS服務端悼沿，繞過運營商的Local DNS∩Ь模基于HTTP協(xié)議的設計可以適用于幾乎所有的網(wǎng)絡環(huán)境糟趾，同時保留了鑒權(quán)、HTTPS等更高安全性的擴展能力甚牲，避免惡意攻擊劫持行為义郑。而商業(yè)化的HTTP DNS服務（比如阿里和騰訊的HTTP DNS）對緩存管理有嚴格的安全保障，避免了類似Local DNS的緩存污染的問題
第一丈钙、精準調(diào)度問題的解決
傳統(tǒng)域名解析的調(diào)度精準性問題非驮，本質(zhì)根源在于Local DNS的部署和分配機制上。由于碎片化的管理方式雏赦，服務質(zhì)量難以得到保障院尔。而HTTP DNS與權(quán)威DNS的交互時，通過edns-client-subnet協(xié)議（https://datatracker.ietf.org/doc/rfc7871）將終端用戶的IP信息直接傳遞給權(quán)威DNS喉誊，權(quán)威DNS根據(jù)終端用戶的IP信息，而不是傳統(tǒng)的Local DNS IP信息進行精準調(diào)度纵顾，這樣避免看了Local DNS的坐標干擾
第二伍茄、解析實時性問題的解決
和精準調(diào)度一樣，由于傳統(tǒng)Local DNS在不同區(qū)域的獨立提供和獨立維護施逾，服務質(zhì)量參差不齊敷矫，因此存在比較明顯的解析變更全網(wǎng)生效滯后問題例获，而商業(yè)化的HTTP DNS服務嚴格遵循DNS TTL限制進行緩存更新（一般都有專門的同步方案進行保證），能夠大大減少滯后性問題
結(jié)語：HTTP DNS本質(zhì)上是將原本分布在各地曹仗，由不同DNS供應商（主要就是運營商）提供的參差不齊的DNS服務質(zhì)量榨汤，利用協(xié)議，轉(zhuǎn)化為由統(tǒng)一DNS服務提供商提供的更短接怎茫、更有保障的DNS服務能力收壕。當然利用HTTP DNS，也要符合具體服務提供者的操作規(guī)范和編程規(guī)范轨蛤，這里面也有較多良好的實踐模式蜜宪，在后面的學習中再進行總結(jié)
晚安……
