域名英文叫 Domain Name,那這個将域名轉換成 IP 的轉換器就叫 Domain Name System(域名系統),簡稱 DNS。域名系統服務(DNS Server)就是一台裝了相關軟體(一般是用 BIND,即 Berkeley Internet Name Domain,最初是由美國加州大學伯克利分校開發和維護的)的伺服器,本質上就是一個“電話本”,用來查找某個域名對應哪個IP。
這個域名到 IP 的轉換,想起來很簡單,但要實施起來有很多事情要考慮。
首先一點是,誰來負責域名、IP的配置設定與轉換呢?我們在浏覽器輸入 www.baidu.com 後,我們的電腦要去問誰關于這個域名的 IP 呢?
美國政府需要解決兩方面的事情:域名(字母位址)的管理和 IP(數字位址)的管理,即如何給全世界的計算機配置設定 IP 和域名,以及如何将域名翻譯成對應的 IP。美國政府(美國國家科學基金會)将域名委托給 NSI 公司(Network Solutions)管理,将 IP 位址委托給IANA(The Internet Assigned Numbers Authority,網際網路數字配置設定機構,從其名字就知道是幹嘛的)管理。
随着網際網路的發展與普及,其他國家對美國這種獨家壟斷越來越不滿(美國商業部在 1998 年初釋出了個綠皮書,說美國政府有對 Internet 的直接管理權,讓其他國家毛炸)。網際網路是世界的,不是你美國的,現在IP由你配置設定,域名由你解析,哪天你對某個國家不爽,就把那裡來的域名解析請求全給屏蔽了,那還得了?
但一個事實是,當時全世界的根域名解析和 IP 位址配置設定基本都是美國機構管理的,是以這事離開美國還真玩不轉。是以比較可行的方案是,對這些機構進行改革,讓其成為類似聯合國的國際性組織,脫離美國政府的管轄。
在其他國家一緻反對的情況下,美國政府在 1998 年被迫對原來的綠皮書做了修訂(人稱白皮書),提議成立個獨立的民間組織 ICANN(Internet Corporation for Assigned Names and Numbers,網際網路名稱與數字位址配置設定機構,官網 https://www.icann.org,總部在美國加州),參與管理 Internet 域名及位址資源的配置設定。起初,雖然 ICANN 參與(注意是參與)網際網路的管理,但仍然是在美國政府的授權架構下行事,受到美國政府(商務部)的監管。直到 2016 年 10 月 1 日,美國政府将網際網路域名管理權完全交給 ICANN,兩者之間的授權管理合同在這一天失效,不再續簽——就是說,從這天起,ICANN才是個名副其實的全球性獨立機構,不再受美國政府的監管(至少在名義上)。
The global coordination of the DNS Root, IP addressing, and other Internet protocol resources is performed as the Internet Assigned Numbers Authority (IANA) functions.
然而,中國的一家公司想要申請個 IP,肯定不是跑到美國找 IANA——IANA 并不管這些雞毛蒜皮的事。IP 資源是以分層組織架構來管理的,IANA 是全球總的 IP 資源管理機構,其在各大洲/區域設立多個區域網際網路注冊機構(Regional Internet Registry,RIR),IANA 主要做的事就是按照 IETF 制定的相關政策給這些 RIR 配置設定 IP 資源池(一批 IP),這些 RIR 再将這些 IP 以更小的批次粒度配置設定給下級機構(如本地網際網路注冊機構LIR、國家網際網路注冊機構NIR,也有可能直接配置設定給 ISP),這些下級機構再以更小的批次粒度配置設定給轄區的 ISP(Internet Server Provider,網際網路接入服務商,如中國電信),而個體或公司則是從 ISP 那裡申請最終的 IP。
比如中國一家公司要向中國電信申請一個 IP,而中國電信則要向中國網際網路絡資訊中心(China Internet Network Information Center,CNNIC,屬于 NIR)申請,而 CNNIC 要向亞太網際網路絡資訊中心(Asia-Pacific Network Information Center,APNIC,屬于 RIR)申請,APNIC 要向 IANA 申請(說是申請,其實是預先配置設定)。
目前 IANA 下設的RIR:
一文搞清楚 DNS 的來龍去脈
這裡是 IPV4 位址配置設定情況。
現在我們知道誰在管理全世界的域名和 IP 了(ICANN),接下來的問題是:如何将域名解析到指定的 IP?
我們還是回到上面的圖:
一文搞清楚 DNS 的來龍去脈
很簡單嘛,弄台電腦,裡面有個資料庫存儲了域名到 IP 的映射目錄,裝個 DNS Server 軟體監聽某個端口(一般是 53 端口)對外提供服務,然後廣而告之讓全世界的主機都來這裡查詢就行了。
這樣的伺服器撐不了一秒鐘。
一個直接的問題是,這樣一台伺服器如何扛得住每天百萬億次的請求?
更嚴重的問題是,如果這台伺服器被 DDoS 了,更有甚資料庫被黑了,豈不是全世界斷網摸黑了?
是以,雞蛋不能放一個籃子裡。DNS 這玩意要玩分布式。
現實中的域名結構和 DNS 解析架構跟 IP 一樣,也是分層的——是以域名和 IP 一樣也是用多個“.”隔開的。
全球的 DNS 解析從邏輯上分成三個層次:根 DNS 伺服器(Root DNS)、頂級 DNS 伺服器(TLD)、權威 DNS 伺服器:
一文搞清楚 DNS 的來龍去脈
對應地,我們看看域名的層次結構:
一文搞清楚 DNS 的來龍去脈
圖檔來自阿裡雲
對比兩張圖我們發現,域名的結構和 DNS 解析架構是一緻的——這很好了解,域名終歸是用來解析的嘛,有什麼樣的解析架構決定了有什麼樣的域名結構。是以百度的域名叫 www.baidu.com,而不是我們開始随便寫的 baidu12345678。
有了這樣的層級結構,現在我們在浏覽器輸入 www.baidu.com,浏覽器為了得到這個域名的 IP,就要在這個層級結構中從上往下問——不過實際上不是浏覽器自己去問,而是有個叫本地 DNS 伺服器(local DNS server,也叫 DNS Resolver)的家夥代勞,浏覽器問本地 DNS 伺服器 www.baidu.com 的 IP 是多少,本地 DNS 伺服器說”稍等,我幫你問問“,然後就開始了類似下面的對話:
(下面我們稱本地 DNS 伺服器叫”小助手“)
小助手先問根 DNS 伺服器:”大哥,請問 www.baidu.com 的 IP 是多少?“
根 DNS 伺服器說:”我不知道,但你可以問問 com 頂級 DNS 伺服器,他知道些 com 的内情。他的 IP 是 192.26.92.30。“
然後小助手跑去問那個 com 頂級 DNS 伺服器:”二哥,請問 www.baidu.com 的 IP 是多少?“
com 頂級 DNS 伺服器說:”我不知道,但你可以問問權威伺服器 A,他知道些 baidu.com 的内情。他的 IP 是 220.181.33.31。“
然後小助手又屁颠屁颠去問權威伺服器 A:”三哥,請問 www.baidu.com 的 IP 是多少?“
權威伺服器 A 說:”算你問對人了,www.baidu.com 的 IP 是 14.215.177.38。“
于是小助手終于拿到了 www.baidu.com 的 IP,高高興興地給到浏覽器。
(注意:實際上 www.baidu.com 做了 CNAME 解析,并且最終 IP 也不止一個。)
即先從域名的根(即”.“,有些場合下 www.baidu.com 會寫成 www.baidu.com.,最後那個”.“就是根域名)開始順藤摸瓜:. -> com -> baidu.com -> www.baidu.com。
上面過程畫成圖就是這樣:
一文搞清楚 DNS 的來龍去脈
這個本地 DNS 伺服器雖然最終問到了 IP,但心裡其實很不爽:我為了問個 IP 就周遊了一遍全世界啊。
浏覽器也不爽:問個 IP 花這麼久,你屬烏龜啊?
另外剛才說通過層級架構解決通路量問題,但從上面例子也沒發現通路量降低啊,每層伺服器都被通路了一遍。
是以在這種分層架構中有個核心要點:DNS 緩存(DNS Cache)。
域名和 IP 的映射關系有個重要的事實是,它們不常變化,特别越往上層變動頻率越低(13 台根 DNS 伺服器的域名和 IP 更是固定不變的),這種資料非常适合做緩存。
是以實際上在上面的查詢中,浏覽器所在的本地電腦和本地 DNS 伺服器都是先查它們自己的緩存,查不到才往上查。
具體是,浏覽器發出 DNS 查詢請求給本地電腦的 DNS 用戶端,DNS 用戶端先查本地 DNS 緩存有沒有對應域名的 IP 資訊(且未過期),有則直接傳回;沒有則去詢問本地 DNS 伺服器,本地 DNS 伺服器先查本地緩存中有沒有對應域名的 IP,有則傳回,沒有則往上層查。
本地 DNS 伺服器一般是 ISP 的 DNS Server 或者公共 DNS(如 114DNS),對于一些大量通路的知名網站,基本都是有緩存的。另外,即使沒有緩存,它也不一定就是從根 DNS 伺服器開始查,因為多半它也持有 TLD DNS 伺服器以及相應域名權威 DNS 伺服器的緩存,是以多數時候它是抄近道查的。
也就是說,對于絕大部分的 DNS 解析請求,在本地電腦和本地 DNS 伺服器兩層已經解決掉了,壓根不會跑到外面那三層體系中——即便這樣,全球 13 台根 DNS 伺服器每天仍要承接數百億次查詢。
一文搞清楚 DNS 的來龍去脈
全世界一共有 13 台(邏輯上)根 DNA 伺服器,分别用 a 到 m 命名,如 a.root-servers.net,b.root-servers.net。之是以是 13 台是有其曆史原因的,根據RFC 791規定,為保證 UDP 資料包傳輸成功率,盡量将資料包控制在 571 位元組以使資料包不會被分片傳輸,是以算來算去這個資料報就隻能放 13 個伺服器資訊。
這 13 台根伺服器中,一台是主伺服器(就是 a 伺服器),12 台輔助伺服器,有 10 台在美國,2 台在歐洲,1台在日本。
說 13 台有點不确切,準确說應該是 13 組,因為 a - m 每個都是全球範圍的分布式叢集,到目前為止,一共有1487 個 ROOT 執行個體(instance),這麼多叢集節點一方面大大提高請求承載能力和通路速度(通過 BGP 路由協定配置設定最近的節點),同時大大提高抗 DDoS 的能力。
這一千多個根執行個體分布如下:
一文搞清楚 DNS 的來龍去脈
我們點開中國地區的看看:
一文搞清楚 DNS 的來龍去脈
上面顯示在重慶有個 F 根,貴陽有個 K 根,武漢有兩個 L 根(L 的營運機構就是 ICANN 自己)。當然中國其他地方還有很多不同的 Root 執行個體。
從前面 DNS 查詢過程可知,根伺服器的主要作用就是告知查詢者各頂級域名(如com)對應的頂級 DNS 伺服器(TLD)的 IP 是什麼,好讓查詢者繼續往下查。是以根伺服器需要維護一個頂級域名到 TLD 伺服器位址的映射目錄,這個目錄叫 DNS 根區(DNS root zone),可以在這裡檢視完整的根區清單。下面是部分内容:
;; 一共 5 列依次是:域名、有效期、類别(IN 表示網際網路 Internet)、記錄類型(NS 表示 Name Server,A 表示 Address)、DNS 伺服器或者 IP(取決于記錄類型是 NS 還是 A),這些在後面講 DNS 協定裡面詳細說明
cn. 172800 IN NS a.dns.cn.
cn. 172800 IN NS b.dns.cn.
cn. 172800 IN NS c.dns.cn.
cn. 172800 IN NS d.dns.cn.
cn. 172800 IN NS e.dns.cn.
cn. 172800 IN NS f.dns.cn.
cn. 172800 IN NS g.dns.cn.
cn. 172800 IN NS ns.cernet.net.
......
a.dns.cn. 172800 IN A 203.119.25.1
a.dns.cn. 172800 IN AAAA 2001:dc7:0:0:0:0:0:1
b.dns.cn. 172800 IN A 203.119.26.1
c.dns.cn. 172800 IN A 203.119.27.1
d.dns.cn. 172800 IN A 203.119.28.1
d.dns.cn. 172800 IN AAAA 2001:dc7:1000:0:0:0:0:1
前面是頂級域名 cn. 對應的 DNS 伺服器。cn. 一共有 8 台 TLD 伺服器,其中 7 台是 CNNIC (中國網際網路絡資訊中心)的,1 台是 35 互聯的。注意伺服器也是用域名表示的,是以後面還需要個 A 記錄列出域名對應的 IP 位址(A 是 IPV4,AAAA 是 IPV6)。
不過,在請求根伺服器擷取 TLD 伺服器資訊之前,我們的本地 DNS 伺服器怎麼知道根伺服器的 IP 呢?
答案是寫死。ICAAN 提供了一份 named.cache 檔案,這個檔案提供了 13 台根伺服器的 IP 位址,這玩意是不會變的,我們把它 down 下來放入本地 DNS Server 配置檔案中就行了。
本地 DNS 伺服器從根伺服器那裡拿到頂級域名(如 com)對應的 TLD Server 的 IP 後,要通路 TLD Server 擷取一級域名(如 baidu.com)對應的權威 DNS 伺服器的 IP。
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
domain: COM
organisation: VeriSign Global Registry Services
address: 12061 Bluemont Way
address: Reston Virginia 20190
address: United States
......
nserver: A.GTLD-SERVERS.NET 192.5.6.30 2001:503:a83e:0:0:0:2:30
nserver: B.GTLD-SERVERS.NET 192.33.14.30 2001:503:231d:0:0:0:2:30
......
whois: whois.verisign-grs.com
status: ACTIVE
remarks: Registration information: http://www.verisigninc.com
created: 1985-01-01
changed: 2017-10-05
source: IANA
第一行說明域名是歸 IANA 管轄的,具體的營運機構是 VeriSign Global Registry Services,後面是用來解析該頂級域名的 DNS 伺服器資訊,可以看到有 13 組 DNS 伺服器(隻截取了部分),這些 DNS 伺服器同時支援 IPV4 和 IPV6。.com 下面的域名 whois 資訊都是 whois.verisign-grs.com 提供的(一般域名的 whois 資訊都是由相應頂級域名服務商提供的,如如 whois 查 baidu.com 的資訊,該資訊就是來自 Verisign 的資料庫)。最後一部分說明 com 頂級域是在 1985 年 1 月 1 日啟用的。
TLD 伺服器同樣不能告訴我們 www.baidu.com 的 IP 到底是什麼,它的資料庫裡面隻有一級域名 baidu.com 對應的權威 DNS 伺服器的 IP,是以我們還要根據其訓示去相應的權威 DNS 伺服器查最終的 IP。
一般來說大公司會搭建自己的權威 DNS 伺服器解析自己的域名,我們可以通過 whois 指令檢視域名對應的權威伺服器。
比如百度的:
# whois baidu.com
......
Name Server: ns3.baidu.com
Name Server: ns7.baidu.com
Name Server: ns4.baidu.com
Name Server: ns2.baidu.com
Name Server: ns1.baidu.com
淘寶的:
# whois taobao.com
......
Name Server: NS4.TAOBAO.COM
Name Server: NS5.TAOBAO.COM
Name Server: NS6.TAOBAO.COM
Name Server: NS7.TAOBAO.COM
新浪的:
# whois sina.com.cn
......
Name Server: ns3.sina.com.cn
Name Server: ns2.sina.com.cn
Name Server: ns4.sina.com.cn
Name Server: ns1.sina.com.cn
一般中小公司會選擇租用某些大型服務商提供的付費權威 DNS(當然也可以自己搭建,但沒必要),比如我們公司域名 weicheche.cn 用的阿裡旗下萬網的權威 DNS 伺服器:
# whois weicheche.cn
......
Name Server: dns31.hichina.com
Name Server: dns32.hichina.com
和根伺服器需要知道各 TLD 伺服器的 IP 資訊一樣(上面提到的 DNS 根區),TLD 伺服器也必須事先知道相應的權威伺服器的域名和 IP 資訊。當百度希望用 ns1.baidu.com 作為 baidu.com 的權威 DNS 伺服器時,它必須将該資訊(ns1.baidu.com 域名以及其 IP )寫到 com TLD 伺服器的資料庫中,如果以後百度想換 baidu.com 這個域名的權威 DNS 伺服器(如換成 ns1.xiaodu.com),則必須修改 com TLD 伺服器的那條記錄(一般一個域名的權威 DNS 至少要有兩台)。
權威 DNS 是可以有多級的。假如有個家政公司其一級域名叫 jiazheng.com,其 DNS 伺服器是 dns.jiazheng.com,該公司想按省份管轄服務,每個省份有自己的域名和 DNS 解析,如湖北省的叫 hb.jiazheng.com,其 DNS 伺服器是 dns-hb.jiazheng.com,廣東的叫 gd.jiazheng.com,其 DNS 伺服器是 dns-gd.jiazheng.com。另外該公司業務分家庭業務和公司業務兩大闆塊,也分别有自己的域名,比如湖北的家庭闆塊域名叫 jt.hb.jiazheng.com,公司闆塊叫 gs.hb.jiazheng.com。
這家公司需要将(而且隻需要)将一級域名 jiazheng.com 對應的 DNS 伺服器 dns.jiazheng.com 注冊到 com TLD Server 資料庫中,然後将二級域名 hb.jiazheng.com 的 DNS 伺服器 dns-hb.jiazheng.com 以及 gd.jiazheng.com 的 DNS 伺服器 dns-gd.jiazheng.com 注冊到 dns.jiazheng.com 的資料庫中。
當使用者通路 jt.hb.jiazheng.com 時,其本地 DNS 伺服器依次查根伺服器、com TLD 伺服器,com TLD 伺服器會告訴說你到 dns.jiazheng.com 這台伺服器上去查,他的 IP 是 X.X.X.X;當本地 DNS 伺服器去 dns.jiazheng.com 上查時,dns.jiazheng.com 并不能直接告訴其 IP 是多少,隻能說你要到 dns-hb.jiazheng.com 上去查,他的 IP 是 Y.Y.Y.Y(具體是傳回一個 NS 封包而非 A 封包,後面會說 DNS 封包類型);最終本地 DNS 伺服器從 dns-hb.jiazheng.com 上查到了 jt.hb.jiazheng.com 的 IP 是 Z.Z.Z.Z。
本地 DNS 并不在三級層次結構中,但它對 DNS 解析非常重要。一般個人電腦上都不會安裝 DNS Server,浏覽器也不會去各層 DNS Server 上去查,這個查詢任務是由本地 DNS 伺服器代理完成的,它接收浏覽器(其實是浏覽器所在電腦上的 DNS Client)的查詢請求,其間無論查詢道路多麼曲折,最終總要傳回該域名的 IP 給到浏覽器。
一般來說,個人的本地 DNS Server 是 ISP 自動配置設定的,或者是路由器裡面內建的。公司可能會搭建自己的本地 DNS 伺服器。也可以使用一些公共的 DNS 服務,如 114DNS(114.114.114.114)、google DNS 服務(8.8.8.8)。
Windows 上在”網絡和 Internet“中可以看到自己電腦的本地 DNS:
一文搞清楚 DNS 的來龍去脈
Mac 上在”網絡偏好設定->進階->DNS“中:
一文搞清楚 DNS 的來龍去脈
DNS 查詢是用 DNS 協定實作的,DNS 協定是應用層協定,其底層主要使用 UDP(某些場景會使用 TCP)。
DNS 伺服器存儲的那些域名到 IP 的映射叫資源記錄(Resource Record,RR),資源記錄(RR)是一個包含下列字段的 4 元祖:
(Name, Value, Type, TTL)
TTL(Time To Live)大家都熟悉,表示這條資源的緩存有效期,前面不是提過 DNS 緩存嘛,到底要緩存多久就取決于這個 TTL 的值,一般越上層的 TTL 越長。
Type 表示這是個什麼類型的封包,它決定了 Name 和 Value 的具體含義。主要用到的 Type 有 A、AAAA、CNAME、NS、MX:
A:Address 的縮寫,此時 Name 表示域名(一般是二級或多級域名),Value 表示該域名的 IPV4 位址。本地 DNS 伺服器拿到 A 記錄就可以傳回給用戶端了;
然而為了性能 DNS 底層選擇使用 UDP,而 UDP 是無連接配接傳輸協定,是以 DNS 并不能學 HTTP 那樣加個 SSL 層變成 DNSS。
IETF 為了 DNS 資料傳輸的安全性搞了個 DNSSEC(Domain Name System Security Extensions,即 DNS 安全擴充),具體内容參見 RFC2535。大緻是說既然你 UDP 資料報是無連接配接的,那我就在資料報身上(而不是連接配接)做文章,為那些資料(A、NS等記錄)生成一個簽名(如 SHA256),然後對這個簽名用非對稱加密算法(私鑰)加密一下,放在這些記錄後面(Type 叫 RRSIG,就是 Resource Record Signature 資源記錄簽名的意思),用戶端拿到資料報後,用公鑰解密出簽名資訊,并和用戶端自己對這些記錄做的簽名結果比對一下,如果不一樣說明資料就是非法的(當然用戶端用的簽名算法肯定要和伺服器端一樣的,比如都用 SHA256)。
但問題是,用戶端(本地 DNS 伺服器)怎麼知道公鑰是多少呢?是以用戶端必須再請求伺服器端(如權威 DNS 伺服器)要公鑰。
# dig www.test.com.tweb.sched.ovscdns.com. +trace
......
ovscdns.com. 172800 IN NS ns1.ovscdns.com.
ovscdns.com. 172800 IN NS ns2.ovscdns.com.
ovscdns.com. 172800 IN NS ns3.ovscdns.com.
ovscdns.com. 172800 IN NS ns4.ovscdns.com.
......
www.test.com.tweb.sched.ovscdns.com. 60 IN A 43.132.83.43
www.test.com.tweb.sched.ovscdns.com. 60 IN A 101.33.27.53
www.test.com.tweb.sched.ovscdns.com. 60 IN A 43.132.83.42
www.test.com.tweb.sched.ovscdns.com. 60 IN A 43.132.83.41
www.test.com.tweb.sched.ovscdns.com. 60 IN A 101.33.27.45
......
終于找到 IP 了,傳回了很多。
這裡 ns1.ovscdns.com. 等 DNS 伺服器就是排程伺服器,它是在傳統 DNS 伺服器的基礎上根據來源 IP 歸屬資訊(哪個地區、哪個主幹網)選擇對應最近的 CDN 節點的 IP 傳回給用戶端以實作最近通路(當然我們上面是 dig 的,不是實際場景,裡面傳回的有日本的有新加坡的)。
核心原理就是這麼簡單:通過 CNAME 将原始域名解析到加速域名,而該加速域名的權威 DNS 伺服器具有智能排程的能力(就是說這個加速域名并不是對應哪一台伺服器的 IP,而是對應該服務商的整個 CDN 節點,可以被排程 DNS 伺服器解析到任何一個結點)。
實際中會複雜很多,為了競争,各 CDN 服務商的排程能力花樣百出,遠遠不止僅通過來源 IP 排程這麼簡單,一般都會提供應用層排程(HttpDNS),可根據 Http 内容(如 url 參數、Header、path 内容執行排程)執行排程政策。
(有人說這沒關系啊,我們自己搭建個根伺服器,中國所有 DNS 伺服器都指向這個根不就行了嗎?是可以,問題是這樣的網際網路隻能在國内自嗨。有人可能覺得我們本來就是被牆在國内嘛,自嗨也沒關系嘛——那是你我這種普通人的感覺,真正重要的東西你我感覺不到,中國的網際網路不可能跟世界其他國家斷開——根伺服器必須是全球性的,一個世界隻能有一個網際網路。)
另外 IPv4 位址行将枯竭,IPv6 的推廣勢在必行,而且現在的根服以及 DNS 解析體系存在一些固有缺陷,這個檔口給了後入局者一個機會。
中國是個大國,不僅是說地大人多,而是說這幾年中國的網際網路産業發展得相當迅速,大有趕超美國的勢頭,未來的目标是萬物互聯,那時候聯網的就遠不止電腦和手機了——現在 IP 快沒了,人家不給你配置設定了,怎麼辦,都玩内網?一群 192.168 在那互通有無?