為什么DNS全球只有13臺根服務(wù)器，中國卻沒有自己的？

今天浩道跟大家分享一個知識掃盲點(diǎn)，即為什么DNS全球只有 13 臺根服務(wù)器，中國卻沒有自己的？

網(wǎng)上很多人都說 DNS 根服務(wù)器只有 13 臺，中國一臺也沒有。在網(wǎng)絡(luò)世界，中國被美國卡住了脖子。那 DNS 根服務(wù)器真的只有 13 臺嗎？如果是，那原因又是什么？今天就給大家說道說道。

DNS 基本概念

在回答這個問題之前，我們需要先回顧一些基本概念。DNS 是一種分層結(jié)構(gòu)，這種層級就體現(xiàn)在域名的『點(diǎn)』里。以我的域名為例，TAOSHU.IN它的完整域名其實(shí)是TAOSHU.IN.。注意最后有一個點(diǎn)。它分三個層級，結(jié)結(jié)構(gòu)為.?IN?TAOSHU。

DNS 又是分布式系統(tǒng)，每一層級都有自己的解析服務(wù)器。.是第一層級，它的解析服務(wù)器就是根服務(wù)器。第二層級是對應(yīng)我們常說的COM/NET等頂級域名 TLD，而我用的IN是印度的國家域名，跟中國的CN一樣，它們都是 CCTLD，也就是所謂的國家頂級域名。TAOSHU就是普通的一級域名。每個域名都可以自行設(shè)置子域名，不受上級域名限制。

域名解析過程也是分布式的。還是以TAOSHU.IN為例?？蛻舳讼日业礁?wù)器的地址，并其查詢IN的解析服務(wù)器。再向IN的服務(wù)器查詢TAOSHU.IN的服務(wù)器。最后向TAOSHU.IN的服務(wù)器查詢具體的解析記錄，比如 A 記錄等。

當(dāng)前根服務(wù)器

從上面的過程可知，所有的 DNS 查詢都從根服務(wù)器開始。所以根服務(wù)器是整個 DNS 系統(tǒng)的核心。如果根服務(wù)器出現(xiàn)故障，那所有 DNS 查詢都會失?。榱吮苊獬霈F(xiàn)這種問題，人們設(shè)置了多個 DNS 根服務(wù)器。發(fā)展到現(xiàn)在，互聯(lián)網(wǎng)社區(qū)累計設(shè)置了 13 臺，它們分別是：

資料來源：IANA1 資料截止時間：2023年06月06日

在 1984 年，Jon Postel 和 Paul Mockapetris 在南加州大學(xué)設(shè)立了世界上第一臺根服務(wù)器2。到了 1990 年，根服務(wù)器的數(shù)量擴(kuò)展到了 7 臺，分屬不同的組織給護(hù)，但全都在美國。到了 1991 年，KTH 在瑞典設(shè)立一臺根服務(wù)器。這是首次在美國之外部署根服務(wù)器。此后一直有舊的根服務(wù)器退役，新的服務(wù)器入役。到了 1995 年，根服務(wù)器已經(jīng)擴(kuò)展到 9 臺。這個時候就遇到了技術(shù)瓶頸，無法添加新的根服務(wù)器了。

到底是什么技術(shù)瓶頸呢？這就得說說 DNS 的底層實(shí)現(xiàn)細(xì)節(jié)了。

Priming 查詢

前面說所有的 DNS 查詢都從根服務(wù)器開始。那客戶端怎么知道當(dāng)前有哪些根服務(wù)器呢？沒什么好辦法，就是在各自的代碼中寫死！對，是硬編碼。但我們前面也說了，在役的根服務(wù)器并非一成不變，寫死的話新添加的服務(wù)怎么生效呢？

這就用到了所謂的 Priming Queries3。簡單來說，所有 DNS 解析客戶端都隨軟件附帶一個列表文件，里面有當(dāng)前所有根服務(wù)器的信息，包括域名、IP地址等信息。這個文件叫 Root Hints，可以從 IANA 官網(wǎng)4下載。但考慮到根服務(wù)器的列表可能會變，所以客戶端需要定期從已知的根服務(wù)器查詢當(dāng)前最新的服務(wù)器列表，用的也是 DNS 協(xié)議，這類請求叫作 Priming 查詢。

對于客戶端來說，它先從 Root Hints 中根據(jù)某種規(guī)則5選出一臺根服務(wù)器，然后向它查詢最新的根服務(wù)器列表，并本機(jī)緩存一段時間，過期之前都以該列表為準(zhǔn)。

因?yàn)?Priming 查詢也是用 DNS 協(xié)議，自然也走 UDP 傳輸?；ヂ?lián)網(wǎng)早期 IP 網(wǎng)絡(luò)的最大傳輸單元長度(MTU)也就五百多字節(jié)，所以 DNS 回復(fù)信息的最大長度同樣不能太長。所以 DNS 協(xié)議規(guī)定回復(fù)信息不能超過 512 字節(jié)。這就是添加根服務(wù)器遇到的技術(shù)瓶頸。

其實(shí)解決這個問題很容易，完全可以要求客戶端使用 TCP 連接傳輸 Priming 查詢結(jié)果嘛。可惜當(dāng)時沒有采用這種方案。不過，如果是我，也不會選 TCP 方案。因?yàn)樗?DNS 查詢都走 UDP 協(xié)議，簡單而統(tǒng)一。雖然 DNS 也支持使用 TCP，但讓 Priming 查詢單獨(dú)走 TCP 明顯會讓系統(tǒng)變得很復(fù)雜。

社區(qū)最終決定想辦法壓縮查詢結(jié)果長度。

報文結(jié)構(gòu)與編碼

DNS 報文結(jié)構(gòu)如下，分為五個部分6。

+---------------------+
|Header|
+---------------------+
|Question|thequestionforthenameserver
+---------------------+
|Answer|RRsansweringthequestion
+---------------------+
|Authority|RRspointingtowardanauthority
+---------------------+
|Additional|RRsholdingadditionalinformation
+---------------------+

Header

Header 為報文頭信息，長度固定為 12 字節(jié)，結(jié)構(gòu)如下：

0123456789012345
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ID|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|Opcode|AA|TC|RD|RA|Z|RCODE|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QDCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ANCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|NSCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|ARCOUNT|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Header 中跟本文內(nèi)內(nèi)直接相關(guān)的就是 QDCOUNT/ANCOUNT/NSCOUNT/ARCOUNT 這四個字段，分別表示后續(xù) Question/Answer/Authority/Additional 段的數(shù)量。

Question

Question 段保存查詢請求信息，通長只有一個。它分成三個部分。后兩個部分表示查詢類型和網(wǎng)絡(luò)類型。含義不重要，重要的是長度固定為 4 字節(jié)。

0123456789012345
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
||
/QNAME/
//
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QTYPE|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QCLASS|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

第一部分 QNAME 長度可變，保存查詢的域名。但存儲的方式有點(diǎn)特別。以域名A.ROOT-SERVERS.NET.為例，它會分成三部分A、ROOT-SERVERS和NET。每一部分稱作一個標(biāo)簽(Label)， QNAME 字段只保存標(biāo)簽，不保存.。每個標(biāo)簽用第一個字節(jié)記錄當(dāng)前標(biāo)簽長度，后面跟著標(biāo)簽內(nèi)容。最后用一個長度為零的標(biāo)簽表示結(jié)尾。所以完整的 QNAME 字段編碼為：

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20|1|A|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22|12|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24|O|O|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26|T|-|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28|S|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30|R|V|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32|E|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
34|S|3|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
36|N|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38|T|0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

長度為 20 字節(jié)。特別的，對于根域名.，它的 QNAME 編碼是：

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20|0||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

長度為 1 字節(jié)。

Answer

Answer 段是服務(wù)器返回的響應(yīng)結(jié)果。數(shù)量為一條到多條不等。每一條稱為一個 RR，全稱是 Resource Record。其結(jié)構(gòu)如下：

0123456789012345
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
||
//
/NAME/
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TYPE|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|CLASS|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TTL|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|RDLENGTH|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/RDATA/
//
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

RR 跟前面的 Question 相比多了 TTL/RDLENGTH/RDATA 三個字段。TTL 表示有效時長， RDLENGTH 表示后續(xù) RDATA 的長度，RDATA 保存實(shí)際的響應(yīng)數(shù)據(jù)。根據(jù) TYPE 和 CLASS 的不同，RDATA 內(nèi)容也各不相同。在 Priming 查詢中，RDATA 保存各根服務(wù)器的域名，編碼跟前 Question 中的 QNAME 一樣。

如果服務(wù)器返回如下一條 RR 數(shù)據(jù)：

.518400INNSa.root-servers.net.

那么 RR 的總長度是 1+2+2+4+2+20=31 字節(jié)。

Authority

Authority 段用來返回待查詢域名的權(quán)威服務(wù)器信息。比如我們嘗試向根服務(wù)器直接查詢TAOSHU.IN的A記錄，根服務(wù)器就會在 Authority 段返回IN域名的解析服器。因?yàn)楦?wù)器并不保存TAOSHU.IN的域名信息。不過在本文中，Priming 查詢的權(quán)威服務(wù)器就是根服務(wù)器，所以此段長度為零。

最后的 Additional 段用來返回一些附加信息。Answer 中只有域名信息。我們希望直接返回 IP 地址，所以需要用到 Additional 段。Additional 中也是一條一條的 PR，計算方式跟 Answer 的一模一樣。

因?yàn)?Priming 查詢會返回所有的根服務(wù)器域名及其對應(yīng)的 IP 地址7，所以根服務(wù)器數(shù)量越多，返回的數(shù)據(jù)就越長。但 DNS 協(xié)議規(guī)定最長只能是 512 字節(jié)，這就產(chǎn)生了瓶頸。

到了 1995 年，已經(jīng)開通了 9 臺根服務(wù)器，Priming 查詢結(jié)果快要超過 512 字節(jié)了。社區(qū)開始著手解決這個問題。方案是標(biāo)簽壓縮。

標(biāo)簽壓縮

壓縮辦法也很簡單，就是在 NAME 中引入指針結(jié)構(gòu)：

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|11|OFFSET|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

DNS 還有一個規(guī)定，域名的長度不能超過 63 字節(jié)。NAME 中第一個字節(jié)表示長度，最大值就是 63，二進(jìn)制表示為00111111，可見高兩位是零。于是大家約定高兩位設(shè)為11的時候，后面的 14 位就表示從報文 Header 開始的偏移量。這樣一來，如果多個 RR 的域名中有相同的部分，就不需要重復(fù)傳輸，減少響應(yīng)長度。

舉個例子，比如要同時返回A.ROOT-SERVERS.NET和B.ROOT-SERVERS.NET兩個域名，顯然它們有共同的后綴ROOT-SERVERS.NET。假設(shè)A.ROOT-SERVERS.NET的偏移量為 20，那么可以表示為：

A.ROOT-SERVERS.NET
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20|1|A|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22|12|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24|O|O|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26|T|-|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28|S|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30|R|V|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32|E|R|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
34|S|3|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
36|N|E|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38|T|0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
B.ROOT-SERVERS.NET
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40|1|B|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44|11|20|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
46|0||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

利用標(biāo)簽壓縮技術(shù)，域名B.ROOT-SERVERS.NET只需要占用 5 個字節(jié)，比A.ROOT-SERVERS.NET節(jié)省了 15 個字節(jié)。

根服務(wù)器更名

要想使用壓縮，前提是所有域名有重復(fù)的部分。但之前的根服務(wù)器域名不相同，這就得改名。到了 1995 年，社區(qū)統(tǒng)一的域名為根服務(wù)器重新編組并部署標(biāo)簽壓縮功能。

上線之后，為新的根服務(wù)器留出了空間。于是在 1997 年，又上線了 J/K/L/M 四臺根服務(wù)器。

這時候 Priming 查詢響應(yīng)的返回值有多大呢？我們可以算一下：

• Header 固定 12 字節(jié)
• 第一個 PR 保存完整域名，31 字節(jié)
• 另外 12 PR 保存壓縮后的域名，12*15 = 180 字節(jié)
• 13 個 PR 保存 A 記錄，13 * 16 = 208 字節(jié)8
• Question 段中 QTYPE 和 QCLASS 字段， 4 字節(jié)
• Question 段中 QNAME 字段，1 字節(jié)

總共為 12+31+180+208+4+1=436 字節(jié)。剩余可用 512?436=76 字節(jié)。一組臺服務(wù)器需要額外占用 15+16=31 字節(jié)。理論上還可以再添加兩臺根服務(wù)器，也就是最多15臺。

如果只管根服務(wù)器功能，確實(shí)還可以添加。但是早期的根服務(wù)器同時也是COM/NET/ORG的解析服務(wù)器?？蛻舳丝梢韵蚋靼l(fā)起針對特定COM域名的 Priming 查詢。因?yàn)轫憫?yīng)結(jié)果需要包含查詢域名 QNAME，所以上面說的 76 字節(jié)中至少要保留 64 字節(jié)給 QNAME。這樣就只剩下 12 字節(jié)。所以就不能再添加新的根服務(wù)器了。

IPv6 與 Anycast

雖然理論上是不能再加新的根服務(wù)器了，但后來網(wǎng)絡(luò)不斷發(fā)展，UDP 報文早已不需要把長度限制到 512 字節(jié)。而且引入 IPv6 網(wǎng)絡(luò)后，Priming 查詢結(jié)果中還需要返回 AAAA 記錄， 512 個字節(jié)肯定不夠用。所以社區(qū)又設(shè)計了 EDNS09 來支持返回超過 512 字節(jié)的 DNS 響應(yīng)。

理論上還是可以繼續(xù)添加新的根服務(wù)器。但為什么不加了呢？那是因?yàn)橛辛烁冗M(jìn)的技術(shù) Anycast，中文譯作任播。任播，可以簡單理解為允許不同網(wǎng)絡(luò)中的計算機(jī)共用一個 IP 地址，同時對外提供 DNS 查詢服務(wù)?；ヂ?lián)網(wǎng)會根據(jù)客戶端的位置將請求路由到就近的計算機(jī)。

Anycast 技術(shù)將原來的單臺服務(wù)器變成了一組多臺服務(wù)器。到了2002年，J根服務(wù)器首次部署 Anycast 功能。到現(xiàn)在為止，前面說的13臺根服務(wù)器嚴(yán)格來說是 13 個域名并且對應(yīng) 13 對 IPv4 和 IPv6 地址。每對地址之后都通過 Anycast 部署了很多臺實(shí)例，總計有超過 1500 臺根服務(wù)器實(shí)例。這些實(shí)例又稱為根鏡像服務(wù)器。

中國根服務(wù)器鏡像

雖說中國沒有自己的根服務(wù)器，但境內(nèi)還是有不少根鏡像服務(wù)器：

資料來源：https://root-servers.org 資料截止時間：2023年06月06日

大家不妨通過 Ping 命令測一下，上面的幾個根服務(wù)器的延遲都在 50ms 左右，一看就是在國內(nèi)，不然不會這么快。