注:本内容的英文原始版本源自

icann.
org,现已被翻译成中文.
刊登在icann.
org上的英文版应被视为权威版本.
RSSAC常见问题解答本文包含关于根服务器系统咨询委员会(RSSAC)的许多最常见问题和解答.
本文内容将随着答案的变化或新问题的频繁出现而更新.
如果您的问题下面没有列出,或者需要进一步的信息或澄清,可以直接发送邮件至ask-rssac@icann.
org.
如果您希望引用此常见问题解答中的某个问题,请在电子邮件中注明问题的编号和主题.
主题列表1.
运营商数量2.
任播3.
DNS与网络4.
DNSSEC5.
RSSAC6.
RSSAC决策委员会7.
常见误解1.
运营商数量1.
1为什么有13个根服务器标识符1985年,有四个根服务器.
从1987年到1991年,有七个根服务器,全部位于美国.
到1993年,有八个根服务器.
此时,遇到了一个问题.
RFC1035规定"通过用户数据包协议(UDP)传输的[DNS]消息不得超过512字节.
"添加更多的根名称服务器将导致启动响应超过512字节.
RFC1035没有提供512字节限制的理由,但同样值得注意的是,当时有一个通用的要求,即,通过互联网传输的IP数据包不得超过576字节.
根服务器运营商意识到,如果他们能够利用域名系统(DNS)名称压缩,则可以添加更多的域名服务器.
因此,提出了在root-servers.
net区域中提供根服务器名称的建议.
到1995年,现有的九个根服务器已重命名为"a.
root-servers.
net"、"b.
root-servers.
net"等.
1997年,又增加了4个根服务器,使根服务器标识符(RSI)总数达到13个.
直到1998年,当时的互联网号码分配机构(IANA)主管强·珀斯特尔(JonPostel)博士一直负责指定根服务器运营商.
在他于1998年去世后,尽管多年来有一小部分运营商已经易手,但是运营商的数量并没有变化.
自1998年以来,根服务器领域在多个方面发生了变化.
每个根服务器都添加了自己的IPv6地址,并且ICANN使用域名系统安全扩展(DNSSEC)对该区域进行了签名.
此外,通过UDP传输的消息大小,已经使用域名系统扩展机制(EDNS)协议扩展进行了扩展.
所有这些变化使得512字节的UDP限制和13个RSI限制变得不那么重要了.
2002年,互联网软件联盟(ISC,现在的"互联网系统联盟")成为第一个部署IP任播的根服务器运营商,尽管WIDE项目早些时候已经对这项技术进行了试验.
多年来,其他根服务器运营商也紧随其后部署了IP任播.
任播允许每个运营商从多个不同的节点提供服务.
虽然当今RSI数量仍然是13个,但事实上,全世界范围内运营超过1000个任播节点.
要更好地了解根服务器系统(RSS)的发展历史,请参阅RSSAC023:根服务器系统发展史.
如果您对RSS的持续发展感兴趣,请阅读RSSAC037:DNS根服务器系统治理模型提案.
1.
213个根服务器标识符限制背后的数学原理是什么1997年,当时的根服务器还充当.
COM、.
NET和.
ORG区域的权威服务器,并且增加的这项功能对可以存在的RSI数量设置了重要限制.
与根区的启动查询一样,对.
COM、.
NET和.
ORG区域的NSRRSET查询也不能超过512字节,并且由于相同的服务器为这些区域提供服务,因此所有这些区域也都具有相同的限制.
DNS响应数据包中还包含"问题"部分中提出的完整问题.
对根启动查询的响应,"问题"部分将始终使用5字节.
限定名称占用1字节,限定类型和限定分类各占用2字节,总共5字节.
然而,对于一个.
COM启动查询,"问题"部分可能会大得多.
用途字节数DNS抬头12首个NS记录3112个压缩的NS记录(12*15)18013个A记录(13*16)208"问题"部分的限定类型和限定分类4"问题"部分的限定名称=435表1:根启动响应中使用的字节数说明由于已使用435字节,因此,"问题"部分的限定名称还剩77字节可用.
当时认为64字节足以处理针对.
COM、.
NET和.
ORG的大部分查询.
添加另一台服务器将需要25字节,由于435+64+25>512,因此当时决定不另外添加服务器.
2.
任播2.
1为什么有些运营商有许多任播节点,而其他运营商却只有几个根服务器运营商(RSO)是拥有不同使命、不同运营模型和不同资金来源的独立组织.
这些差异可能会影响任播节点的数量,以及其他运营选择.
根服务器运营商在如何部署网络方面拥有高度的独立性,请参阅RSSAC042:RSSAC针对根服务器运营商独立性的声明.
所有RSO都致力于提供高质量的根DNS服务.
2.
2如何确保正确复制根区根区文件是否可能会被任何攻击或恶意软件破坏根区文件通过DNS区域传输协议(RFC5936中的AXFR和RFC1995中的IXFR)从根区维护人(RZM)传输到单个RSO.
如RFC2845中所述,使用交易签名(TSIG)资源记录对这些区域传输消息进行安全保护.
这是一个可靠的协议,没有发生过已知的数据损坏事件.
而且,由于会对根区进行签名,因此,DNSSEC验证器可以检测到不正确或伪造的答案.
RSSAC鼓励在可能的情况下使用DNSSEC验证.
2.
3任播节点的数量是不受限制,还是具有一定的数量限制RFC4786"任播服务运营"和RFC7094"IP任播架构考量因素"中对任播运营进行了定义和描述.
任播服务中的节点数量没有任何固有的限制.
2.
4根服务器会复制权威根区并重新发布,然后任播节点会重新发布源自这些根区的数据.
这两种类型的重新发布有什么区别RSO从根区维护人(RZM)接收权威根区数据.
然后,每个RSO使用其自己的内部分发系统将根区数据传送到其所有站点和任播节点.
2.
5我们在地方城市托管了一个根服务器任播节点.
我们看到该任播节点在答复来自全球各地的查询.
我如何将其设置为仅答复来自本地的查询这实际上是一个关于IP路由和RSO如何运营其任播服务的问题.
一些RSO会对其路由器和对等会话进行配置,使任播节点只接收本地流量.
其他RSO则会将其路由器和对等会话配置为接收全球流量,依靠路由系统选择网络中的最佳传输路径.
如果您发现托管服务器有不正常行为,应与提供此服务的RSO进行讨论.
2.
62016年,Dyn曾遭到大规模攻击.
同样的事件是否会发生在所有根服务器任播节点上会,至少理论上是这样.
这是RSS拥有许多运营商和许多根服务器节点的原因之一.
大量的任播节点增加了RSS的容量,在遭受攻击的情况下肯定会有所帮助.
2.
7如何为我的组织请求根服务器任播节点请使用以下联系信息直接联系根服务器运营商.
与问题3.
4相似,您还可以考虑运行根区的本地副本(如RFC7706中所述),而不是在形式上作为根服务器任播系统的一部分.
Cogent通信公司(CogentCommunications)美国国防部(NIC)ICANNhttps://www.
dns.
icann.
org/imrs/host/InternetSystemsConsortium,Inc.
https://www.
isc.
org/f-root/hosting-an-f-root-node/美国国家航空航天局(艾姆斯研究中心)Netnodhttps://www.
netnod.
se/i-root/i.
root-servers.
net欧洲网络协调中心(RIPENCC)https://www.
ripe.
net/analyse/dns/k-root/hosting-a-k-root-node马里兰大学南加利福尼亚大学,信息科学研究所https://b.
root-servers.
org/美国陆军(研究实验室)Verisign,Inc.
https://www.
verisign.
com/rirsWIDE项目3.
DNS与网络3.
1递归服务器如何选择查询哪个根服务器我的递归服务器应优先选择哪个根服务器标识符这称为"服务器选择算法".
DNS协议没有指定递归名称服务器应该如何从一组特定查询中进行选择.
因此,每个递归软件供应商都可以确定他们自己的服务器选择算法.
某些解析器实施会"锁定"到延迟最短的服务器,或具有与最快速服务器相似延迟的某个服务器.
有些解析器实施每次会随机选择服务器,有些则会根据复杂的公式来分发查询.
一篇2012年的文章介绍了当时流行的实施算法.
让您的递归软件执行其本职功能可能是更可靠的做法,而不要试图影响它如何优先选择或避免选择特定的服务器.
3.
2我们知道DNS使用UDP端口53,能否说明一下什么情况下DNS使用TCP端口53默认情况下,几乎所有的DNS客户端都使用UDP传输进行查询.
但是,在某些情况下,需要改用TCP.
当UDP响应被截断时,通常会使用TCP.
当服务器的响应太大而无法包含在单个UDP消息中时,就会发生这种截断.
这取决于客户端发布的UDP缓冲区大小,以及服务器可能对自身设置的响应大小限制.
当客户端接收到设置了截断位的响应时,DNS协议会指示必须通过TCP重试查询才能获取完整响应.
另一个对DNS使用TCP的情况是区域传输.
由于整个区域通常比单个UDP消息大得多,无法包含在单个消息中,因此,通过TCP执行这些传输是合情合理的.
当服务器发现自己遭受攻击时,TCP也会发挥作用.
服务器可能会向客户端发送截断响应,以此来确定消息源是否可靠.
可以将建立TCP连接的客户端列入白名单,作为可靠信息源.
此外,一种名为响应速率限制(RRL)的技术偶尔也会发送截断的响应,以便合法的客户端有机会通过TCP接收响应,而攻击流量将无法重试发起攻击.
必须通过TCP使用DNS才能在DNS软件中实施.
有关更多信息,请参阅RFC7766.
3.
3如何减少我运行的递归服务器与根服务器之间的延迟首先,您应该仔细考虑靠近(更多)根服务器是否有任何实质性的优势.
对离开您的递归名称服务器,以处理发送到根名称服务器的查询流量进行分析.
如果您看到的流量超出预期,也许可以修复您的应用程序或网络配置,以便这些流量无需经常查询根服务器.
使用类似"dig"实用工具的程序来测量实际延迟.
如果至少两个根服务器的延迟在100毫秒以内,这通常就足够了.
使用"traceroute"等工具探索递归服务器与递归名称服务器使用的根服务器之间的网络路径.
如果您发现一些没有意义的路径(例如,通过较远位置的路由),可以询问您的ISP是否可以调整路由.
为获取有关DNS服务质量度量的更多信息,欧洲网协(RIPE)Atlas项目组通过其DNSMON项目对根服务的服务质量进行了监控.
数百个RIPEAtlas锚点的测量结果显示,大多数服务器的延迟低于60毫秒.
如果附近没有合适的根服务器,那么您可以尝试确定根服务器所在位置附近的一个交换点或数据中心.
询问一个或多个根服务器运营商是否可以在那个位置放置服务器.
但是,请注意,如果某个位置已有一个根服务器,那么运营商通常不希望在该处放置另一个服务器.
通过访问http://www.
root-servers.
org,并在页面底部的"根服务器"部分中找到"ContactEmail"(联系电子邮件)按钮,您可以找到运营商联系信息.
3.
4您可以通过下载根区文件并自行验证签名来设置根服务器吗RFC7706介绍了如何通过此方法设置根服务器,并列出了关于这样做可能带来的负面影响的多项警告意见.
请注意,这需要进行DNSSEC验证.
另请参阅LocalRoot项目.
3.
5递归服务器会将信息缓存多长时间每个DNS记录都有一个由区域运营商指定的存活时间(TTL)值.
此值决定递归名称服务器或其他客户端应将数据缓存以供重复使用的时间长度.
超过此时间之后,递归名称服务器需要再次联系权威服务器以获取新数据.
对于根区,某些记录的TTL为24小时,其他记录的TTL为48小时.
有些解析器的最长缓存生存期通常为24小时.
3.
6由于过期后的缓存会提供错误信息,如何更新解析器,使其提供正确的DNS信息如果您怀疑递归名称服务器缓存中的数据已过时,可以刷新缓存或重新启动服务器进程.

3.
7什么是DNS启动查询和响应在开始答复常规查询之前,DNS递归解析器需要使用源自根区的特定数据来启动缓存.
RFC8109介绍了递归解析器会发送哪些查询,以及它们期望从根服务器得到怎样的响应.