☰

顶级域名 (TLD) 服务器的大小？特别是 .com？

tag-icon • tag-icon domain-name-system
顶级域名 (TLD) 服务器的大小？特别是 .com？

如果这个问题很愚蠢或者我问错了地方，请见谅。但我一直在学习 DNS，顶级域名 (TLD) 服务器，尤其是 .com 服务器，有些东西让我很困扰。如果我理解正确的话，.com TLD 服务器有一条记录每一个.com 网站还存在吗？我查了 Wikipedia，上面说有大约 1.45 亿个已注册的 .com 网站。

我是否理解正确，.com TLD 服务器（实际上是一个服务器集群）绝对庞大，无法存储这么多记录？或者也许现在虽然非常大，但这真的不是不合理的？我确实想说，我理解 TLD 服务器只是指向权威名称服务器，因此它不包含每个 .com 站点的完整 DNS 记录。但我仍然很难理解这一点。我知道我可能错了，但在一个地方存储这么多记录似乎不对，所以我想问问我是否理解正确。谢谢！

答案1

您的理解是正确的。

.COM 区域文件确实很大……但你甚至可以获取它，它是公开可用的，就像任何 gTLD 一样，通过 ICANN 集中区域数据访问服务，你可以在https://czds.icann.org/home

它当然会长达数 GB，因为它包含字符串，其中包含（几乎）所有 .COM 下的域名及其权威名称服务器以及一些相关的其他记录（胶水、DNSSEC 签名、DS 记录等）。

这个文件很大，但在“大数据”世界中仍然很小。

但您还必须了解，这只是一种导出格式。服务器本身可能无法那样处理这些数据。数据可以存储在数据库中（如今，拥有数十亿条记录的数据库并不算真正“大”），也可以通过适当的结构（例如二叉树、字典树或 DAFSA 结构等）加载到内存中。

或者说，虽然现在规模很大，但这确实也不算不合理？

大型权威 DNS 运营商还有其他问题要困扰他们，这些问题比区域容量复杂得多：查询率和响应所有人的能力（因为 DNS 作为一项服务，应该有 100% 的正常运行时间）。这意味着在所有阶段都需要充足的超额配置。

但把这么多的记录存储在一个地方似乎不太合适

对，从什么意义上说是对的？这就是 DNS 的工作方式，每个节点都需要有一个其下方所有委托节点的列表。从.com历史上看是一个大区域，但没有什么特别之处，我的意思是对于计算机来说，这个标签就像其他标签一样。

答案2

我是否理解正确，.com TLD 服务器（实际上是一个服务器集群）非常庞大，能够存储这么多的记录？

不。你确实对如今即使是低端服务器的危害存在严重的误解 - 对于你的手机来说，这已经是很大的数目，对于笔记本电脑来说甚至不算什么。DNS 记录非常小。

或者说，虽然现在规模很大，但这确实也不算不合理？

它甚至不是很大。几百兆字节并不算大。20 年前它们就不算大。

您的计算严重错误 - 现代中端服务器将拥有 32 到 64 个核心，如果需要的话，可以轻松拥有几百 GB 的数据。而且这些是成本优化的服务器，并不接近高端服务器。对于托管一小部分 GB 文件的服务器来说，这已经是很大的空间了。足以真正优化使用内存索引等的访问。

答案3

我com.zone从 ICANN 的集中区域数据服务下载到我的桌​​面。截至 2021 年 4 月，未压缩的文本文件长 3.82 亿行，大小为 22 GB。对于每个拥有多条记录的约 1.5 亿个域名来说，这是合理的。

当然，对于 DNS 区域来说很大，但对于数据库来说却很小。

请记住，DNS 是一种简单的协议，缓存量很大。无论是在更大的 DNS 服务器上还是在更多的 DNS 服务器上，都易于扩展。并且com.只需处理缓存未命中，一旦其他解析器知道谁拥有域名，他们暂时不会再次询问。

有趣的是，这是 Server Fault。在 Stack Overflow 基础设施博客上，我们的系统管理员承认不信任某个组织提供的 DNS，这是事实。

ns1.serverfault.com.    172800  in      a       198.252.206.80
ns3.serverfault.com.    172800  in      a       69.59.197.60
serverfault.com.        172800  in      ns      ns-1135.awsdns-13.org.
serverfault.com.        172800  in      ns      ns-860.awsdns-43.net.
serverfault.com.        172800  in      ns      ns-cloud-c1.googledomains.com.
serverfault.com.        172800  in      ns      ns-cloud-c2.googledomains.com.

答案4

由于我没有com现成的区域数据（理论上可以通过以下方式请求访问捷克共和国，但我不会com特别关注该区域。

我快速浏览了一下面积适中的se区域（随时可用从 IIS）。它有大约 1.5M 个委托区域，而 则有大约 150M 个com。

作为由 生成的格式的主区域文件dig，该se区域为 1.3 GB。也就是说，在存储方面确实无需担心。

将nsd同一个文件加载为区域后，它将使用大约 1.8 GB 的内存。
您使用的名称服务器软件显然会影响这个数字，但任何将区域数据预加载到内存中的软件最终都可能达到这种使用量，具体使用量取决于用于表示记录的确切数据结构。

在同样的设置下，区域会使用多少内存com？我不太确定，一方面，数据可能存在一些差异；将其视为com“大得多se”可能不是一个完美的比较。但从上面的粗略想法来看，几百 GB 至少可能是规模的正确想法。

那么，如今几百 GB 的容量还算多吗？对于典型的现代服务器硬件而言，这完全在您可以设定的范围内，无需进行任何特别的操作。

您是否一定要将整个内容加载到内存中？不一定，因为有很多很少使用的数据。但是，这无疑是一种确保快速访问的明显方法，并且对于上面指出的大小，它实际上不应该太大。

相关内容