全面理解DNS及HTTPDNS

iosmedia發表於2019-11-05
DNShttpd

說明

移動場景下DNS解析開銷是整個網路請求中不可忽略的一部分。在弱網環境下，基於UDP的LocalDNS解析非常容易出現解析超時的問題，並且即使解析成功會消耗數百毫秒乃至更甚，對我們整個業務請求而言是非常不利的，它直接影響了客戶的體驗。

對於一個比較大眾的應用而言，DNS的優化對整個應用的網路優化所佔的權重是很大的。我們接下來從以下幾個方面全面理解DNS，相信對我們開發中的網路優化會有不小的幫助。

  • DNS
    • 認識DNS
    • DNS解析相關概念
      • DNS域名層次結構
      • 權威DNS
      • 遞迴DNS
      • 公共DNS
      • 轉發DNS
    • 域名解析記錄方式
    • 域名解析過程
  • 全域性負載均衡GSLB
    • 智慧DNS
  • DNS解析存在的問題
    • DNS劫持
    • DNS解析域名時快取解析結果
    • 轉發解析
  • HTTPDNS
    • 什麼是HTTPDNS
    • HTTPDNS的特性
    • 如何支援HTTPS
  • 問題
    • 主機是如何知道DNS伺服器地的IP地址的？
    • 為什麼DNS採用UDP協議 ？

1. DNS

1.1 認識DNS

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

作為網路通訊的最靠前的一個環節，其在整個網路通訊的過程中的重要性不言而喻。

圖片

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

圖片

1.2 DNS解析相關概念

1.2.1 DNS域名層次結構

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

圖片

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服務，而傳統的遞迴DNS資訊一般由運營商分發給使用者。

在 DNS 的解析過程中，使用者向遞迴 DNS 發起請求，遞迴 DNS 向權威 DNS 請求解析結果，可以說遞迴 DNS 起到一種轉發的作用。ISP DNS 就是遞迴 DNS；同時一些個人或網際網路服務提供商也會架設自己的遞迴 DNS 開放給所有人使用，稱為公共 DNS。

運營商 anycast 官網 DNS
南京信風公共DNS 南京、濟南、芝加哥 www.114dns.com 114.114.114..114 114.114.115.115
阿里雲公共DNS 成都、深圳、杭州 http://www.alidns.com 233.5.5.5 233.6.6.6
Google Public DNS Google 36個資料中心 developers.google.com/speed/publi… 8.8.8.8 8.8.4.4

全國DNS彙總: www.114dns.com/DNS_List.ht… ipip: tools.ipip.net/dns.php

圖片

1.2.5 轉發DNS

可以理解為遞迴DNS和使用者之間的一箇中轉站，它不提供直接解析域名的服務，它將請求轉發給遞迴DNS，然後將遞迴DNS的結果轉發一下，也提供快取作用。比如，日常家用的路由器，它的DNS伺服器一般都是192.168.1.1，只是轉發給遞迴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.
複製程式碼

;; Received 239 bytes from 180.76.76.92#53(ns7.baidu.com) in 10 ms

通過上面命令我們可以看到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.12
www.a.shifen.com.	300	IN	A	180.101.49.11
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.
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.com
Server:		114.114.114.114
Address:	114.114.114.114#53

Non-authoritative answer:
www.baidu.com	canonical name = www.a.shifen.com.
Name:	www.a.shifen.com
Address: 180.101.49.11
Name:	www.a.shifen.com
Address: 180.101.49.12
複製程式碼

圖示DNS解析baidu的過程：

  1. 終端向 Local DNS發起域名解析請求
  2. Local DNS在獲取到域名請求後，首先從Root hins獲取根域名伺服器的地址(Root hints包含了網際網路DNS根伺服器的地址資訊)
  3. 獲取到了根域名伺服器地址後，Local DNS向根域名伺服器發起DNS解析請求，根域名伺服器返回頂級域名伺服器地址(com或者cn或者其它)
  4. 隨後Local DNS向com域名伺服器發起解析請求，並得到baidu.com二級域名伺服器地址
  5. Local DNS向baidu.com二級域名伺服器發起解析請求，並最終貨到了www.baidu.com 的ip地址資訊
  6. Local DNS將遞迴查詢獲得的IP地址資訊快取並返回給客戶端

3. 全域性負載均衡GSLB

GSLB是Global Server load Blance的縮寫，即全域性負載均衡。目的是實現網際網路上不同地域的伺服器間的流量調配，保證使使用者的請求能被離使用者最近或者服務質量更好的伺服器來處理。從而確保服務質量。

能通過判斷伺服器的負載，包括CPU佔用、頻寬佔用等資料，決定伺服器的可用性，同時能判斷使用者（訪問者）與伺服器間的鏈路狀況，選擇鏈路狀況最好的伺服器。因此GSLB是對伺服器和鏈路進行綜合判斷來決定由哪個地點的伺服器來提供服務，實現異地伺服器群服務質量的保證。

圖片

3.1 智慧DNS

智慧DNS是GSLB的一種應用。

圖片

2. DNS解析存在的問題

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

2.1 運營商劫持

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

圖片

2.2 DNS解析域名時快取解析結果

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

如果當LocalDNS快取的有baidu.com對應的結果，那麼他就不會像百度的權威伺服器查詢其對應的ip，而是直接返回快取中的結果。如果此時權威伺服器中的baidu.com對應的ip發生了變化，LocalDNS沒有及時更新，這樣會導致使用者訪問不到伺服器。

圖片

2.3 轉發解析

你用手機訪問baidu.com時，會到當前運營商的DNS伺服器查，然後運營商的DNS服務再去百度權威伺服器去查，最終把權威伺服器中的正確ip返回。

上面是正常的情況，但是如果當前運營商(比如聯通)的LocalDNS不訪問百度權威DNS伺服器，而是直接訪問了其它運營商(比如電信)的LocalDNS伺服器，有些小的運營商就是通過這樣做來降低成本。如果電信的LocalDNS對非自家ip的訪問限了速那麼很明顯會影響你的DNS解析時間。如果你應用中的某些服務需要運營商資訊isp(eg:只能dns, cdn等服務).

下面截圖是我手機的網路環境(NetPing開源地址：github.com/mediaios/ne…)

圖片

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

圖片

如果發生了轉發則邏輯如下：

圖片

3. HTTPDNS

3.1 什麼是HTTPDNS

HTTPDNS使用HTTP與DNS伺服器互動，代替傳統的基於UDP的DNS協議，域名解析請求直接傳送到HTTPDNS服務端，從而繞過運營商的Local DNS

圖片

圖片

3.2 HTTPDNS的特性

3.2.1 防止域名劫持

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

3.2.2 精準排程

HTTPDNS能夠直接獲取到使用者的IP地址，從而實現精確定位與導流

3.2.3 使用者連線失敗率下降

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

原來的請求地址為 “apis.juhe.cn/simpleWeath…”，通過HTTPDNS替換域名後最終的結果如下：

圖片
全面理解DNS及HTTPDNS

3.2 HTTPS IP Content

傳送HTTPS請求首先要進行SSL/TLS握手，握手過程大致如下：

  1. 客戶端發起握手請求，攜帶隨機數、支援演算法列表等引數。
  2. 服務端收到請求，選擇合適的演算法，下發公鑰證照和隨機數。
  3. 客戶端對服務端證照進行校驗，併傳送隨機數資訊，該資訊使用公鑰加密。
  4. 服務端通過私鑰獲取隨機數資訊。
  5. 雙方根據以上互動的資訊生成session ticket，用作該連線後續資料傳輸的加密金鑰。

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

  1. 客戶端用本地儲存的根證照解開證照鏈，確認服務端下發的證照是由可信任的機構頒發的。
  2. 客戶端需要檢查證照的domain域和擴充套件域，看是否包含本次請求的host。

如果上述兩點都校驗通過，就證明當前的服務端是可信任的，否則就是不可信任，應當中斷當前連線。

當客戶端使用HTTPDNS解析域名時，請求URL中的host會被替換成HTTPDNS解析出來的IP，所以在證照驗證的第2步，會出現domain不匹配的情況，導致SSL/TLS握手不成功。

4.問題

4.1 主機是如何知道DNS伺服器地的IP地址的？

通過DHCP動態獲得，或者手工配置的。

DHCP協議： DHCP（Dynamic Host Configuration Protocol，動態主機配置協議）通常被應用在大型的區域網路環境中，主要作用是集中的管理、分配IP地址，使網路環境中的主機動態的獲得IP地址、Gateway地址、DNS伺服器地址等資訊，並能夠提升地址的使用率。

4.1 為什麼DNS採用UDP協議 ？

TCP通訊過程太複雜並且開銷大，一次TCP交換需要9個包： 三個連線包，四個斷開包，一個request包，一個響應包。

UDP通訊過程簡單，只需要一個查詢包和一個響應包。

相關文章