☰

问题

tag-icon • tag-icon domain-name-system nameserver microsoft-dynamics-crm
问题

问题

如果父域的 DNS 服务器不为子域提供 NS 记录，那么子域使用与父域不同的名称服务器是否有效？

例如：

  • 运行Resolve-DnsName -Name example.com -Type NS -Server 1.1.1.1返回ns1.example.com；ns1.example.com的权威名称服务器也是如此example.com。
  • 运行Resolve-DnsName -Name subdomain.example.com -Type NS -Server 1.1.1.1返回ns2.example.com；ns2.example.com的权威名称服务器也是如此subdomain.example.com。

我希望ns1.example.com包含 NS 记录集，以subdomain.example.com告知客户端“我不管理此子域的 NS 记录，对于这些记录，请与其名称服务器通信”。即我希望Resolve-DnsName -Name subdomain.example.com -Type NS -Server ns1.example.com返回ns2.example.com。

注意：如果子域使用与其父域相同的 NS 服务器，则我不会期望对上述内容做出响应。

（解析 DNS 名称只是一个nslookup命令，其中Name参数是需要获取的 FQDN，Server是需要查询的名称服务器，并Type允许我们指定我们所需的 DNS 记录类型）。

我的理解是否正确，或者子域名是否可以具有与其父域名不同的名称服务器，而其父域名无需为子域名托管 NS 记录？

语境

我们在使用 MS Dynamics 365 for Finance and Operations 时遇到了间歇性问题，有时用户浏览实例时会看到以下错误：

The site can’t be reached
Check if there is a typo in EXAMPLE.operations.dynamics.com
If spellling is correct, try running Windows Networkk Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN

上述错误的屏幕截图

用户正在使用正确的 URI/主机名。

通常，此问题会在约 30 分钟后自行解决。我们在生产（EXAMPLE.operations.dynamics.com和测试（EXAMPLE.sandbox.operations.dynamics.com）中都看到了这个问题。

经过调查，如果我尝试使用我们的公司 DNS 服务解析 FQDN，则无法解析；确认浏览器的错误；但是当我们针对公共 DNS 服务（例如 CloudFlare 的1.1.1.1）进行解析时，通常可以正确解析。注意：我们也看到了这个问题，远程工作的用户（不使用我们的公司 DNS 服务）有同样的问题 / 这里他们的 ISP 的 DNS 服务显示它无法解析 FQDN。

我相信问题与 DNS 有关，并且 CloudFlare 的 DNS 通常更可靠，因为它们会将 DNS 条目缓存更长时间（或者由于它们的服务器被访问的次数更多，因此它们更有可能拥有缓存条目）。

具体来说，当我们的环境的 FQDN 解析出现问题时，我通常可以根据 CloudFlare 的 DNS 和该子域的 MS 权威名称服务器来解决问题（正如您所期望的那样）...但尝试从其父域的权威名称服务器获取子域的权威名称服务器失败；例如，参见下面突出显示的 2 个错误：

屏幕截图显示，从 cloudflare 获取子域的名称服务器有效，而从父域的名称服务器获取子域的名称服务器则出现错误

这是我对 DNS 的理解存在问题（意味着我们需要进行更多调查才能找到问题的根本原因），还是 MS 实施的配置问题？

注意：我已就上述问题联系了 MS 支持，但支持 Dynamics 的团队是应用程序支持团队，因此无法协助解决 DNS/基础设施相关问题或将我的票转发给可以提供帮助的团队。

答案1

但尝试从父域的权威名称服务器获取子域的权威名称服务器失败

这看起来更像是 PowerShell 故障，而不是 DNS 故障。Wireshark 告诉我服务器给出了成功的答复——但这是一个转诊在“权威”部分中有 NS 记录，而不是在“答案”部分中有（NS 记录的“父副本”不会产生答案 - 它仅用于引用），并且 PowerShell 显然并不期望这一点。

尝试使用其他工具执行相同的查询：

  • 视窗nslookup -d -q=NS operations.dynamics.com. ns1-205.azure-dns.com.
    （忽略出现的 PTR 查询，nslookup 总是会执行一个）

  • Linux/WSLdig operations.dynamics.com. NS @ns1-205.azure-dns.com.

我建议使用最新版本的dig，因为它支持 DNS EDE – 扩展错误数据，它允许解析器（例如 1.1.1.1）提供有关它为什么给您 SERVFAIL 的更详细信息。（这与您的 PowerShell 错误实际上无关，因为您无论如何都是直接查询权威服务器而没有任何中介；这更像是一般性建议。）

我的理解是否正确，或者子域名是否可以具有与其父域名不同的名称服务器，而其父域名无需为子域名托管 NS 记录？

两份名单应该匹配，但只要 NS 记录在父母域指向一组有效的名称服务器。不匹配的 NS 记录集并非严格正确，但可能会长期不被注意。

子域名服务器的 NS 列表是您通过手动查询公共解析器获得的-Type NS，但只有父域名服务器的 NS 列表才会用于从父域名到子域名的引用（当然，因为此时可能还不知道子域名服务器的内容）。

因此，如果子域名实际上具有更多父级 NS 列表副本中缺少的名称服务器，则不应导致故障 - 额外的名称服务器将保持未使用状态（即使它们会出现在-Type NS针对公共解析器的手动查询中）。

总结一下：

  • 如果父区域的列表不完整，那么缺失的服务器根本就不会被使用，即使子区域列出了它们（同样，如果子区域有虚假条目，它们也不会被使用）。

    这是唯一一个问题DNSViz您的域名的报告。

  • 如果父级列表具有未配置为托管子域的无关名称服务器（即，它们返回 REFUSED 或横向推荐），那么这是一个严重问题，并将导致您看到 SERVFAIL。

  • 如果孩子自己的列表不完整，您只会在-Type NS查询中注意到这一点，但除此之外不会发生太多事情。

  • 如果子列表自己的列表中有多余的名称服务器，您同样只会在手动查询中注意到它，但除此之外不会发生太多事情 - 解析器不会联系它们。

举例来说，如果父区域 (example.com) 具有：

sub.example.com. NS ns1.example.com.
sub.example.com. NS ns2.example.com.

子区域 (sub.example.com) 具有：

sub.example.com. NS ns2.example.com.
sub.example.com. NS ns3.example.com.
sub.example.com. NS ns4.example.com.

那么 ns1/ns2 都应为权威服务器，而 ns3/ns4 将不会用于任何用途，即使进行显式-Type NS查询将返回“NS ns2、ns3、ns4”

但是，如果您有此配置，但 ns1/ns2 未配置为托管子区域，则它们将向解析器响应 REFUSED，并将该响应作为 SERVFAIL 传播给您。此外，ns1/ns2不是允许使用“横向推荐”来响应 ns3/ns4 - 如果发生这种情况，您将收到 SERVFAIL。

相关内容