主页 / server / 问题 / 1156593
Accepted
JohnLBevan
Asked: 2024-03-20 19:36:14 +0800 CST

DNS 与 Microsoft Dynamics Finance and Operations 的奇怪之处

  • 772

问题

如果父域的 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 服务器，我不会期望对上述内容做出回应。

（Resolve-DnsName只是一个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/基础设施相关问题，也无法将我的票证转给可以提供帮助的团队。

domain-name-system

1 个回答

  1. Best Answer

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

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

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

    • Windows 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。

    • 1

相关问题