剛好有人發出知乎 https://www.zhihu.com/question/22587247 的這個鏈接，問哪個答案才是對的，我看了一下里面的答案，魚龍混雜，我試著回答一下。

其實對于一個小白，這個問題核心并不是13臺，而是，域名根服務器什么，查詢的過程是怎么樣呢?

不算太久以前的基礎知識

DNS 是一種分層結構，在整個互聯網中組成一個樹狀系統，頂層是系統的根域名，下層為 TLD 以及二級域名，葉子就構成了所謂的 FQDN(Fully Qualified Domain Names)，根域名通常使用 "." 來表示，其實際上也是由域名組成，全世界目前有 13 組域名根節點，由少數幾個國家進行管理，而國內僅有幾臺根節點鏡像。

如查詢 www.im.qq.com，簡略描述 DNS 的過程就是，先查詢 com 這個域名的 name server 有哪些，然后選一個繼續查詢 qq 這個子域名的 name servers 有哪些，再選一個繼續查詢 im 這個子域名的 name servers 有哪些，www 不是域名，查詢結束。這個查詢出來的結果就是 google.com 域名。所謂的 name server，其實就是dns服務器啦，用來解析域名的。

萬物起始之風——Root Servers

而上面的查詢過程有一個問題就是，程序該去哪里查詢 com，gov 這些頂級域名的服務器呢?

這個就是 Root servers(根服務器) 的作用，用來查詢以上的頂級域名的 name server。

思考

而怎么樣獲取 Root servers 的地址呢，注意這里沒有動態域名(DNS)可用，獲取的地址其實就是要獲取 IP，假如我們來實現 DNS 服務器，這一步你會怎么做呢?

其實這種做法很顯然易見，寫程序直覺就是如此：

• 寫一份配置文件放程序里，記錄了全部 Root servers 的 IP 地址列表，定時從網上(這個就可以用域名了)更新這份配置文件;
• 又或者程序啟動的時候，直接從網上獲取這些信息，存下來，也是定時更新;

DNS 的做法也不外乎如是，而上面說到的這份"配置文件"，就在 https://www.internic.net/domain/named.root，里面就是所有`Root Servers`的 信息：

1. ;       This file holds the information on root name servers needed to  
2. ;       initialize cache of Internet domain name servers 
3. ;       (e.g. reference this file in the "cache  .  <file>" 
4. ;       configuration file of BIND domain name servers).  
5. ;  
6. ;       This file is made available by InterNIC  
7. ;       under anonymous FTP as 
8. ;           file                /domain/named.cache  
9. ;           on server           FTP.INTERNIC.NET 
10. ;       -OR-                    RS.INTERNIC.NET 
11. ;  
12. ;       last update:     July 30, 2019  
13. ;       related version of root zone:     2019073000 
14. ;  
15. ; FORMERLY NS.INTERNIC.NET  
16. ; 
17. .                        3600000      NS    A.ROOT-SERVERS.NET. 
18. A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4 
19. A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30 
20. ;  
21. ; FORMERLY NS1.ISI.EDU  
22. ; 
23. .                        3600000      NS    B.ROOT-SERVERS.NET. 
24. B.ROOT-SERVERS.NET.      3600000      A     199.9.14.201 
25. B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b 
26. ;  
27. ; FORMERLY C.PSI.NET  
28. ; 
29. .                        3600000      NS    C.ROOT-SERVERS.NET. 
30. C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12 
31. C.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2::c 
32. ;  
33. ; FORMERLY TERP.UMD.EDU  
34. ; 
35. .                        3600000      NS    D.ROOT-SERVERS.NET. 
36. D.ROOT-SERVERS.NET.      3600000      A     199.7.91.13 
37. D.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2d::d 
38. ;  
39. .                        3600000      NS    M.ROOT-SERVERS.NET. 
40. M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33 
41. M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35 
42. ; End of file 

中間的服務器太多，我就刪掉一部分了。

Priming Query!

按照我的風格，寫這樣一篇文章時，怎么能不帶權威的信息呢。

Initializing a DNS Resolver with Priming Queries[1] 就是 Internet Engineering Task Force (IETF) 寫的一份關于 priming query[2]的BCP(Best Current Practice )文檔。

This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS RRSet for the root zone and the necessary address information for reaching the root servers.

上面提到的列表信息，可能并不是最新的，所以 DNS解析器首次啟動時，并不去讀這份文件，而是直接去查詢有哪些服務器(來自下文提及的文章，我對這個說法存疑，因為文件的大小跟查詢到的東西差別應該不大，有待驗證)。

關于Priming Query的額外知識請看下面補充。

A priming query is a normal DNS query. Thus, a root name server cannot distinguish a priming query from any other query for the root NS RRset. Thus, the root server's response will also be a normal DNS response.

Resolver software SHOULD treat the response to the priming query as a normal DNS response, just as it would use any other data fed to its cache. Resolver software SHOULD NOT expect exactly 13 NS RRs because historically some root servers have returned fewer.

為什么是13，還重要嗎?

是不是感覺沒那么重要了呢。

是這樣的，在DNS設計之初，在龜速的網絡下，當然是希望做 Prime Query 查 Root Servers 性價比達到最高啦。

DNS 是用 UDP 傳數據的，而設計的時候規定DNS查詢時，一個包的能放的數據最多是 512 Bytes，為什么是 512 Bytes，為什么域名根服務器只能有13臺呢?- 車小胖的回答 - 知乎[3] 做了完整的回答，摘錄一點如下：

Internet 大多數網絡接口 MTU>512，即使 DNS 報文 + UDP+ IP= 512+8+20=540，這個大小幾乎可以在 Internet 上暢通無阻，而無需 IP 分片。

為何 IP 分片不好? 一個 UDP 報文如果因為 size > MTU，則會被 IP 層分成兩片多片，但是只有一片有端口號，由于其它分片沒有端口號，能否通過防火墻則完全看防火墻的臉色，所以對于能否通信成功是一個未知數。

如果防火墻網開一面，不檢查端口號，分片可以全部通行，到目的地再組裝到一起，IP 層提交給 UDP/DNS，一點問題沒有。但是防火墻的安全功能大打折扣，如何阻止非法的外來攻擊包?

如果防火墻嚴格檢查端口號，則沒有端口號的分片則統統丟棄，造成通信障礙。

所以選擇一個合適的 UDP size 至關重要，避免分片。

有同學說，對于 MTU <512 物理接口的 DNS 如何處理?這個其實好辦，這些只是接入層接口，用于接入終端用戶，用戶的 DNS 請求是請求其上一級 DNS 服務器做遞歸查詢(告訴我最終查詢結果)

接著就是 13 這個數字的果了。

為了做 Prime Query 查 Root Servers 性價比達到最高，肯定是一個包能放多少東西就塞多少東西，所以把所有 Root Servers 的結果都塞進去，剛好能塞14個，不全用就塞13個吧，留下一點東西以備后患，留待擴展。

塞的細節嘛，https://miek.nl/2013/november/10/why-13-dns-root-servers/ 這篇文章有詳細的介紹，但是我對此不大感興趣了~

原文鏈接：https://mp.weixin.qq.com/s/MKd7Bpkk-WCEpN4sXBC9MQ