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

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

1. DNS

1.1 認(rèn)識(shí)DNS

DNS(Domain Name System)是域名“系統(tǒng)”的英文縮寫，是一種組織成域?qū)哟谓Y(jié)構(gòu)的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)命名系統(tǒng)，它用于TCP/IP網(wǎng)絡(luò)，它所提供的服務(wù)是用來(lái)將主機(jī)名和域名轉(zhuǎn)換為IP地址的工作。

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

ios10之后，apple提供的原生http請(qǐng)求方法能返回http請(qǐng)求各個(gè)階段的時(shí)間指標(biāo)，其中就包含DNS解析時(shí)間。

1.2 DNS解析相關(guān)概念

1.2.1 DNS域名層次結(jié)構(gòu)

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

1.2.2 權(quán)威DNS

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

1.2.3 遞歸DNS

遞歸DNS又稱為L(zhǎng)ocal DNS，它沒有域名解析結(jié)果的決定權(quán)，但代理了用戶向權(quán)威DNS獲取域名解析結(jié)果的過程。遞歸DNS上有緩存模塊，當(dāng)目標(biāo)域名存在緩存解析結(jié)果并且TTL未過期時(shí)（每個(gè)域名都有TTL時(shí)間，即有效生存時(shí)間，若域名解析結(jié)果緩存的時(shí)間超過TTL，需要重新向權(quán)威DNS獲取解析結(jié)果），遞歸DNS會(huì)返回緩存結(jié)果，否則，遞歸DNS會(huì)一級(jí)一級(jí)地查詢各個(gè)層級(jí)域名的權(quán)威DNS直至獲取最終完整域名的解析結(jié)果。eg: 我們自己的電腦，運(yùn)營(yíng)商提供的dns服務(wù)器等等。

1.2.4 公共DNS

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

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

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

1.3 域名解析記錄方式

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

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

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 所以我們?cè)俨橐幌?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

然后我們?cè)儆胣slookup命令查看一下百度的ip是不是上面顯示的兩個(gè):

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

3. 全局負(fù)載均衡GSLB

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

3.1 ?智能DNS

智能DNS是GSLB的一種應(yīng)用。

4. DNS解析存在的問題

有時(shí)候我們?cè)谠L問百度或者在應(yīng)用中發(fā)出一個(gè)http請(qǐng)求時(shí)，如果DNS解析被劫持，我們可能最終訪問到的不是我們想要訪問的服務(wù)器。

4.1 運(yùn)營(yíng)商劫持

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

4.2 DNS解析域名時(shí)緩存解析結(jié)果

我們?cè)陂_發(fā)中有時(shí)候會(huì)遇到這樣的情況：你是一個(gè)聯(lián)通用戶，你在手機(jī)瀏覽器中輸入baidu.com，由一個(gè)LocalDNS服務(wù)器像百度權(quán)威服務(wù)器查應(yīng)該訪問哪一臺(tái)服務(wù)器，權(quán)威把結(jié)果返回給LocalDNS服務(wù)器,localDNS服務(wù)器返回結(jié)果給用戶。

如果當(dāng)LocalDNS緩存的有baidu.com對(duì)應(yīng)的結(jié)果，那么他就不會(huì)像百度的權(quán)威服務(wù)器查詢其對(duì)應(yīng)的ip，而是直接返回緩存中的結(jié)果。如果此時(shí)權(quán)威服務(wù)器中的baidu.com對(duì)應(yīng)的ip發(fā)生了變化，LocalDNS沒有及時(shí)更新，這樣會(huì)導(dǎo)致用戶訪問不到服務(wù)器。

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

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

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

5. HTTPDNS

5.1 什么是HTTPDNS

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

5.2 HTTPDNS的特性

5.2.1 防止域名劫持

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

5.2.2 精準(zhǔn)調(diào)度

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

5.2.3 用戶連接失敗率下降

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

5.3 HTTPS IP Content

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

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

上述過程中，和HTTPDNS有關(guān)的是第3步，客戶端需要驗(yàn)證服務(wù)端下發(fā)的證書，驗(yàn)證過程有以下兩個(gè)要點(diǎn)：

客戶端用本地保存的根證書解開證書鏈，確認(rèn)服務(wù)端下發(fā)的證書是由可信任的機(jī)構(gòu)頒發(fā)的。
客戶端需要檢查證書的domain域和擴(kuò)展域，看是否包含本次請(qǐng)求的host。

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

6.問題

6.1 主機(jī)是如何知道DNS服務(wù)器地的IP地址的？

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