a.gtld-servers.net 是否有所有 .com 域的列表？

Question

当我这样做时dig @a.gtld-servers.net example.com，它会快速返回这些名称服务器的名称服务器example.com和 IP 地址（胶水记录）。

这是否意味着a.gtld-servers.net（和*.gtld-servers.net）在.com本地拥有所有域的记录？他们的反应非常快，所以我认为他们不会自己进一步询问。同样，对example.com's nameservers的请求不会将我重定向到 domains.starting.with.e.gtld-servers.net或任何东西。

我确实意识到a.gtld-servers.net可能有几台机器，并且我被路由到离我最近的一台（通过新的单 IP 多机技术），但这仅意味着其他几台机器拥有所有.com域。

编辑：感谢所有回答的人！后续问题：如果有人“侵入”其中一台机器，他们是否无法获得所有.com域的列表？这似乎是有用的信息，除非它已经在某处免费提供？我意识到域信息是公开的，但仍然很难批量获取。我猜*.gtld-servers.net不支持区域传输（尽管.edu的名称服务器支持，至少在几年前）。

注意：我意识到 example.com 不是一个真正的域——只需用上面的任何其他 .com 域替换它（我最初有 xyz.com，但有人正确编辑了它以避免使用真实的域名）。

Answer 1

是的，“x.gtld-servers.net”是“com”顶级域的权威服务器，因此它们拥有 .com 域的所有“指针”。您可以通过运行来查看 TLD 的名称服务器

dig -t ns com
dig -t ns us
dig -t ns dk
dig -t ns aero

Answer 2

你很久以前就已经得到了回复，但我觉得我们可以更准确，你还有一个后续问题，实际上应该是另一个问题。

那么让我们从头开始吧。

如果您查询根服务器以了解.COM委托（请注意，以下所有内容均以相同的方式适用，因为.NET两者均由同一注册表处理），您会收到以下答复：

$ dig @a.root-servers.net com. NS +noall +auth

; <<>> DiG 9.12.0 <<>> @a.root-servers.net com. NS +noall +auth
; (1 server found)
;; global options: +cmd
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.

因此，总而言之，这些名称服务器中的任何一个都是权威的，.COM并且它们都具有相同的数据（因此您可以扩大您的问题，a.gtld-servers.net这绝不是特别的，下面的所有内容都将适用于这些名称服务器中的任何一个）。

当您向这些域名服务器查询任何.COM/.NET域名时，他们需要使用您所请求域名的权威域名服务器进行权威回复。

因此，根据定义，“这是否意味着 a.gtld-servers.net（和 *.gtld-servers.net）在本地拥有所有 .com 域的记录？”，但它的意思正是如此！关于“全部”的一些警告将在下面进一步讨论。

请注意，您谈论的是粘合记录，这是一种特定情况，而不是最常见的情况。通常，在上述任何名称服务器上对域的请求只会返回一个或多个 NS 记录。

让我们花点时间来解决您文本中的其他小问题：

他们回复得很快，所以我认为他们自己并没有进一步询问。

根据定义，权威名称服务器拥有回复查询所需的数据，而无需依赖任何外部资源，否则它并不是真正的权威。

至于速度，这在一定程度上是主观的，很大程度上取决于您测试的内容和方式，但有几个因素：默认情况下，DNS 使用比 TCP 更轻的 UDP，因此速度更快，并且此类名称服务器是任播的，这意味着如果运气好的话，您总是可以有一个“靠近”你。

我确实意识到 a.gtld-servers.net 可能是几台机器

您可以删除“可能”:-) 这些名称服务器收到如此多的查询，任何单个盒子都无法承受。

如果您访问https://stat.ripe.net/192.5.6.30#tabId=routing您会看到很多可能难以消化的信息，但基本上，看到这个单个 IP a.gtld-servers.net（实际上是其中的块）它是）是由一家公司控制的多个 AS 宣布的，这是任播的一个强有力的指标，它对于大多数 DNS 来说工作得很好。

如果您访问http://www.root-servers.org/您可以了解更多信息。这与根域名服务器有关，不再是那些根域名服务器.COM，但从技术上讲，这是完全相同的事情。例如，您可能会发现，13 个根服务器由 12 个不同的组织跨 930 个实例进行管理（一个实例不仅仅是一台服务器，它是一个位置，一个“存在点”，操作员在其中拥有一个“节点”，通常是路由设备、负载平衡/故障转移设置中的多个服务器、一些监控/远程操作功能等）。F例如在 222 个地方。

我被路由到离我最近的一台（通过新的单 IP 多机技术），但这仅意味着其他几台机器都拥有 .com 域。

.COM是的，许多机器都有所有域名的列表。但首先要注意的是：在这些域名服务器上，您将获得所有 .COM 域名的所有域名服务器的列表...这意味着对于未委托的域名，您将无法在这里找到它们。这可能在多种情况下发生：

1. 当您注册域名时，您可以选择不设置名称服务器，或者稍后将其删除。
2. 例如，由于付款纠纷，您的注册商可能会clientHold在您的域名上添加状态，从而使其从 DNS 中消失
3. 注册机构可以出于任何原因放置域名serverHold。

（如果您想了解有关这些状态和其他状态的更多信息，请参阅https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en ）。

根据您如何定义“全部”以及您将如何处理这些数据，您可能无法真正获得所有这些数据。

在上述所有情况下，域名不会出现在注册表 DNS 服务器上，但会在您执行 whois 查询时出现。因此，whois 服务器（同样，不是一个盒子）也将拥有...所有 .COM 域名的列表，甚至比名称服务器上的数据更多，因为：

1. 您实际上拥有所有域名，包括那些未解析的域名，因此不在注册名称服务器上
2. whois 提供更多信息，例如联系数据

这些仍然只是面向公众的注册服务，以某种方式或部分拥有域名列表（或其一部分）。

至于你的后续行动：

后续问题：如果有人“侵入”其中一台机器，他们难道无法获得所有 .com 域的列表吗？

从技术上来说，是的。但：

1. 这当然不是您在网上找到的最简单的目标
2. 在这种特定情况下，数据已经可以免费使用。

.COM是 gTLD，因此与 ICANN 签订了合同。ICANN 要求所有 gTLD 注册机构每天至少发布一次其区域文件（这基本上是域名服务器自己使用的文件，因此 NS 记录加上 A/AAAA 粘合剂），只要签署协议，任何人都可以免费访问以确保您不会将这些数据用于“不良”目的（例如自己重新发布）。

有关详细信息，请参阅https://czds.icann.org/en 。这可以让您访问数百个 gTLD 区域文件。

请注意，如果您的问题扩展到“如果有人侵入其中一台机器并更改添加或删除 .COM 域名的内容......”，那么我们可以快速回答：

1. 这些更改不会在全世界范围内看到，因为您只破解了一个盒子，并且有许多名称服务器，首先是名称，然后是任播
2. DNSSEC 可能会使您的更改显示为错误，因此会很快被发现（当然，除了运营商本身采取的任何本地对策之外）。

简而言之，为了搞乱域名而这样做并不是最好的主意.COM，还有其他方法。

我意识到域名信息是公开的，但仍然很难批量获取。

有关 ICANN 计划，请参阅上文。至于 ccTLD，情况各不相同，但更常见的是，他们不授予对其区域文件的访问权限，而且不是实时的。

有时，您可以在一段时间后访问它，例如通过“开放数据”运动。一个示例： https: //opendata.afnic.fr/en/products-and-services/services/opendata-en.html域名.FR。

我猜 *.gtld-servers.net 不支持区域传输（尽管 .edu 的名称服务器至少在几年前支持）。

易于测试：

$ for ns in $(dig NS . +noall +ans | grep 'IN NS' | awk '{print $5}') ; do echo $ns ; dig @$ns com. AXFR; done
c.root-servers.net.

; <<>> DiG 9.12.0 <<>> @c.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
m.root-servers.net.

; <<>> DiG 9.12.0 <<>> @m.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
i.root-servers.net.

; <<>> DiG 9.12.0 <<>> @i.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
e.root-servers.net.

; <<>> DiG 9.12.0 <<>> @e.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
j.root-servers.net.

; <<>> DiG 9.12.0 <<>> @j.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
l.root-servers.net.

; <<>> DiG 9.12.0 <<>> @l.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
g.root-servers.net.

; <<>> DiG 9.12.0 <<>> @g.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
k.root-servers.net.

; <<>> DiG 9.12.0 <<>> @k.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
b.root-servers.net.

; <<>> DiG 9.12.0 <<>> @b.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
h.root-servers.net.

; <<>> DiG 9.12.0 <<>> @h.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
d.root-servers.net.

; <<>> DiG 9.12.0 <<>> @d.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; connection timed out; no servers could be reached
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
a.root-servers.net.

; <<>> DiG 9.12.0 <<>> @a.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
f.root-servers.net.

; <<>> DiG 9.12.0 <<>> @f.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.

不，目前没有.COM权威名称服务器接受 AXFR 查询。但这并不一定在所有地方都一样。如果您查询f.root-servers.net域名服务器，您可以执行 AXFR 查询来获取所有已发布的 TLD。一些其他 TLD 也可能允许这样做。

请注意，有“很多”建议反对允许公共 AXFR 查询。事实是，根据定义，它们是巨大的答案，如果重复，可能会给服务器带来压力，这是事实。On 可以无休止地争论公众为什么/是否需要这些信息。它在 DNS 诞生之初更多地用于在名称服务器之间复制区域（现在有更好的替代方案）。因此 AXFR 经常被禁用...除了如果您同时以某种特定方式（即 NSEC 而不是 NSEC3 变体）执行 DNSSEC，则很容易通过标准 DNS 查询而无需 AXFR，您的所有区域并重建区域文件。存在可以做到这一点的工具。

另请注意，各种在线提供商会向您出售许多 TLD 的区域文件和/或所有域名的列表，他们通过各种方式获取这些域名（其中一个想法是：您获取开放的区域文件，例如 ，对于.COMTLD，.example您一一查询您在 中找到的所有名称.COM，这可以给您一些想法，当然，除了基于 TLD 搜索中最常用的语言的字典查找之外）。