根域名服務器只有13臺？

時間：2023-02-20 01:54:01 | 來源：建站知識

時間：2023-02-20 01:54:01 來源：建站知識

根域名服務器只有13臺？：根域名服務器只有13臺這個說法流傳甚廣，哪怕你不了解DNS協(xié)議，也有可能聽說過這個說法，但事實真的如此嗎？

當然不可能啦！世界上有45億的因特網(wǎng)用戶，哪怕有遞歸名稱服務器作為緩沖，根域名服務器只有13臺是不可能應付的了如此大規(guī)模的查詢的。

只有13臺的說法來源

根域名服務器只有13臺的說法是怎么來的呢？這是源于DNS協(xié)議在不使用EDNS0和TCP協(xié)議時，通過UDP協(xié)議傳輸?shù)腄NS消息最大長度需要限制在512字節(jié)（不包括IP頭部、UDP頭部），超出部分要被截斷。有了最大長度限制后，一個UDP協(xié)議傳輸?shù)腄NS響應能夠返回的資源記錄數(shù)量就是有限的。

512字節(jié)的限制是在RFC 1035中規(guī)定的，為了更好的性能我們需要將響應限制在一個響應報文中完成，也就是只有512字節(jié)可以用了。

當我們查詢根域（.）的NS記錄時，512字節(jié)只夠返回包含13個由A-M命名的根域名服務器的NS記錄和A記錄的響應。NS記錄在回答區(qū)段中，A記錄在額外信息區(qū)段中，A記錄用于幫助你接下來向根域名服務器進一步查詢。

為什么需要查詢根域的NS記錄？

遞歸名稱服務器中的根名稱服務器信息是需要管理員提前配置的，需要一個的包含根名稱服務器的域名和IP地址的根提示文件。

根名稱服務器的域名和IP地址有可能會改變，導致根提示文件中的信息過時，因此遞歸名稱服務器需要一種不需要依賴管理員更新自己根提示文件信息的機制，這就是我們需要查詢根域的NS記錄的原因。我們稱這種查詢?yōu)椤皢硬樵儭?，在RFC 8109中有對啟動查詢的更多描述。直至今天，根名稱服務器的使用的IP地址仍然會改變，不過域名在1997年已經(jīng)穩(wěn)定。

遞歸名稱服務器剛啟動時在根提示文件中隨機選擇一個根名稱服務器發(fā)送啟動查詢，如果查詢失敗則隨機選擇下一個。根域的NS記錄與其他資源記錄相同，都是有TTL的，TTL過期后遞歸名稱服務器就需要重新發(fā)送啟動查詢。

現(xiàn)在的啟動查詢要求使用EDNS0，需要至少能夠處理1024字節(jié)。不過我們不能用現(xiàn)在的技術去套用在曾經(jīng)的歷史上，決定根名稱服務器只有13臺的時候，EDNS0還沒有出現(xiàn)，還存在512字節(jié)的限制。

限制512字節(jié)的原因

為什么需要限制DNS消息長度呢？這是因為在DNS出現(xiàn)的年代，網(wǎng)絡設備還沒有處理長度比較大的數(shù)據(jù)報的能力。另一方面是為了避免IP分片，在分片重組過程中只要其中一個分片丟失，就會導致整個數(shù)據(jù)報無法被重組接收。為了提高可靠性需要盡量避免IP分片（TCP中也有類似的功能，MSS選項）。

為什么是512字節(jié)呢？為什么不是514字節(jié)，不是522字節(jié)呢？實際上不僅僅是DNS協(xié)議有512字節(jié)的限制，很多其他的基于UDP的協(xié)議也有512字節(jié)的限制，例如RIP協(xié)議（RFC 1058）、HSP協(xié)議（RFC 3652）。那這個512是怎么來的呢？我能找到最好的解釋在IP協(xié)議的RFC 791中，以下為相關描述：

Total Length: 16 bits
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the length of
a datagram to be up to 65,535 octets. Such long datagrams are
impractical for most hosts and networks. All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information. For
example, this size allows a data block of 512 octets plus 64 header
octets to fit in a datagram. The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing a
margin for headers of higher level protocols.
...
Fragmentation and Reassembly.
...
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled.
...

以上內(nèi)容規(guī)定了IP數(shù)據(jù)報最大總長度可以為65535字節(jié)（包括頭部和數(shù)據(jù)），但是接收這么長的數(shù)據(jù)報對于當時的大多數(shù)主機和網(wǎng)絡來說都是不切實際的。不過所有主機必須準備好接收總長度最多為576字節(jié)的IP數(shù)據(jù)報，無論是單個IP數(shù)據(jù)報形式還是IP分片的形式。選擇576是為了允許使用合理的數(shù)據(jù)塊大小傳輸IP頭部以外的信息。舉個例子，576字節(jié)允許傳輸512字節(jié)的數(shù)據(jù)塊加上64字節(jié)的頭部在一個數(shù)據(jù)報中。最大的IP頭部是60字節(jié)，而常用的IP頭部是20字節(jié)（無IP選項），保留了空間給其他高層協(xié)議頭部。

我猜測上述的協(xié)議就是基于此處的舉例把512字節(jié)作為消息的最大長度限制，常用IP頭部20字節(jié) + UDP頭部8字節(jié) + 512字節(jié)消息為540字節(jié)，低于規(guī)定必須準備好接收的576字節(jié)，能夠兼容所有主機。同時剩余的36字節(jié)也預留了空間給額外的IP選項、二次封裝（IPsec）等需求。

512字節(jié)可以容納多少臺根域名服務器？

我們先來明確一下DNS響應報文的長度計算方式。DNS頭部是固定的12字節(jié)。問題區(qū)段是1字節(jié)的根域0 + 2字節(jié)查詢類型 + 2字節(jié)查詢類一共是5字節(jié)。回答區(qū)段的每個NS記錄都會在額外信息區(qū)段添加對應的A記錄（當時IPv6還沒出現(xiàn)，所以不考慮AAAA記錄）。NS記錄為1字節(jié)根域0 + 2字節(jié)類型 + 2字節(jié)類 + 4字節(jié)TTL + 2字節(jié)資源數(shù)據(jù)長度 + 不定長度的根服務器域名，一共是11字節(jié)固定部分 + 不定長度數(shù)據(jù)。A記錄是2字節(jié)的壓縮標簽（指向NS記錄中的根服務器域名） + 10字節(jié)資源記錄固定部分（類型、類、TTL、資源數(shù)據(jù)長度）+ 4字節(jié)IPv4地址，一共是16字節(jié)。

總結起來就是12 + 5 + 11n + 16n + 所有根服務器域名的數(shù)據(jù)標簽的長度總和，得到結果為DNS響應報文總長度，n為根服務器數(shù)量。

事實上512字節(jié)曾經(jīng)還無法容納13臺這么多，現(xiàn)在能容納13臺A-M根域名服務器已經(jīng)是改進過的了。根域名服務器并不是一開始就有13臺的，也并不是一開始就是使用a.root-servers.net.的形式的域名。

根域名服務器系統(tǒng)的歷史

在DNS剛發(fā)明后的1984年首臺根域名服務器運行在南加州大學（USC）的信息科學研究所（ISI）為ARPANET提供服務。在1985年ISI添加了一臺新的根域名服務器，斯坦福國際研究院（SRI International）也部署了根域名服務器。同樣在1985年，美國彈道研究實驗室（BRL）建立了根域名服務器為MILNET提供服務。此時一共有四臺根域名服務器。

/begin{array}[b] {|c|c|} /hline 域名 & IP地址 & 組織 // /hline SRI-NIC & { 10.0.0.51 // 26.0.0.73 } & 斯坦福國際研究院 // /hline ISIB & 10.3.0.52 & USC信息科學研究所 // /hline ISIC & 10.0.0.52 & USC信息科學研究所 // /hline BRL-AOS & { 192.5.25.82 // 128.20.1.2 } & 美國彈道研究實驗室 // /hline /end{array}//

以上表格中的“域名”看起來和現(xiàn)在不一樣是因為當時還沒有頂級域名（TLD）這個概念，DNS剛發(fā)明的時候僅僅為了取代存儲主機名的hosts。在1986年ISIB停止服務，由另一臺域名為ISIA的根域名服務器代替。在1987年引入頂級域名后SRI-NIC改名為SRI-NIC.ARPA，ISIA改名為http://A.ISI.EDU，ISIC改名為http://C.ISI.EDU，BRL-AOS改名為BRL-AOS.ARPA。

在1987年隨著NSFNET的流量和使用人數(shù)增長，現(xiàn)有的根域名服務器已經(jīng)不夠用了。為了解決這個問題，經(jīng)過IETF會議的討論，決定增加三個新的根域名服務器，分別為：馬里蘭大學的http://TERP.UMD.EDU、美國國家航空航天局（NASA）的http://NS.NASA.GOV、倫斯勒理工大學（RPI）的http://C.NYSER.NET，為NSFNET、ARPANET等網(wǎng)絡提供服務。同樣在1987年，為了繼續(xù)對MILNET進行從hosts到DNS的遷移，甘特空軍基地（Gunter AFS）也建立了根域名服務器GUNTER-ADAM.ARPA，為MILNET提供服務。在1987年底http://C.ISI.EDU停用。

在1988年美國國防數(shù)據(jù)網(wǎng)（DDN）繼續(xù)對MILNET實施域名解析的第二階段改造，將SRI-NIC.ARPA改名為NIC.DDN.MIL，BRL-AOS.ARPA改名為AOS.BRL.MIL，GUNTER-ADAM.ARPA改名為GUNTER-ADAM.AF.MIL。

在1990年，隨著ARPANET、MILNET等網(wǎng)絡逐漸被淘汰，Gunter AFS建立的GUNTER-ADAM.AF.MIL停止服務，NIC.DDN.MIL停止服務，DDN建立了新的根域名服務器NS.NIC.DDN.MIL。

隨著因特網(wǎng)在歐洲的發(fā)展，越來越需要在歐洲建立根域名服務器，減少對美國根域名服務器依賴（當時的跨國網(wǎng)絡非常不穩(wěn)定）。最終在1991年在瑞典皇家理工學院網(wǎng)絡運營中心（KTHNOC）部署了第一臺不在美國的根域名服務器http://NIC.NORDU.NET，支持多種網(wǎng)絡協(xié)議。

在1991年美國國防信息系統(tǒng)局將網(wǎng)絡信息中心（DDN-NIC）交給了政府系統(tǒng)公司（GSI），GSI將其外包給了網(wǎng)絡解決方案公司（NSI），交接后http://A.ISI.EDU停止服務，由http://KAVA.NISC.SRI.COM取代。

從80年代開始DDN-NIC一直負責域名注冊，因為當時大部分都是軍事用途，不過從90年代開始，學術機構占了新注冊域名的大部分，軍方不愿意為其提供資金。美國聯(lián)邦網(wǎng)絡委員會要求國家科學基金會為非軍事用途域名注冊提供資金，在1992年經(jīng)過招標后由美國電話電報公司（AT&T）、通用原子公司（GA）、網(wǎng)絡解決方案公司（NSI）合作提供數(shù)據(jù)庫服務、信息服務、非軍事域名注冊服務，采用了InterNIC作為合作名稱。在1993年NSI贏得了管理域名注冊服務的競標，IANA同意其部署一臺新的根域名服務器http://NS.INTERNET.NET。

在1994年KAVA.NISC.SRI.COMIANA停止提供服務，由http://NS1.ISI.EDU取代。同年因特網(wǎng)軟件聯(lián)盟（ISC）請求在其部署新的根域名服務器，IANA同意后添加新根域名服務器http://NS.ISC.ORG。在1994年年底 http://C.NYSER.NET改為http://C.PSI.NET。

/begin{array}[b] {|c|c|} /hline 域名 & IP地址 & 組織 // /hline NS.INTERNET.NET & 198.41.0.4 & InterNIC // /hline NS1.ISI.EDU & 128.9.0.107 & USC信息科學研究所 // /hline C.PSI.NET & 192.33.4.12 & PSINet // /hline TERP.UMD.EDU & 128.8.10.90 & 馬里蘭大學 // /hline NS.NASA.GOV & 192.203.230.10 & 美國國家航空航天局 // /hline NS.ISC.ORG & 192.5.5.241 & 因特網(wǎng)軟件聯(lián)盟 // /hline NS.NIC.DDN.MIL & 192.112.36.4 & 政府系統(tǒng)公司 // /hline AOS.ARL.ARMY.MIL & 128.63.2.53 & 美國軍事研究所 // /hline NIC.NORDU.NET & 192.36.148.17 & 瑞典皇家理工學院 // /hline /end{array}//

以上為此時的根域名服務器列表，一共有9臺，DNS響應已經(jīng)快接近512字節(jié)的極限了。我們計算一下以上列表構成的DNS響應報文大小為12 + 5 + 11 * 9 + 16 * 9 + (17 + 13 + 11 + 14 + 13 + 12 + 16 + 18 + 15) = 389字節(jié)。

假設一個新的根域名服務器的域名長度為15字節(jié)，那么就需要占用11 + 15 + 16 = 42字節(jié)，512 - 389 = 123字節(jié)， 123 / 42 ≈ 2.9，也就是只能再增加 2 - 3個根域名服務器，最多只能容納9 + 3 = 12個根域名服務器。

為了繼續(xù)添加更多的根域名服務器Bill Manning和Paul Vixie發(fā)起了重命名根域名服務器的域名的計劃，將所有根域名服務器放在http://root-servers.net域下，這樣就可以使用壓縮標簽節(jié)省空間。

IANA在1995年同意了重命名計劃，使用單個字母表示一個特定的根域名服務器，根域名服務器的域名變成了我們現(xiàn)在使用的http://a.root-servers.net。此時有9臺根域名服務器，用字母命名就是A到I。

/begin{array}[b] {|c|c|} /hline 原域名 & 新域名 // /hline NS.INTERNET.NET & A.ROOT-SERVERS.NET // /hline NS1.ISI.EDU & B.ROOT-SERVERS.NET // /hline C.PSI.NET & C.ROOT-SERVERS.NET // /hline TERP.UMD.EDU & D.ROOT-SERVERS.NET // /hline NS.NASA.GOV & E.ROOT-SERVERS.NET // /hline NS.ISC.ORG & F.ROOT-SERVERS.NET // /hline NS.NIC.DDN.MIL & G.ROOT-SERVERS.NET // /hline AOS.ARL.ARMY.MIL & H.ROOT-SERVERS.NET // /hline NIC.NORDU.NET & I.ROOT-SERVERS.NET // /hline /end{array}//

重命名后第一個NS記錄使用20字節(jié)的數(shù)據(jù)標簽，例如a.root-servers.net.，后續(xù)NS記錄就可以使用字母后跟壓縮標簽的形式，一共只需要4字節(jié)。例如第二個NS記錄b.root-servers.net.為0x01 0x61 0xc0 0x1e，0x01是標簽長度，0x61是’b’，0xc01e就是壓縮標簽，指針指向第一個NS記錄的root-servers.net.。0x1e十進制是30，跳過了17字節(jié)的頭部和問題區(qū)段，再跳過11字節(jié)的資源記錄頭部，再跳過2字節(jié)的0x01 0x60（‘a(chǎn)’），剛好就是root-servers.net.。

我們再計算一下DNS響應報文的大小，第一個NS記錄為11字節(jié)資源記錄頭部 + 20字節(jié)的數(shù)據(jù)標簽，其余8個NS記錄使用4字節(jié)的壓縮后的標簽。那么報文大小為12 + 5 + (11 + 20) + (11 + 4) * 8 + 16 * 9 = 312字節(jié)。剩余的空間為512 - 312 = 200字節(jié)，增加一個新的根域名服務器需要(11 + 4) + 16 = 31字節(jié)，200 / 31 ≈ 6.4，也就是說最多可以再添加6臺根域名服務器，一共9 + 6 = 15臺。

通過將域名移到http://root-servers.net域下，使用壓縮標簽，DNS響應中就留出了空間給額外的根域名服務器。在1997年IANA增加了最后4臺J、K、L、M根域名服務器，成為了13臺根域名服務器。J和K由在美國東部的NSI負責運營，L和M由在美國西部的USC ISI負責運營。

后來為了讓根域名服務器部署在更需要它的地方，K和M轉(zhuǎn)移到了因特網(wǎng)正在高速發(fā)展的歐洲和亞洲。K根域名服務器部署到了倫敦，由歐洲IP資源網(wǎng)絡協(xié)調(diào)中心（RIPE NCC）負責運營。M根域名服務器部署到了日本，由WIDE負責運營。其他兩個根域名服務器J和L本來也是打算分配給其他更有需要的地區(qū)，不過由于此項工作的負責人Jon Postel過世，一直沒有人去推動。

我們計算一下13臺根域名服務器的DNS響應報文大小，12 + 5 + (11 + 20) + (11 + 4) * 12 + 16 * 13 = 436字節(jié)，剩余空間為512 - 436 = 76字節(jié)。由于增加一個新根域名服務器只需要31字節(jié)，實際上我們還有空間可以再增加2臺根域名服務器。不過Bill Manning（ICANN）表示應該保守一些，保留一定的空間方便未來進行擴展，所以只停留在了13臺。

根域名服務器的故事到這里就結束了嗎？當然不是了，后來各個根域名服務器的運營組織很多經(jīng)歷了轉(zhuǎn)移、收購、改名，使用的IP地址也發(fā)生過改變，不過這些與“根域名服務器只有13臺”的問題已經(jīng)無關了。

任播網(wǎng)絡的出現(xiàn)

在1993年因特網(wǎng)社區(qū)提出了任播（anycast）的想法并在RFC 1546中記錄。當有多個服務器能提供同樣網(wǎng)絡服務時，對于用戶來說使用具體哪個服務器并不重要。當數(shù)據(jù)報被發(fā)送到服務器的任播地址時，網(wǎng)絡負責將其傳送到最好的（最近的）一個服務器。這樣就可以簡化用戶尋找合適服務器的過程，不再需要保存服務器列表去選擇，只需要知道服務器的任播地址。

在RFC 4786與RFC 7094中記錄了更多關于任播工作的內(nèi)容。任播在實現(xiàn)上是通過路由協(xié)議（例如BGP）在路由系統(tǒng)的不同區(qū)域?qū)ν粋€IP地址（網(wǎng)段）發(fā)出通告，產(chǎn)生多條路由路徑，每條路徑實際上對應著不同的服務器節(jié)點，達到一組服務器節(jié)點使用同一個IP地址的目的，最終根據(jù)路由算法選擇的最優(yōu)路徑通常就是最近的節(jié)點（例如根據(jù)AS_PATH屬性選擇）。當一個節(jié)點不可用時會撤銷路由信息，后續(xù)的流量將會通過其他路由路徑被路由到其他節(jié)點，用戶請求能夠繼續(xù)正常處理，提高了可靠性。

任播利用了現(xiàn)有的網(wǎng)絡基礎架構，數(shù)據(jù)包不需要作任何修改，不需要獨立的地址空間，不需要像組播一樣有單獨的路由表，不需要特殊的客戶端與服務端程序，在用戶眼中任播使用起來與單播沒有任何區(qū)別。

任播可以實現(xiàn)更好的負責均衡，避免所有流量集中在一個節(jié)點，一個區(qū)域的流量只會傳送到距離此區(qū)域最近的節(jié)點，降低了響應延遲。同時也很好的緩解了分布式拒絕服務攻擊（DDOS），使攻擊流量只會到達離攻擊源最近的節(jié)點，不會影響其他節(jié)點，也更容易定位攻擊源。

DNS與任播

DNS是任播最成功的應用，早在2002年F根域名服務器就開始實行任播，在RFC 3258中也記錄了權威名稱服務器部署在任播上的內(nèi)容，在往后的幾年里其他根域名服務器也逐漸開始使用任播，到了今天所有根域名服務器都是部署在任播上了，節(jié)點遍布全球。不僅僅是根域名服務器使用任播，頂級域名服務器，甚至公共遞歸服務器（例如1.1.1.1）都會使用任播。

例如上圖為L根域名服務器的任播節(jié)點分布，在全球有167個節(jié)點，遍布82個國家，可以在https://www.dns.icann.org/imrs/locations/查看。

DNS使用任播后DNS解析器不再需要知道DNS服務器的真正IP地址，只需要知道任播地址就可以在世界各地與當?shù)氐淖顑?yōu)節(jié)點通信了，我們現(xiàn)在所看到的根域名服務器的IP地址實際上都是任播地址。

至今（2020.2.15）在全球已經(jīng)有1089個根域名服務器節(jié)點了，當前由12個組織負責運營，我們可以在https://root-servers.org/看到部署情況。

在我國有26個根域名服務器節(jié)點，分別為：西寧市L；貴陽市K；鄭州市L；武漢市L；北京市I、L、J、K、F；上海市L；杭州市F；香港特別行政區(qū)A、I、H、F、F、E、J；澳門特別行政區(qū)E、F；臺北市I、E、F、F、K、L。

每個根服務器的運營者獨立負責管理自己的任播節(jié)點，任播節(jié)點數(shù)量沒有限制，但是各個組織有著不同的運營模式，所以不同根服務器的任播節(jié)點數(shù)量有很大差異，例如H根只有4個任播節(jié)點，E根卻有306個節(jié)點。

每個根服務器運營者通過DNS區(qū)域傳輸（RFC 5936的AXFR和RFC 1995的IXFR）從根區(qū)域維護者（IANA）獲取根區(qū)域信息，傳輸數(shù)據(jù)通過RFC 2845的TSIG保護，資源記錄現(xiàn)在還有DNSSEC的簽名，保證根區(qū)域信息正確。根服務器運營者獲取根區(qū)域信息后通過自己的內(nèi)部分發(fā)系統(tǒng)交付信息到所有任播節(jié)點。

根區(qū)域的信息完全公開，完整的根區(qū)域文件我們可以在IANA的網(wǎng)站上獲取http://www.internic.net/domain/root.zone。事實上根據(jù)RFC 7706我們甚至可以在本地建立一個自己的根域名服務器部署在回環(huán)地址，用于降低查詢延遲和避免查詢被竊聽，使用BIND或NSD作為DNS服務器程序。通過AXFR從ICANN的服務器lax.xfr.dns.icann.org或iad.xfr.dns.icann.org獲取根區(qū)域的完整信息，用DNSSEC驗證信息，根據(jù)SOA記錄中的信息定期更新。

如果你想測試一下DNS的完整區(qū)域傳輸（AXFR），可以通過以下命令

dig @lax.xfr.dns.icann.org AXFR .在返回的結果中你可以看到完整的根區(qū)域內(nèi)容，根區(qū)域所有的資源記錄，由于內(nèi)容實在太多，這里為了節(jié)省篇幅省略，可以自己做一下這個測試。

如何標識根服務器的任播節(jié)點

隨著DNS越來越多的部署在任播上，大量任播節(jié)點使用同一個任播地址，有時候很難判斷到底是哪一個節(jié)點對查詢返回響應，這會給管理者排錯帶來一些困擾，RFC 4892中記錄了這個問題，并給出了常用的解決辦法。

在BIND服務器程序中可以使用CHAOS類中的TXT類型的資源記錄存儲根域名服務器的標識，查詢名稱為“HOSTNAME.BIND.”。這種機制被其他DNS實現(xiàn)引入后去除了BIND特有的BIND.域，改為了SERVER.域，查詢名稱改為“ID.SERVER.”，我們可以通過以下dig命令測試這種標識機制：

dig @k.root-servers.net TXT CHAOS ID.SERVER;; QUESTION SECTION:;ID.SERVER. CH TXT;; ANSWER SECTION:ID.SERVER. 0 CH TXT "ns1.cn-gya.k.ripe.net"可以看到我這里的K根任播節(jié)點的標識為http://ns1.cn-gya.k.ripe.net。

以上這種方法有一點不好在于需要一個額外的DNS查詢報文去確認任播節(jié)點，但是此查詢報文和其他普通查詢報文有可能會被路由到不同的任播節(jié)點，導致獲取到錯誤標識，所以利用CHAOS類的方法沒有被標準化。

更好的方法應該是標識包含在普通查詢的響應報文內(nèi)，在RFC 5001中標準化了DNS名稱服務器標識選項（NSID），作為EDNS0偽資源記錄RDATA中的選項來存儲標識信息。DNS解析器通過在DNS查詢中包含一個空的NSID選項表示想要獲取名稱服務器標識，如果名稱服務器支持NSID則返回包含標識內(nèi)容的NSID選項的響應。NSID在權威名稱服務器和遞歸名稱服務器都可以使用，不過NSID是逐跳選項(hop-by-hop)，不會被傳遞，只作用于接收到的服務器本身。

dig @k.root-servers.net www.baidu.com +nsid;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; NSID: 6e 73 31 2e 63 6e 2d 67 79 61 2e 6b 2e 72 69 70 65 2e 6e 65 74 ("ns1.cn-gya.k.ripe.net");; QUESTION SECTION:;www.baidu.com. IN A;; AUTHORITY SECTION:com. 172800 IN NS a.gtld-servers.net....;; ADDITIONAL SECTION:a.gtld-servers.net. 172800 IN A 192.5.6.30...通過dig使用NSID機制可以看到我這里的K根任播節(jié)點的NSID中的標識為http://ns1.cn-gya.k.ripe.net，包含在查詢http://www.baidu.com的響應報文內(nèi)。

dig ns1.cn-gya.k.ripe.net A;; ANSWER SECTION:ns1.cn-gya.k.ripe.net. 86400 IN A 58.16.72.74http://ns1.cn-gya.k.ripe.net剛好是這個K根服務器的域名，我們查詢其A記錄可以看到此域名對應的IPv4地址為58.16.72.74。為了更好的讓管理員對特定節(jié)點監(jiān)控管理，通常每個任播節(jié)點除了任播地址還會有自己的單播地址。注意，不是所有根域名服務器返回的NSID內(nèi)容都是域名，NSID內(nèi)容可由管理員隨意設置。

查詢58.16.72.74的地理位置可以發(fā)現(xiàn)這是一個貴陽市的IP地址，顯然這是在貴陽市部署的K根域名服務器的任播節(jié)點。

不再有512字節(jié)限制后的DNS

到了今天網(wǎng)絡世界早已天翻地覆，絕大部分的網(wǎng)絡設備支持的IP報文最大長度不再是區(qū)區(qū)576字節(jié)，經(jīng)過統(tǒng)計表明大部分的MTU都在1340字節(jié)以上，能夠重組的IP分片數(shù)據(jù)長度就更大了，512字節(jié)的限制在ENDS0（RFC 6891）出現(xiàn)后已經(jīng)不存在了。事實上在IPv6出現(xiàn)后，增加了AAAA記錄，13臺根域名服務器構成的DNS響應報文無論如何都會超過512字節(jié)，而在DNSSEC出現(xiàn)后添加了RRSIG記錄響應報文就更大了。

那為什么現(xiàn)在沒有512字節(jié)的空間限制后不繼續(xù)增加新的根域名服務器呢？為了回答這個問題我們先來想想，增加根域名服務器的目的是為了什么？是為了減輕現(xiàn)有根域名服務器的查詢負擔，將查詢分散到更多的服務器，是為了讓根域名服務器離用戶更近，降低查詢延遲。

不斷在響應報文中增加服務器數(shù)量總會有極限的，也會讓報文越來越大增加傳輸開銷，用戶也很難知道到底哪個服務器離自己最近，也會有一定的向后兼容性問題，要是舊的解析器不支持EDNS0就只能截斷報文了。

更好的解決方法是使用任播網(wǎng)絡，任播網(wǎng)絡由路由系統(tǒng)選擇最近的服務器，不需要用戶操心，也沒有任播節(jié)點數(shù)量的限制，哪怕全球范圍內(nèi)部署上萬個任播節(jié)點也沒有任何問題。在任播網(wǎng)絡中所有節(jié)點都是平等的，沒有主次之分，技術上沒有差別，提供的內(nèi)容也完全相同。現(xiàn)在的13臺，倒不如說是13組，任播節(jié)點實際上有上千個，只有13臺根域名服務器這個概念已經(jīng)毫無意義了。

綜上所述，這是個馬車與汽車的問題，當更強大的汽車出現(xiàn)后我們就不需要繼續(xù)使用馬車作為交通工具了，當任播出現(xiàn)后我們也不需要繼續(xù)在啟動查詢的響應報文中添加更多NS記錄來增加根域名服務器了。