TLD 域名服务器在实际中如何运作?

TLD 域名服务器在实际中如何运作?

TLD 名称服务器究竟如何解析查询并根据所需信息识别权威名称服务器?“.com”的 TLD 名称服务器是否存储了每个带有“.com”TLD 的网站的相应名称服务器?这难道不是一个庞大的数据库吗?或者是否存在某种算法来决定将哪些域名分配给哪些权威名称服务器,因此通过该算法运行域名,您可以识别正确的权威名称服务器?

抱歉,这似乎是一个非常简单的问题,但我在网上找不到任何东西,我只能找到 DNS 的表面解释,例如这个由 CloudFlare 提供,但没有涉及具体细节。

答案1

TLD 名称服务器究竟如何解析查询并使用所需信息来识别权威名称服务器?

TLD 名称服务器与 DNS 树中任何其他节点上的任何其他权威名称服务器没有任何区别,这是根据 DNS 协议作为分散式数据库的设计和属性。

您可能忘记了“注册平面”。DNS 处理解析,也称为“解析平面”。它解释了如何获取数据,而不是数据最初是如何存储的(DNS 更新除外,但这是用于本地用途而不是全局用途)。

注册层面通常包括注册中心和注册商。注册中心管理 TLD。它确保名称服务器正常运行,并从注册商处获得订单。注册商有选择域名并注册的最终客户。注册商通常使用称为 EPP 的协议向注册中心发送命令。

因此,总而言之,注册中心维护一个包含所有数据的数据库(通常是关系型数据库),包括未在 DNS 中发布但可通过 whois 或 RDAP 等其他协议获取的数据(例如联系人)。此数据库用于配置包含所有授权(即记录)的 TLD 权威名称服务器NS

“.com” 的 TLD 名称服务器是否存储了每个具有“.com” TLD 的网站的相应名称服务器?

是的,根据以上讨论。

这不是一个庞大的数据库吗?

对于某些 TLD 来说,答案是.com肯定的,但是:

  • 只有几亿条记录,这是数据库完全可以处理的,其他情况下的数据要多得多
  • 这样的 TLD 是个例外,大多数 TLD 都小得多;例如,典型的 ccTLD 有几百万个域名

或者是否存在某种算法来决定将哪些域名分配给哪些权威名称服务器,从而通过算法运行域名就可以识别正确的权威名称服务器?

没有。当您注册域名时(实际上在 DNS 树的任何级别),您可以自由选择要处理该域名的任何名称服务器(除了一些非常特殊的边缘情况,例如.tel过去注册中心强制使用特定名称服务器的情况)。

抱歉,这似乎是一个非常简单的问题,但我在网上找不到任何信息,

https://en.wikipedia.org/wiki/Domain_name_registry虽然很短,但可以作为一个很好的介绍。只要您了解了一边是解析(DNS),另一边是注册(整个注册中心/注册商),它应该可以帮助您更好地理解事情。

答案2

好吧,他们必须拥有他们区域的所有委托(NS)和粘合(A / AAAA)记录。dig com NS显示名称服务器的数量与根服务器的数量一样多:

;; ANSWER SECTION:
com.                    63343   IN      NS      i.gtld-servers.net.
com.                    63343   IN      NS      l.gtld-servers.net.
com.                    63343   IN      NS      f.gtld-servers.net.
com.                    63343   IN      NS      b.gtld-servers.net.
com.                    63343   IN      NS      k.gtld-servers.net.
com.                    63343   IN      NS      h.gtld-servers.net.
com.                    63343   IN      NS      j.gtld-servers.net.
com.                    63343   IN      NS      c.gtld-servers.net.
com.                    63343   IN      NS      d.gtld-servers.net.
com.                    63343   IN      NS      g.gtld-servers.net.
com.                    63343   IN      NS      e.gtld-servers.net.
com.                    63343   IN      NS      a.gtld-servers.net.
com.                    63343   IN      NS      m.gtld-servers.net.

因此,您可以像这样查询其中任何一个:dig google.com @a.gtld-servers.net。它们会告诉您请求域的权威名称服务器:

;; AUTHORITY SECTION:
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.         172800  IN      AAAA    2001:4860:4802:34::a
ns2.google.com.         172800  IN      A       216.239.34.10
ns1.google.com.         172800  IN      AAAA    2001:4860:4802:32::a
ns1.google.com.         172800  IN      A       216.239.32.10
ns3.google.com.         172800  IN      AAAA    2001:4860:4802:36::a
ns3.google.com.         172800  IN      A       216.239.36.10
ns4.google.com.         172800  IN      AAAA    2001:4860:4802:38::a
ns4.google.com.         172800  IN      A       216.239.38.10

答案3

“.com” 的 TLD 名称服务器是否存储了每个具有“.com” TLD 的网站的相应名称服务器?

是的。多个服务 IP 背后有许多服务器,其中任何一个都可以为查询提供服务。 dig -t NS com.获取列表。

为了好玩我下载了 com。 来自 ICANN。该区域大小为 22 GB,压缩后为 3.9 GB。对于 DNS 来说很大,但对于现代数据库和存储系统来说很小。操作员可以选择哪个数据库实现存储区域数据以及如何复制数据。很可能每个节点都有自己的副本,以便在发生影响某些服务器的停机事件时提高整体服务可用性。

该区域包含哪些 DNS 服务器对给定名称具有权威性。关注 Stack Exchange 基础设施博客的人可能还记得,他们正在对 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.
stackoverflowdevinsights.com.   172800  in      ns      ns1.serverfault.com.
stackoverflowdevinsights.com.   172800  in      ns      ns3.serverfault.com.

另请参阅超级用户:有没有办法无需联系域名主机就可以获取域名的完整区域文件?

相关内容