总结：当主托管区域包含两个 NS 记录时，其中包含主托管区域（example.com）和子域托管区域（sub.example.com）的名称服务器，这是否足以通过 example.com 的名称服务器解析 sub.domain.com？
域名目前由 name.com 管理，但 DNS 应由 AWS Route 53 管理，以便自动创建新的子域名并动态设置记录。
域名所有权应归 name.com 所有，这意味着需要为该域名配置自定义名称服务器example.com
类似的子域名也sub.example.com应该通过的名称服务器进行解析example.com，否则添加新的子域名就需要在 name.com 上配置自定义名称服务器。
在当前设置中，每个域和子域都在其自己的托管区域中。example.com有一个 NS 记录，sub.example.com也有一个。 现在为了委托，我在 中添加了另一条NS记录，example.com用于sub.example.com包含名称服务器sub.example.com
因此托管区域中有两条 NS 记录example.com。然而，当我运行
dig @ns-of-example.com sub.example.com
我没有得到答案部分，尽管权威部分包含正确的名称服务器。我本以为 dig 会进行递归，然后询问那里列出的权威名称服务器。
但我认为我的 DNS 协议在这里的工作逻辑存在缺陷。
答案1
尽管权威部分包含正确的名称服务器，但我没有得到答案部分。
那你应该没问题。默认情况下，dig它只询问你告诉它询问的服务器，并显示该服务器的答案。
我本来假设 dig 会进行递归，然后询问那里列出的权威名称服务器。
这是一个错误的假设。如果您想要一个可以完全有效地测试域名在互联网上的行为的递归查找，您需要让公共递归解析器为您执行此操作，例如dig @8.8.8.8 my-sub.example.com。
否则，您可以获得所需的行为，dig ... +trace但请注意，在某些情况下，这可能会给您一种虚假的成功感，因为它不是使用递归解析器进行查找 - 这是普通机器进行查找的方式。