[導讀]移動場景下DNS解析開銷是整個網絡請求中不可忽略的一部分。在弱網環(huán)境下，基于UDP的LocalDNS解析非常容易出現(xiàn)解析超時的問題，并且即使解析成功會消耗數(shù)百毫秒乃至更甚，對我們整個業(yè)務請求而言是非常不利的，它直接影響了客戶的體驗。對于一個比較大眾的應用而言，DNS的優(yōu)化對整個應...

移動場景下DNS解析開銷是整個網絡請求中不可忽略的一部分。在弱網環(huán)境下，基于UDP的LocalDNS解析非常容易出現(xiàn)解析超時的問題，并且即使解析成功會消耗數(shù)百毫秒乃至更甚，對我們整個業(yè)務請求而言是非常不利的，它直接影響了客戶的體驗。對于一個比較大眾的應用而言，DNS的優(yōu)化對整個應用的網絡優(yōu)化所占的權重是很大的。我們接下來從以下幾個方面全面理解DNS，相信對我們開發(fā)中的網絡優(yōu)化會有不小的幫助。

1. DNS

1.1 認識DNS

DNS(Domain Name System)是域名“系統(tǒng)”的英文縮寫，是一種組織成域層次結構的計算機和網絡服務命名系統(tǒng)，它用于TCP/IP網絡，它所提供的服務是用來將主機名和域名轉換為IP地址的工作。

作為網絡通信的最靠前的一個環(huán)節(jié)，其在整個網絡通信的過程中的重要性不言而喻。

ios10之后，apple提供的原生http請求方法能返回http請求各個階段的時間指標，其中就包含DNS解析時間。

1.2 DNS解析相關概念

1.2.1 DNS域名層次結構

DNS是一種分層結構，在整個互聯(lián)網中組成一個樹狀系統(tǒng)，頂層是系統(tǒng)的根域名，下層為TLD以及二級域名，葉子就構成了所謂的FQDN（Fully Qualified Domain Names），根域名通常使用"."來表示，其實際上也是由域名組成，全世界目前有13組域名根節(jié)點，由少數(shù)幾個國家進行管理，而國內僅有幾臺根節(jié)點鏡像。

1.2.2 權威DNS

權威DNS是經過上一級授權對域名進行解析的服務器，同時它可以把解析授權轉授給其他人，如COM頂級服務器可以授權xxorg.com這個域名的的權威服務器為NS.ABC.COM，同時NS.ABC.COM還可以把授權轉授給NS.DDD.COM，這樣NS.DDD.COM就成了ABC.COM實際上的權威服務器了。平時我們解析域名的結果都源自權威DNS。eg: 阿里云云解析 ?[https://wanwang.aliyun.com/domain/dns](https://wanwang.aliyun.com/domain/dns)?
復制代碼

1.2.3 遞歸DNS

遞歸DNS又稱為Local DNS，它沒有域名解析結果的決定權，但代理了用戶向權威DNS獲取域名解析結果的過程。遞歸DNS上有緩存模塊，當目標域名存在緩存解析結果并且TTL未過期時（每個域名都有TTL時間，即有效生存時間，若域名解析結果緩存的時間超過TTL，需要重新向權威DNS獲取解析結果），遞歸DNS會返回緩存結果，否則，遞歸DNS會一級一級地查詢各個層級域名的權威DNS直至獲取最終完整域名的解析結果。eg: 我們自己的電腦，運營商提供的dns服務器等等。

1.2.4 公共DNS

公共DNS是遞歸DNS的一種特例，它是一種全網開放的遞歸DNS服務，而傳統(tǒng)的遞歸DNS信息一般由運營商分發(fā)給用戶。
在 DNS 的解析過程中，用戶向遞歸 DNS 發(fā)起請求，遞歸 DNS 向權威 DNS 請求解析結果，可以說遞歸 DNS 起到一種轉發(fā)的作用。ISP DNS 就是遞歸 DNS；同時一些個人或互聯(lián)網服務提供商也會架設自己的遞歸 DNS 開放給所有人使用，稱為公共 DNS。

全國DNS匯總: ?www.114dns.com/DNS_List.ht… ?ipip: tools.ipip.net/dns.php
1.2.5 轉發(fā)DNS

可以理解為遞歸DNS和用戶之間的一個中轉站，它不提供直接解析域名的服務，它將請求轉發(fā)給遞歸DNS，然后將遞歸DNS的結果轉發(fā)一下，也提供緩存作用。比如，日常家用的路由器，它的DNS服務器一般都是192.168.1.1，只是轉發(fā)給遞歸DNS。

1.3 域名解析記錄方式

域名解析記錄主要分為A記錄、MIX記錄、CNAME記錄、NS記錄和TXT記錄：

A記錄：
A代表Address,用來指定域名對應的ip,例如將www.hello.com指定到 113.112.3.xxx, A記錄可以將多個域名解析到一個ip地址，但是不能講一個域名解析到多個ip地址
MIX記錄：
Mail Exchange，就是可以將某個域名下的郵件服務器直線給自己的Mail Server
CNAME記錄：
Canonical Name，即別名解析。
所謂別名解析就是可以為一個域名設置一個或者多個別名，如將aaa.com解析到bbb.net、將ccc.com也解析到bbb.net，其中bbb.net分別是aaa.com和ccc.com的別名
NS記錄：
為某個域名指定DNS解析服務器，也就是這個域名由指定的IP地址的DNS服務器解析
TXT記錄：
為某個主機名或域名設置說明，如可以為ucloud.cn是指TXT記錄為“中立安全科信賴”這樣的說明

1.4 域名解析過程

以下是在終端中dig百度顯示的具體過程：

macdeiMac:~ ethan$ dig trace www.baidu.com?

; <<>> DiG 9.10.6 <<>> trace www.baidu.com;; global options: cmd. 1615 IN NS a.root-servers.net.. 1615 IN NS g.root-servers.net.. 1615 IN NS f.root-servers.net.. 1615 IN NS l.root-servers.net.. 1615 IN NS m.root-servers.net.. 1615 IN NS j.root-servers.net.. 1615 IN NS k.root-servers.net.. 1615 IN NS c.root-servers.net.. 1615 IN NS b.root-servers.net.. 1615 IN NS d.root-servers.net.. 1615 IN NS i.root-servers.net.. 1615 IN NS e.root-servers.net.. 1615 IN NS h.root-servers.net.;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 10 ms

com. 172800 IN NS a.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.com. 172800 IN NS c.gtld-servers.net.com. 172800 IN NS d.gtld-servers.net.com. 172800 IN NS e.gtld-servers.net.com. 172800 IN NS f.gtld-servers.net.com. 172800 IN NS g.gtld-servers.net.com. 172800 IN NS h.gtld-servers.net.com. 172800 IN NS i.gtld-servers.net.com. 172800 IN NS j.gtld-servers.net.com. 172800 IN NS k.gtld-servers.net.com. 172800 IN NS l.gtld-servers.net.com. 172800 IN NS m.gtld-servers.net.com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

com.      86400  IN  RRSIG  DS 8 1 86400 20191112050000 20191030040000 22545 . Sr1g7h DSqi ekBQQS2ZBc/jt0zL IR Od/R9TnMjcy8Mw9RxLrMY2pm 1VYNqL5cAME1stSAfRUKwjD/vixnCeVLoJ6idCFOZeB t/tTFQF/jfk1 td66pW9V/WgLIvslAwEZjidVeUFYERc7hZXr10BgzryZthizHISimuiQ qBjoIQN/uYULTnmePkIW07mnJXc9/AVZrjeI1AmvYC7wE0uR7DWNg1Ig dL4DaLDOM30qN7FBAD7K091uEgctpdxd/8G5XoYclSqroN4G6RibvkWT /vPCFRUzoaxembT5tR7gIz7gxdhN1r8NBD468JTG180MNUvb16Z/87U6 7UkMrg==

;; Received 1173 bytes from 192.58.128.30#53(j.root-servers.net) in 77 ms

baidu.com. 172800 IN NS ns2.baidu.com.baidu.com. 172800 IN NS ns3.baidu.com.baidu.com. 172800 IN NS ns4.baidu.com.baidu.com. 172800 IN NS ns1.baidu.com.baidu.com. 172800 IN NS ns7.baidu.com.

CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A? NS SOA RRSIG DNSKEY NSEC3PARAM

CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20191103044815 20191027033815 12163 com. U/FwNWeuKzR/uT2X/8Cf9TQmnaMdWf6XwBrFIIOCQ/kfKaOExEiT8LSQ 13OaEjtvFOOlIPK0XIbsL dgGPYb/UV6sipBeQ1n8KuK18m3bYk47Ely oe 3VVp0zaiXt9DZrmRRenBB13o0DPqCbRHAHq1pj5zG5VkMufu9L/TT g80XlNukAMcu4GrV4VP8OimOQxz7HJbadci2oYn3beiHqQ==

HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HPVVN3Q5E5GOQP2QFE2LEM4SVB9C0SJ6? NS DS RRSIG

HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20191105055359 20191029034359 12163 com. J5Dq0lGkcejjg1vPqWDBvNYaAhqFF3Ck8trKj4tgW5Z1bmoXsHGU6/Cl y3GlLfzb49xjiXzxVLCuAQJ9uLuKSX5cn kesc8rwYqcVXU4nXbD5jzo u3CK2yHD3FqPDCOKlMSNy3KKkL03bB3DfmvAae/qQs7xSe6VTpCkR6v/ lo3UA/pMfTYBjSIOvR2KmpM9yFLmN5LXAQW3rNH8sW91BA==

;; Received 761 bytes from 192.26.92.30#53(c.gtld-servers.net) in 241 ms

www.baidu.com. 1200 IN CNAME www.a.shifen.com.a.shifen.com. 1200 IN NS ns2.a.shifen.com.a.shifen.com. 1200 IN NS ns3.a.shifen.com.a.shifen.com. 1200 IN NS ns4.a.shifen.com.a.shifen.com. 1200 IN NS ns5.a.shifen.com.a.shifen.com. 1200 IN NS ns1.a.shifen.com.

通過上面命令我們可以看到DNS解析的逐步過程，其中最后一步我們可以看到www.baidu.com 被CNAME到 www.a.shifen.com 所以我們再查一下 www.a.shifen.com 即可看到其ip.

;; Received 215 bytes from 220.181.33.31#53(ns2.baidu.com) in 28 ms

www.a.shifen.com. 300 IN A 180.101.49.12www.a.shifen.com. 300 IN A 180.101.49.11a.shifen.com. 1200 IN NS ns4.a.shifen.com.a.shifen.com. 1200 IN NS ns5.a.shifen.com.a.shifen.com. 1200 IN NS ns1.a.shifen.com.a.shifen.com. 1200 IN NS ns2.a.shifen.com.a.shifen.com. 1200 IN NS ns3.a.shifen.com.;; Received 236 bytes from 180.76.76.95#53(ns5.a.shifen.com) in 9 ms

然后我們再用nslookup命令查看一下百度的ip是不是上面顯示的兩個:

macdeiMac:~ ethan$ nslookup www.baidu.comServer: 114.114.114.114Address: 114.114.114.114#53

Non-authoritative answer:www.baidu.com canonical name = www.a.shifen.com.Name: www.a.shifen.comAddress: 180.101.49.11Name: www.a.shifen.comAddress: 180.101.49.12圖示DNS解析baidu的過程：

終端向 Local DNS發(fā)起域名解析請求
Local DNS在獲取到域名請求后，首先從Root hins獲取根域名服務器的地址(Root hints包含了互聯(lián)網DNS根服務器的地址信息)
獲取到了根域名服務器地址后，Local DNS向根域名服務器發(fā)起DNS解析請求，根域名服務器返回頂級域名服務器地址(com或者cn或者其它)
隨后Local DNS向com域名服務器發(fā)起解析請求，并得到baidu.com二級域名服務器地址
Local DNS向baidu.com二級域名服務器發(fā)起解析請求，并最終貨到了www.baidu.com 的ip地址信息
Local DNS將遞歸查詢獲得的IP地址信息緩存并返回給客戶端

3. 全局負載均衡GSLB

GSLB是Global Server load Blance的縮寫，即全局負載均衡。目的是實現(xiàn)互聯(lián)網上不同地域的服務器間的流量調配，保證使用戶的請求能被離用戶最近或者服務質量更好的服務器來處理。從而確保服務質量。能通過判斷服務器的負載，包括CPU占用、帶寬占用等數(shù)據(jù)，決定服務器的可用性，同時能判斷用戶（訪問者）與服務器間的鏈路狀況，選擇鏈路狀況最好的服務器。因此GSLB是對服務器和鏈路進行綜合判斷來決定由哪個地點的服務器來提供服務，實現(xiàn)異地服務器群服務質量的保證。

3.1 ?智能DNS

智能DNS是GSLB的一種應用。

4. DNS解析存在的問題

有時候我們在訪問百度或者在應用中發(fā)出一個http請求時，如果DNS解析被劫持，我們可能最終訪問到的不是我們想要訪問的服務器。

4.1 運營商劫持

DNS劫持就是通過劫持了 DNS 服務器，通過某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，導致對該域名的訪問由原 IP 地址轉入到修改后的指定 IP，其結果就是對特定的網址不能訪問或訪問的是假網址，從而實現(xiàn)竊取資料或者破壞原有正常服務的目的。

4.2 DNS解析域名時緩存解析結果

我們在開發(fā)中有時候會遇到這樣的情況：你是一個聯(lián)通用戶，你在手機瀏覽器中輸入baidu.com，由一個LocalDNS服務器像百度權威服務器查應該訪問哪一臺服務器，權威把結果返回給LocalDNS服務器,localDNS服務器返回結果給用戶。

如果當LocalDNS緩存的有baidu.com對應的結果，那么他就不會像百度的權威服務器查詢其對應的ip，而是直接返回緩存中的結果。如果此時權威服務器中的baidu.com對應的ip發(fā)生了變化，LocalDNS沒有及時更新，這樣會導致用戶訪問不到服務器。

4.3 轉發(fā)解析你用手機訪問baidu.com時，會到當前運營商的DNS服務器查，然后運營商的DNS服務再去百度權威服務器去查，最終把權威服務器中的正確ip返回。上面是正常的情況，但是如果當前運營商(比如聯(lián)通)的LocalDNS不訪問百度權威DNS服務器，而是直接訪問了其它運營商(比如電信)的LocalDNS服務器，有些小的運營商就是通過這樣做來降低成本。如果電信的LocalDNS對非自家ip的訪問限了速那么很明顯會影響你的DNS解析時間。如果你應用中的某些服務需要運營商信息isp(eg:只能dns, cdn等服務).下面截圖是我手機的網路環(huán)境(NetPing開源地址：github.com/mediaios/ne…)

我直接ping百度的地址，然后用wireshark抓包結果，正常結果如下：

如果發(fā)生了轉發(fā)則邏輯如下：

5. HTTPDNS

5.1 什么是HTTPDNS

HTTPDNS使用HTTP與DNS服務器交互，代替?zhèn)鹘y(tǒng)的基于UDP的DNS協(xié)議，域名解析請求直接發(fā)送到HTTPDNS服務端，從而繞過運營商的Local DNS

5.2 HTTPDNS的特性

5.2.1 防止域名劫持

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

5.2.2 精準調度

HTTPDNS能夠直接獲取到用戶的IP地址，從而實現(xiàn)精確定位與導流

5.2.3 用戶連接失敗率下降

通過算法降低以往失敗率過高的服務器排序，通過時間近期訪問過的數(shù)據(jù)提高服務器排序，通過歷史訪問成功記錄提高服務器排序。原來的請求地址為 “apis.juhe.cn/simpleWeath…”，通過HTTPDNS替換域名后最終的結果如下：

5.3 HTTPS IP Content

發(fā)送HTTPS請求首先要進行SSL/TLS握手，握手過程大致如下：

客戶端發(fā)起握手請求，攜帶隨機數(shù)、支持算法列表等參數(shù)。
服務端收到請求，選擇合適的算法，下發(fā)公鑰證書和隨機數(shù)。
客戶端對服務端證書進行校驗，并發(fā)送隨機數(shù)信息，該信息使用公鑰加密。
服務端通過私鑰獲取隨機數(shù)信息。
雙方根據(jù)以上交互的信息生成session ticket，用作該連接后續(xù)數(shù)據(jù)傳輸?shù)募用苊荑€。

上述過程中，和HTTPDNS有關的是第3步，客戶端需要驗證服務端下發(fā)的證書，驗證過程有以下兩個要點：

客戶端用本地保存的根證書解開證書鏈，確認服務端下發(fā)的證書是由可信任的機構頒發(fā)的。
客戶端需要檢查證書的domain域和擴展域，看是否包含本次請求的host。

如果上述兩點都校驗通過，就證明當前的服務端是可信任的，否則就是不可信任，應當中斷當前連接。當客戶端使用HTTPDNS解析域名時，請求URL中的host會被替換成HTTPDNS解析出來的IP，所以在證書驗證的第2步，會出現(xiàn)domain不匹配的情況，導致SSL/TLS握手不成功。

6.問題

6.1 主機是如何知道DNS服務器地的IP地址的？

通過DHCP動態(tài)獲得，或者手工配置的。DHCP協(xié)議：DHCP（Dynamic Host Configuration Protocol，動態(tài)主機配置協(xié)議）通常被應用在大型的局域網絡環(huán)境中，主要作用是集中的管理、分配IP地址，使網絡環(huán)境中的主機動態(tài)的獲得IP地址、Gateway地址、DNS服務器地址等信息，并能夠提升地址的使用率。