[[422359]]粤友钱
刚好有人发出知乎 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`的 信息：
; 粤友钱 This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.cache ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET ; ; last update: July 30, 2019 ; related version of root zone: 2019073000 ; ; FORMERLY NS.INTERNIC.NET ; . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30 ; ; FORMERLY NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201 B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b ; ; FORMERLY C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c ; ; FORMERLY TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13 D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35 ; 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/ 这篇文章有详细的介绍，但是我对此不大感兴趣了~
本文转载自微信公众号「山尽写东西的cache」，可以通过以下二维码关注。转载本文请联系山尽写东西的cache公众号。
本信选配提示：文章来自网络，不代表本站观点。
