全面瞭解移動端DNS域名劫持等雜症：原理、根源、HttpDNS解決方案等

每天騰訊的分散式域名解析監測系統在不停地對全國所有的重點LocalDNS（指運營商的DNS服務）進行探測，騰訊域名在全國各地的日解析異常量是已經超過了80萬條（這方面，來自移動端的異常尤為突出）。這給騰訊的業務帶來了巨大的損失。為此騰訊建立了專業的團隊與各個運營商進行了深度溝通，但是由於各種原因，處理效率及效果均不能達到騰訊各業務部門的需求。

除了和運營商進行溝通，有沒有一種技術上的方案，能從根源上解決域名解析異常及使用者訪問跨網的問題呢？這是包括騰訊在內的很多國內網際網路大廠技術團隊一直在思考的問題。

4、首先，什麼是DNS？

要想理解本文將要討論的DNS各種問題，我們需要首先來複習一下DNS的基本原理和相關知識。

4.1 DNS的工作原理

DNS（Domain Name System，域名系統），DNS 服務用於在網路請求時，將域名轉為 IP 地址。能夠使使用者更方便的訪問網際網路，而不用去記住能夠被機器直接讀取的 IP 數串。

DNS的基一原理如下圖所示：

傳統的基於 UDP 協議的公共 DNS 服務極易發生 DNS 劫持，從而造成安全問題。

4.2 DNS 域名系統結構

如上圖所示，典型DNS域名系統的結構如下：

1）Root 域名：DNS 域名使用時，規定由尾部句號來指定名稱位於根或更高級別的域層次結構；

2）Top Level 頂級域名：用來指示某個國家、地區或組織使用的名稱的型別名稱。如 .net；

3）Second Level 域名：個人或組織在 Internet 上使用的註冊名稱。如 52im.net；

4）Third Level 域名：已註冊的二級域名派生的域名。如 docs.52im.net。

4.3 DNS 解析過程

如上圖所示，這是一個典型的域名解析過程：

1）瀏覽器中輸入 www.52im.net ，發出解析請求；

2）本機的域名解析器 resolver 程式查詢本地快取和 host 檔案中是否為域名的對映關係，如果有則呼叫這個 IP 地址對映，完成解析；

3）如果 hosts 與本地解析器快取都沒有相應的網址對映關係，則本地解析器會向 TCP/IP 引數中設定的首選 DNS 伺服器（我們叫它 Local DNS 伺服器）發起一個遞迴的查詢請求；

4）伺服器收到查詢時，如果要查詢的域名由本機負責解析，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。如果要查詢的域名，不由 Local DNS 伺服器解析，但該伺服器已快取了此網址對映關係，則呼叫這個 IP 地址對映，完成域名解析，此解析不具有權威性；

5）如果 Local DNS 伺服器本地區域檔案與快取解析都失效，則根據 Local DNS 伺服器的設定（是否遞迴）進行查詢，如果未用開啟模式，Local DNS 就把請求發至13臺 Root DNS。如果用的是遞迴模式，此 DNS 伺服器就會把請求轉發至上一級 DNS 伺服器，由上一級伺服器進行解析，上一級伺服器如果不能解析，或找根 DNS 或把轉請求轉至上上級，以此迴圈；

6）Root DNS 伺服器收到請求後會判斷這個域名是誰來授權管理，並會返回一個負責該頂級域名伺服器的一個 IP；

7）Local DNS 伺服器收到 IP 資訊後，將會聯絡負責 .net 域的這臺伺服器；

8）負責 .com 域的伺服器收到請求後，如果自己無法解析，它就會找一個管理 .net 域的下一級 DNS 伺服器地址給本地 DNS 伺服器；

9）當 Local DNS 伺服器收到這個地址後，就會找 52im.net 域伺服器，10、11重複上面的動作，進行查詢；

10）最後 www.52im.net 返回需要解析的域名的 IP 地址給 Local DNS 伺服器；

11）Local DNS 伺服器快取這個解析結果（同時也會快取，6、8、10返回的結果）；

12）Local DNS 伺服器同時將結果返回給本機域名解析器；

13）本機快取解析結果；

14）本機解析器將結果返回給瀏覽器；

15）瀏覽器通過返回的 IP 地址發起請求。

4.4 DNS的遞迴查詢和迭代查詢

遞迴查詢： 如果主機所詢問的本地域名伺服器不知道被查詢域名的 IP 地址，那麼本地域名伺服器就以 DNS 客戶的身份，向其他根域名伺服器繼續發出查詢請求報文，而不是讓該主機自己進行下一步的查詢。

迭代查詢： 當根域名伺服器收到本地域名伺服器發出的迭代查詢請求報文時，要麼給出所要查詢的 IP 地址，要麼告訴本地域名伺服器：你下一步應當向哪一個域名伺服器進行查詢。然後讓本地域名伺服器進行後續的查詢，而不是替本地域名伺服器進行後續的查詢。

由此可見，客戶端到 Local DNS 伺服器，Local DNS 與上級 DNS 伺服器之間屬於遞迴查詢；DNS 伺服器與根 DNS 伺服器之前屬於迭代查詢。

實際環境中，因為採用遞迴模式會導致 DNS 伺服器流量很大，所以現在大多數的 DNS 都是迭代模式。

5、國內移動端網路所面臨的各種DNS雜症

總結下來，DNS的這些咋整主要的帶來了三類問題：

1）LocalDNS劫持；

2）平均訪問延遲下降；

3）使用者連線失敗率下降。

LocalDNS劫持: 由於HttpDNS是通過ip直接請求http獲取伺服器A記錄地址，不存在向本地運營商詢問domain解析過程，所以從根本避免了劫持問題。（對於http內容tcp/ip層劫持，可以使用驗證因子或者資料加密等方式來保證傳輸資料的可信度）

平均訪問延遲下降: 由於是ip直接訪問省掉了一次domain解析過程，（即使系統有快取速度也會稍快一些‘毫秒級’）通過智慧演算法排序後找到最快節點進行訪問。

使用者連線失敗率下降: 通過演算法降低以往失敗率過高的伺服器排序，通過時間近期訪問過的資料提高伺服器排序，通過歷史訪問成功記錄提高伺服器排序。如果ip(a)訪問錯誤，在下一次返回ip(b)或者ip(c) 排序後的記錄。

那麼，追根溯源，到底為什麼會存在這些問題？這就是下一節要討論的問題。

6、追根溯源，國內DNS問題的根源是什麼？

我們得先得了解下現在國內各ISP運營商的LocalDNS的基本情況。

國內運營商LocalDNS造成的這些問題，可以歸為下以下3種原因：

1）域名快取；
2）解析轉發；
3）LocalDNS遞迴出口NAT。

下面，我們來逐一分析。

6.1 域名快取

域名快取很好理解，就是LocalDNS快取了騰訊的域名的解析結果，不向騰訊權威DNS發起遞迴。

示意圖如下：

為何LocalDNS要把域名解析結果進行快取呢？原因有以下幾個：

1）保證使用者訪問流量在本網內消化：國內的各網際網路接入運營商的頻寬資源、網間結算費用、IDC機房分佈、網內ICP資源分佈等存在較大差異。為了保證網內使用者的訪問質量，同時減少跨網結算，運營商在網內搭建了內容快取伺服器，通過把域名強行指向內容快取伺服器的IP地址，就實現了把本地本網流量完全留在了本地的目的；

2）推送廣告：有部分LocalDNS會把部分域名解析結果的所指向的內容快取，並替換成第三方廣告聯盟的廣告。

以上型別的行為就是我們常說的域名快取，域名快取會導致使用者產生以下的訪問異常：

A、僅對80埠的http服務做了快取，如果域名是通過https協議或其它埠提供服務的，使用者訪問就會出現失敗。比如支付服務、遊戲通過指定埠連線connect server服務等；

B、快取伺服器的運維水平參差不齊，時有出現快取伺服器故障導致使用者訪問異常的問題。

6.2 解析轉發

除了域名快取以外，運營商的LocalDNS還存在解析轉發的現象。解析轉發是指運營商自身不進行域名遞迴解析，而是把域名解析請求轉發到其它運營商的遞迴DNS上的行為。

正常的LocalDNS遞迴解析過程是這樣的：

而部分小運營商為了節省資源，就直接將解析請求轉發到了其它運營的遞迴LocalDNS上去了：

這樣的直接後果就是騰訊權威DNS收到的域名解析請求的來源IP就成了其它運營商的IP，最終導致使用者流量被導向了錯誤的IDC，使用者訪問變慢。

6.3 LocalDNS遞迴出口NAT

LocalDNS遞迴出口NAT指的是運營商的LocalDNS按照標準的DNS協議進行遞迴，但是因為在網路上存在多出口且配置了目標路由NAT，結果導致LocalDNS最終進行遞迴解析的時候的出口IP就有概率不為本網的IP地址。

如下圖所示：

這樣的直接後果就是GSLB DNS收到的域名解析請求的來源IP還是成了其它運營商的IP，最終導致使用者流量被導向了錯誤的IDC，使用者訪問變慢。

7、必須著手解決這些問題，但傳統解決方案問題太多

運營商的LocalDNS解析域名異常，給對使用者訪問騰訊網際網路業務的體驗造成了非常大的損害。

那麼以前，我們是如何處理這些域名解析異常的問題的呢？

1）實時監控+商務推動：

這種方案是目前騰訊的運營團隊一直在使用的方案。這種方案就是週期比較長，畢竟通過行政手段來推動運營商來解決這個問題是比較耗時的。另外我們通過大資料分析，得出的結論是Top 3的問題使用者均為移動網際網路使用者。對於這部分使用者，我們有什麼技術手段可以解決以上的問題呢？

2）繞過自動分配DNS，使用114dns或Google public DNS：

這個方案看上去很美好，114dns是國內最大的中立快取DNS，而Google又是秉承不作惡理念的網際網路工程帝國巨鱷，而且騰訊的權威DNS又支援edns-client-subnet功能，能直接識別使用Google publicDNS解析騰訊域名的使用者的IP地址，不會出現流量排程失效。

但是問題來了：

a. 如何在使用者側構造域名請求：對於PC端的客戶端來說，構造一個標準的DNS請求包並不算什麼難事。但在移動端要向一個指定的LocalDNS上傳送標準的DNS請求包，而且要相容各種iOS和android的版本的話，技術上是可行的，只是相容的成本會很高；
b. 推動使用者修改配置極高：如果要推動使用者手動修改PC的DNS配置的話，在PC端和手機客戶端的WiFI下面還算勉強可行。但是要使用者修改在移動網際網路環境下的DNS配置，其難度不言而喻。

3）完全拋棄域名，自建connectcenter進行流量排程：

如果要採用這種這種方案的話，首先你就得要拿到一份準確的IP地址庫來判斷使用者的歸屬，然後再製定個協議搭個connect center來做排程，然後再對接入層做排程改造。這種方案和2種方案一樣，不是不能做，只是成本會比較高，尤其對於騰訊這種業務規模如此龐大的公司而言。

既然上面的這些傳統方案都存在那麼多的問題，那有沒有一種排程精準、成本低廉、配置方便的基於域名的流量排程系統呢？答案是肯定的，我們在下一步繼續分享。

8、當前主流的解決方案：HttpDNS出現了

8.1 什麼HttpDNS？

HTTPDNS 利用 HTTP 協議與 DNS 伺服器互動，代替了傳統的基於 UDP 協議的 DNS 互動，繞開了運營商的 Local DNS，有效防止了域名劫持，提高域名解析效率。另外，由於 DNS 伺服器端獲取的是真實客戶端 IP 而非 Local DNS 的 IP，能夠精確定位客戶端地理位置、運營商資訊，從而有效改進排程精確性。

HTTPDNS的原理如下圖所示：

8.2 HttpDns 主要解決的問題

Local DNS 劫持： 由於 HttpDns 是通過 IP 直接請求 HTTP 獲取伺服器 A 記錄地址，不存在向本地運營商詢問 domain 解析過程，所以從根本避免了劫持問題。

平均訪問延遲下降： 由於是 IP 直接訪問省掉了一次 domain 解析過程，通過智慧演算法排序後找到最快節點進行訪問。

使用者連線失敗率下降： 通過演算法降低以往失敗率過高的伺服器排序，通過時間近期訪問過的資料提高伺服器排序，通過歷史訪問成功記錄提高伺服器排序。

8.3 騰訊的HttpDNS思路

經過努力，騰訊公司的GSLB 團隊推出的HttpDNS是為移動客戶端量身定做的基於Http協議和域名解析的流量排程解決方案，專治LocalDNS解析異常以及流量排程不準。

詳細介紹如下。

騰訊的HttpDNS基本原理：

HttpDNS的原理非常簡單，主要有兩步：

A、客戶端直接訪問HttpDNS介面，獲取業務在域名配置管理系統上配置的訪問延遲最優的IP。（基於容災考慮，還是保留次選使用運營商LocalDNS解析域名的方式）；

B、客戶端向獲取到的IP後就向直接往此IP傳送業務協議請求。以Http請求為例，通過在header中指定host欄位，向HttpDNS返回的IP傳送標準的Http請求即可。

HttpDNS帶來的優勢：

從原理上來講，HttpDNS只是將域名解析的協議由DNS協議換成了Http協議，並不複雜。

但是這一微小的轉換，卻帶來了無數的收益：

A、根治域名解析異常：由於繞過了運營商的LocalDNS，使用者解析域名的請求通過Http協議直接透傳到了騰訊的HttpDNS伺服器IP上，使用者在客戶端的域名解析請求將不會遭受到域名解析異常的困擾；

B、排程精準：HttpDNS能直接獲取到使用者IP，通過結合騰訊自有專利技術生成的IP地址庫以及測速系統，可以保證將使用者引導的訪問最快的IDC節點上；

C、實現成本低廉：接入HttpDNS的業務僅需要對客戶端接入層做少量改造，無需使用者手機進行root或越獄；而且由於Http協議請求構造非常簡單，相容各版本的移動作業系統更不成問題；另外HttpDNS的後端配置完全複用現有權威DNS配置，管理成本也非常低。總而言之，就是以最小的改造成本，解決了業務遭受域名解析異常的問題，並滿足業務精確流量排程的需求；

D、擴充套件性強：HttpDNS提供可靠的域名解析服務，業務可將自有排程邏輯與HttpDNS返回結果結合，實現更精細化的流量排程。比如指定版本的客戶端連線請求的IP地址，指定網路型別的使用者連線指定的IP地址等。

當然各位可能會問： 使用者將首選的域名解析方式切換到了HttpDNS，那麼HttpDNS的高可用又是如何保證的呢？另外不同運營商的使用者訪問到同一個HttpDNS的服務IP，使用者的訪問延遲如何保證？

為了保證高可用及提升使用者體驗，HttpDNS通過接入了騰訊公網交換平臺的BGP Anycast網路，與全國多個主流運營商建立了BGP互聯，保證了這些運營商的使用者能夠快速地訪問到HttpDNS服務；另外HttpDNS在多個資料中心進行了部署，任意一個節點發生故障時均能無縫切換到備份節點，保證使用者解析正常。

接入效果及未來展望：

當前騰訊的HttpDNS方案已在騰訊內部接入了多個業務，覆蓋數億使用者，並已持續穩定執行超過一年時間。而接入了HttpDNS的業務在使用者訪問體驗方面都有了非常大的提升。

以某個接入HttpDNS的業務為例，該業務僅通過接入HttpDNS，在未做任何其它優化的情況下，使用者平均訪問延遲下降超過10%，訪問失敗率下降了超過五分之一，使用者訪問體驗的效果提升非常顯著。另外騰訊的HttpDNS服務除了在騰訊內部被廣泛使用以外，也受到了業務同行的肯定。國內最大的publicDNS服務商114dns在受到騰訊DNS的啟發下，也推出了HttpDNS服務。

在未來的日子裡，騰訊GSLB團隊將會在騰訊內部進一步推廣HttpDNS服務，並將在實際業務的需求下對HttpDNS服務進行升級，如提供更為通用、安全、簡單的接入協議，進一步提升接入使用者的網路訪問體驗等等。希望HttpDNS能為各位在解決域名解析異常及全域性流量排程失效方面提供一個簡單、可行的思路。

9、作為創業團隊，如何改造APP並支援HttpDNS？

作為創業團隊，人力、財力、技術力量可能都無暇顧及這一塊，但是移動端APP卻實實在在面臨文中提到的各種DNS問題，我們該怎麼辦呢？

9.1 使用第3方雲服務商提供的HttpDNS介面

目前，國內有一部分廠商已經提供了這個解析服務，可以直接使用第三方服務。

目前，提供 HttpDns 解析服務的第3方服務商越來多，比如：阿里雲HttpDNS 、騰訊雲HttpDNS 、華為雲HttpDNS 等。

以阿里雲的 HttpDNS為便，它的API 比較標準，直接發一個 Get 請求，帶上請求引數，返回結果以 json 返回：

http://203.107.1.1/d?host=www.52im.net

請求成功時，返回結果如下：

{
  "host": "www.linkedkeeper.com",
  "ips": [
    "115.238.23.241",
    "115.238.23.251"
  ],
  "ttl": 57
}

在移動端，將由 HttpDns 獲得的 IP 地址在原有 URL 的基礎上，將域名替換為 IP，然後用新的 URL 發起 HTTP 請求。

9.2 新浪 微博團隊分享的開源HttpDNS庫：HTTPDNSLib

HTTPDNSLib的Github地址： https://github.com/CNSRE/HTTPDNSLib

HTTPDNSLib中實現的HttpDNS互動流程原理：

從上圖中可以看出來整個業務的互動流程，使用者向查詢模組傳入一個URL地址，然後查詢模組會檢查快取是否存在，不存在從httpdnsapi介面查詢，然後經過評估模組返回。在使用者請求URL過程完畢時，需要將這次請求的結果反饋給 lib庫的評估模組由評估模組入庫記錄本次質量資料。

HttpDns Lib庫互動詳細流程：

上圖這張詳細流程圖就更深入的說了下 lib的工作原理。有兩條豎線講圖片分為了三個區域，分別是左部分、中間部分和右部分。

左部分是app主執行緒操作的事情，中間部分是app呼叫者執行緒中處理lib庫事件邏輯的事情，右面部分是新執行緒獨立處理事件的邏輯。

開始是裡客戶端呼叫方，傳入一個 url，獲取domain資訊後由查詢模組查詢domain記錄，查詢模組會從記憶體快取層查詢，記憶體快取層沒有資料會，查詢資料庫，如果資料庫也沒有資料會請求本地 LocalDNS。從三個環節中任何一個環節拿到資料後，都會進入下一個環節，如果沒有拿到資料返回null結束。進入評估模組，根據五個外掛進行排序，排序後返回資料給客戶端。

lib模組設定定時器，根據ttl過期時間來檢查domain是否需要更新。定時器是獨立執行緒，不會影響app主執行緒。 httpdns api請求資料，先從自己配置的 httpdns api介面獲取資料，如果獲取不到會從 dnspod api介面獲取如果也獲取不到直接從本地 localDNS獲取資料，（從本地localDNS獲取資料後期會改為傳送UDP包封裝dns協議從公共dns伺服器直接獲取，比如114dns等。dns伺服器地址可自行設定。）獲取到資料後進入測速模組。測速模組最新版本可以配置兩種方式，一種是http空請求。兩個http頭的互動，類似tcp首保耗時時間原理，用來測試鏈路最快。另一種是ping命令，（icmp協議）來儘量最小化流量的消耗，考慮倒可能有的伺服器禁ping就使用空http測速即可。測速後將資料插入本地 cache 即可。

下面是測試Demo的截圖：