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

DNS 基本概念

在回答這個問題之前，我們需要先回顧一些基本概念。DNS 是一種分層結(jié)構(gòu)，這種層級就體現(xiàn)在域名的『點』里。以我的域名為例，TAOSHU.IN它的完整域名其實是TAOSHU.IN.。注意最后有一個點。它分三個層級，結(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 查詢都會失??！為了避免出現(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ù)量擴展到了 7 臺，分屬不同的組織給護，但全都在美國。到了 1991 年，KTH 在瑞典設(shè)立一臺根服務(wù)器。這是首次在美國之外部署根服務(wù)器。此后一直有舊的根服務(wù)器退役，新的服務(wù)器入役。到了 1995 年，根服務(wù)器已經(jīng)擴展到 9 臺。這個時候就遇到了技術(shù)瓶頸，無法添加新的根服務(wù)器了。

到底是什么技術(shù)瓶頸呢？這就得說說 DNS 的底層實現(xiàn)細節(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ù)器列表，并本機緩存一段時間，過期之前都以該列表為準(zhǔ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ù)瓶頸。

其實解決這個問題很容易，完全可以要求客戶端使用 TCP 連接傳輸 Priming 查詢結(jié)果嘛。可惜當(dāng)時沒有采用這種方案。不過，如果是我，也不會選 TCP 方案。因為所有 DNS 查詢都走 UDP 協(xié)議，簡單而統(tǒng)一。雖然 DNS 也支持使用 TCP，但讓 Priming 查詢單獨走 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 長度可變，保存查詢的域名。但存儲的方式有點特別。以域名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 保存實際的響應(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域名的解析服器。因為根服務(wù)器并不保存TAOSHU.IN的域名信息。不過在本文中，Priming 查詢的權(quán)威服務(wù)器就是根服務(wù)器，所以此段長度為零。

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

因為 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，二進制表示為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ù)器功能，確實還可以添加。但是早期的根服務(wù)器同時也是COM/NET/ORG的解析服務(wù)器?？蛻舳丝梢韵蚋靼l(fā)起針對特定COM域名的 Priming 查詢。因為響應(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ù)器。但為什么不加了呢？那是因為有了更先進的技術(shù) Anycast，中文譯作任播。任播，可以簡單理解為允許不同網(wǎng)絡(luò)中的計算機共用一個 IP 地址，同時對外提供 DNS 查詢服務(wù)?；ヂ?lián)網(wǎng)會根據(jù)客戶端的位置將請求路由到就近的計算機。

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

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

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

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