全面理解DNS及HTTPDNS

時間  2021-08-12
標籤 php html ios git github 算法 api 瀏覽器 緩存 安全 欄目 系統網絡 简体版
原文   原文鏈接

說明

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

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

  • 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地址的工做。ios

做爲網絡通訊的最靠前的一個環節，其在整個網絡通訊的過程當中的重要性不言而喻。git

圖片

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

圖片

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服務器等等。api

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替換域名後最終的結果以下：

圖片

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通訊過程簡單，只須要一個查詢包和一個響應包。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程