網(wǎng)上很多人都說 DNS 根服務(wù)器只有 13 臺(tái),中國一臺(tái)也沒有。在網(wǎng)絡(luò)世界,中國被美國卡住了脖子。那 DNS 根服務(wù)器真的只有 13 臺(tái)嗎?如果是,那原因又是什么?今天就給大家說道說道。
DNS 基本概念
在回答這個(gè)問題之前,我們需要先回顧一些基本概念。DNS 是一種分層結(jié)構(gòu),這種層級(jí)就體現(xiàn)在域名的『點(diǎn)』里。以我的域名為例,TAOSHU.IN它的完整域名其實(shí)是TAOSHU.IN.。注意最后有一個(gè)點(diǎn)。它分三個(gè)層級(jí),結(jié)結(jié)構(gòu)為.?IN?TAOSHU。
DNS 又是分布式系統(tǒng),每一層級(jí)都有自己的解析服務(wù)器。.是第一層級(jí),它的解析服務(wù)器就是根服務(wù)器。第二層級(jí)是對(duì)應(yīng)我們常說的COM/NET等頂級(jí)域名 TLD,而我用的IN是印度的國家域名,跟中國的CN一樣,它們都是 CCTLD,也就是所謂的國家頂級(jí)域名。TAOSHU就是普通的一級(jí)域名。每個(gè)域名都可以自行設(shè)置子域名,不受上級(jí)域名限制。
域名解析過程也是分布式的。還是以TAOSHU.IN為例??蛻舳讼日业礁?wù)器的地址,并其查詢IN的解析服務(wù)器。再向IN的服務(wù)器查詢TAOSHU.IN的服務(wù)器。最后向TAOSHU.IN的服務(wù)器查詢具體的解析記錄,比如 A 記錄等。
當(dāng)前根服務(wù)器
從上面的過程可知,所有的 DNS 查詢都從根服務(wù)器開始。所以根服務(wù)器是整個(gè) DNS 系統(tǒng)的核心。如果根服務(wù)器出現(xiàn)故障,那所有 DNS 查詢都會(huì)失??!為了避免出現(xiàn)這種問題,人們?cè)O(shè)置了多個(gè) DNS 根服務(wù)器。發(fā)展到現(xiàn)在,互聯(lián)網(wǎng)社區(qū)累計(jì)設(shè)置了 13 臺(tái),它們分別是:
主機(jī)名 | IP 地址 | 運(yùn)營機(jī)構(gòu) | 國家 |
---|---|---|---|
a.root-servers.net | 198.41.0.4, 2001ba3e:30 | Verisign, Inc. | 美國 |
b.root-servers.net | 199.9.14.201, 2001200::b | University of Southern California, Information Sciences Institute | 美國 |
c.root-servers.net | 192.33.4.12, 20012::c | Cogent Communications | 美國 |
d.root-servers.net | 199.7.91.13, 20012d::d | University of Maryland | 美國 |
e.root-servers.net | 192.203.230.10, 2001a8::e | NASA (Ames Research Center) | 美國 |
f.root-servers.net | 192.5.5.241, 20012f::f | Internet Systems Consortium, Inc. | 美國 |
g.root-servers.net | 192.112.36.4, 200112::d0d | US Department of Defense (NIC) | 美國 |
h.root-servers.net | 198.97.190.53, 20011::53 | US Army (Research Lab) | 美國 |
i.root-servers.net | 192.36.148.17, 2001:53 | Netnod | 瑞典 |
j.root-servers.net | 192.58.128.30, 2001c27:30 | Verisign, Inc. | 美國 |
k.root-servers.net | 193.0.14.129, 2001:1 | RIPE NCC | 荷蘭 |
l.root-servers.net | 199.7.83.42, 20019f::42 | ICANN | 國際 |
m.root-servers.net | 202.12.27.33, 2001:35 | WIDE Project | 日本 |
資料來源:IANA1 資料截止時(shí)間:2023年06月06日
在 1984 年,Jon Postel 和 Paul Mockapetris 在南加州大學(xué)設(shè)立了世界上第一臺(tái)根服務(wù)器2。到了 1990 年,根服務(wù)器的數(shù)量擴(kuò)展到了 7 臺(tái),分屬不同的組織給護(hù),但全都在美國。到了 1991 年,KTH 在瑞典設(shè)立一臺(tái)根服務(wù)器。這是首次在美國之外部署根服務(wù)器。此后一直有舊的根服務(wù)器退役,新的服務(wù)器入役。到了 1995 年,根服務(wù)器已經(jīng)擴(kuò)展到 9 臺(tái)。這個(gè)時(shí)候就遇到了技術(shù)瓶頸,無法添加新的根服務(wù)器了。
到底是什么技術(shù)瓶頸呢?這就得說說 DNS 的底層實(shí)現(xiàn)細(xì)節(jié)了。
Priming 查詢
前面說所有的 DNS 查詢都從根服務(wù)器開始。那客戶端怎么知道當(dāng)前有哪些根服務(wù)器呢?沒什么好辦法,就是在各自的代碼中寫死!對(duì),是硬編碼。但我們前面也說了,在役的根服務(wù)器并非一成不變,寫死的話新添加的服務(wù)怎么生效呢?
這就用到了所謂的 Priming Queries3。簡單來說,所有 DNS 解析客戶端都隨軟件附帶一個(gè)列表文件,里面有當(dāng)前所有根服務(wù)器的信息,包括域名、IP地址等信息。這個(gè)文件叫 Root Hints,可以從 IANA 官網(wǎng)4下載。但考慮到根服務(wù)器的列表可能會(huì)變,所以客戶端需要定期從已知的根服務(wù)器查詢當(dāng)前最新的服務(wù)器列表,用的也是 DNS 協(xié)議,這類請(qǐng)求叫作 Priming 查詢。
對(duì)于客戶端來說,它先從 Root Hints 中根據(jù)某種規(guī)則5選出一臺(tái)根服務(wù)器,然后向它查詢最新的根服務(wù)器列表,并本機(jī)緩存一段時(shí)間,過期之前都以該列表為準(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í)解決這個(gè)問題很容易,完全可以要求客戶端使用 TCP 連接傳輸 Priming 查詢結(jié)果嘛??上М?dāng)時(shí)沒有采用這種方案。不過,如果是我,也不會(huì)選 TCP 方案。因?yàn)樗?DNS 查詢都走 UDP 協(xié)議,簡單而統(tǒng)一。雖然 DNS 也支持使用 TCP,但讓 Priming 查詢單獨(dú)走 TCP 明顯會(huì)讓系統(tǒng)變得很復(fù)雜。
社區(qū)最終決定想辦法壓縮查詢結(jié)果長度。
報(bào)文結(jié)構(gòu)與編碼
DNS 報(bào)文結(jié)構(gòu)如下,分為五個(gè)部分6。
+---------------------+ |Header| +---------------------+ |Question|thequestionforthenameserver +---------------------+ |Answer|RRsansweringthequestion +---------------------+ |Authority|RRspointingtowardanauthority +---------------------+ |Additional|RRsholdingadditionalinformation +---------------------+
Header
Header 為報(bào)文頭信息,長度固定為 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 這四個(gè)字段,分別表示后續(xù) Question/Answer/Authority/Additional 段的數(shù)量。
Question
Question 段保存查詢請(qǐng)求信息,通長只有一個(gè)。它分成三個(gè)部分。后兩個(gè)部分表示查詢類型和網(wǎng)絡(luò)類型。含義不重要,重要的是長度固定為 4 字節(jié)。
0123456789012345 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ || /QNAME/ // +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QTYPE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QCLASS| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
第一部分 QNAME 長度可變,保存查詢的域名。但存儲(chǔ)的方式有點(diǎn)特別。以域名A.ROOT-SERVERS.NET.為例,它會(huì)分成三部分A、ROOT-SERVERS和NET。每一部分稱作一個(gè)標(biāo)簽(Label), QNAME 字段只保存標(biāo)簽,不保存.。每個(gè)標(biāo)簽用第一個(gè)字節(jié)記錄當(dāng)前標(biāo)簽長度,后面跟著標(biāo)簽內(nèi)容。最后用一個(gè)長度為零的標(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é)。特別的,對(duì)于根域名.,它的 QNAME 編碼是:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 20|0|| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
長度為 1 字節(jié)。
Answer
Answer 段是服務(wù)器返回的響應(yīng)結(jié)果。數(shù)量為一條到多條不等。每一條稱為一個(gè) RR,全稱是 Resource Record。其結(jié)構(gòu)如下:
0123456789012345 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ || // /NAME/ || +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |TYPE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |CLASS| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |TTL| || +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |RDLENGTH| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| /RDATA/ // +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
RR 跟前面的 Question 相比多了 TTL/RDLENGTH/RDATA 三個(gè)字段。TTL 表示有效時(shí)長, 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ù)器就會(huì)在 Authority 段返回IN域名的解析服器。因?yàn)楦?wù)器并不保存TAOSHU.IN的域名信息。不過在本文中,Priming 查詢的權(quán)威服務(wù)器就是根服務(wù)器,所以此段長度為零。
最后的 Additional 段用來返回一些附加信息。Answer 中只有域名信息。我們希望直接返回 IP 地址,所以需要用到 Additional 段。Additional 中也是一條一條的 PR,計(jì)算方式跟 Answer 的一模一樣。
因?yàn)?Priming 查詢會(huì)返回所有的根服務(wù)器域名及其對(duì)應(yīng)的 IP 地址7,所以根服務(wù)器數(shù)量越多,返回的數(shù)據(jù)就越長。但 DNS 協(xié)議規(guī)定最長只能是 512 字節(jié),這就產(chǎn)生了瓶頸。
到了 1995 年,已經(jīng)開通了 9 臺(tái)根服務(wù)器,Priming 查詢結(jié)果快要超過 512 字節(jié)了。社區(qū)開始著手解決這個(gè)問題。方案是標(biāo)簽壓縮。
標(biāo)簽壓縮
壓縮辦法也很簡單,就是在 NAME 中引入指針結(jié)構(gòu):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |11|OFFSET| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DNS 還有一個(gè)規(guī)定,域名的長度不能超過 63 字節(jié)。NAME 中第一個(gè)字節(jié)表示長度,最大值就是 63,二進(jìn)制表示為00111111,可見高兩位是零。于是大家約定高兩位設(shè)為11的時(shí)候,后面的 14 位就表示從報(bào)文 Header 開始的偏移量。這樣一來,如果多個(gè) RR 的域名中有相同的部分,就不需要重復(fù)傳輸,減少響應(yīng)長度。
舉個(gè)例子,比如要同時(shí)返回A.ROOT-SERVERS.NET和B.ROOT-SERVERS.NET兩個(gè)域名,顯然它們有共同的后綴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 個(gè)字節(jié),比A.ROOT-SERVERS.NET節(jié)省了 15 個(gè)字節(jié)。
根服務(wù)器更名
要想使用壓縮,前提是所有域名有重復(fù)的部分。但之前的根服務(wù)器域名不相同,這就得改名。到了 1995 年,社區(qū)統(tǒng)一的域名為根服務(wù)器重新編組并部署標(biāo)簽壓縮功能。
舊域名 | 新域名 | 運(yùn)營機(jī)構(gòu) |
---|---|---|
NS.INTERNIC.NET | A.ROOT-SERVERS.NET | InterNIC (operated by NSI) |
NS1.ISI.EDU | B.ROOT-SERVERS.NET | Information Sciences Institute, USC |
C.PSI.NET | C.ROOT-SERVERS.NET | PSINet |
TERP.UMD.EDU | D.ROOT-SERVERS.NET | University of Maryland |
NS.NASA.GOV | E.ROOT-SERVERS.NET | NASA Ames Research Center |
NS.ISC.ORG | F.ROOT-SERVERS.NET | Internet Software Consortium |
NS.NIC.DDN.MIL | G.ROOT-SERVERS.NET | GSI (operated by NSI) |
AOS.ARL.ARMY .MIL | H.ROOT-SERVERS.NET | U.S. Army Research Lab |
NIC.NORDU.NET | I.ROOT-SERVERS.NET | NORDUnet |
上線之后,為新的根服務(wù)器留出了空間。于是在 1997 年,又上線了 J/K/L/M 四臺(tái)根服務(wù)器。
這時(shí)候 Priming 查詢響應(yīng)的返回值有多大呢?我們可以算一下:
Header 固定 12 字節(jié)
第一個(gè) PR 保存完整域名,31 字節(jié)
另外 12 PR 保存壓縮后的域名,12*15 = 180 字節(jié)
13 個(gè) 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é)。一組臺(tái)服務(wù)器需要額外占用 15+16=31 字節(jié)。理論上還可以再添加兩臺(tái)根服務(wù)器,也就是最多15臺(tái)。
如果只管根服務(wù)器功能,確實(shí)還可以添加。但是早期的根服務(wù)器同時(shí)也是COM/NET/ORG的解析服務(wù)器。客戶端可以向根服器發(fā)起針對(duì)特定COM域名的 Priming 查詢。因?yàn)轫憫?yīng)結(jié)果需要包含查詢域名 QNAME,所以上面說的 76 字節(jié)中至少要保留 64 字節(jié)給 QNAME。這樣就只剩下 12 字節(jié)。所以就不能再添加新的根服務(wù)器了。
IPv6 與 Anycast
雖然理論上是不能再加新的根服務(wù)器了,但后來網(wǎng)絡(luò)不斷發(fā)展,UDP 報(bào)文早已不需要把長度限制到 512 字節(jié)。而且引入 IPv6 網(wǎng)絡(luò)后,Priming 查詢結(jié)果中還需要返回 AAAA 記錄, 512 個(gè)字節(jié)肯定不夠用。所以社區(qū)又設(shè)計(jì)了 EDNS09 來支持返回超過 512 字節(jié)的 DNS 響應(yīng)。
理論上還是可以繼續(xù)添加新的根服務(wù)器。但為什么不加了呢?那是因?yàn)橛辛烁冗M(jìn)的技術(shù) Anycast,中文譯作任播。任播,可以簡單理解為允許不同網(wǎng)絡(luò)中的計(jì)算機(jī)共用一個(gè) IP 地址,同時(shí)對(duì)外提供 DNS 查詢服務(wù)。互聯(lián)網(wǎng)會(huì)根據(jù)客戶端的位置將請(qǐng)求路由到就近的計(jì)算機(jī)。
Anycast 技術(shù)將原來的單臺(tái)服務(wù)器變成了一組多臺(tái)服務(wù)器。到了2002年,J根服務(wù)器首次部署 Anycast 功能。到現(xiàn)在為止,前面說的13臺(tái)根服務(wù)器嚴(yán)格來說是 13 個(gè)域名并且對(duì)應(yīng) 13 對(duì) IPv4 和 IPv6 地址。每對(duì)地址之后都通過 Anycast 部署了很多臺(tái)實(shí)例,總計(jì)有超過 1500 臺(tái)根服務(wù)器實(shí)例。這些實(shí)例又稱為根鏡像服務(wù)器。
中國根服務(wù)器鏡像
雖說中國沒有自己的根服務(wù)器,但境內(nèi)還是有不少根鏡像服務(wù)器:
編號(hào) | 城市 |
---|---|
A | 廣州 |
D | 香港 臺(tái)北 |
E | 臺(tái)北 |
F | 北京 重慶 杭州 高雄 南寧 臺(tái)北 |
I | 北京 香港 沈陽 臺(tái)北 |
J | 北京 香港 湖州 上海 |
K | 北京 廣州 貴陽 臺(tái)北 |
L | 北京 長沙 ???上海 武漢 西寧 新北 鄭州 |
M | 高雄 |
大家不妨通過 Ping 命令測(cè)一下,上面的幾個(gè)根服務(wù)器的延遲都在 50ms 左右,一看就是在國內(nèi),不然不會(huì)這么快。
-
編碼
+關(guān)注
關(guān)注
6文章
932瀏覽量
54731 -
DNS
+關(guān)注
關(guān)注
0文章
215瀏覽量
19771 -
報(bào)文
+關(guān)注
關(guān)注
0文章
38瀏覽量
4012 -
根服務(wù)器
+關(guān)注
關(guān)注
1文章
7瀏覽量
3205
原文標(biāo)題:為什么 DNS 全球只有 13 臺(tái)根服務(wù)器,中國卻沒有自己的?
文章出處:【微信號(hào):良許Linux,微信公眾號(hào):良許Linux】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論