☰

一段时间后 Azure VM 的名称解析失败

tag-icon • tag-icon domain-name-system azure domain-controller navision
一段时间后 Azure VM 的名称解析失败

我不太擅长管理，所以我将尝试根据我所遇到的情况来描述问题。

我在 Azure 上运行一台装有 Windows Server 2019 Datacenter 的虚拟机。它充当 Navision 服务器。它已加入我们的域。只有一个 DC，在本地充当 AD、DHCP 和 DNS 服务器。DC 和 NAV 服务器之间的连接是通过 VPN 隧道进行的。

最近，用户无法启动 NAV 客户端软件，并收到 Kerberos 错误。原因是 NAV 服务器丢失了域信任关系。NAV 服务器的事件日志中有来自 GP 更新的错误，提示无法解析 DC 的名称。

因此我尝试刷新 NAV 服务器上的 DNS 缓存，并且成功了。不过只成功了几个小时。

  • nltest /query 导致连接状态 1311 (ERROR_NO_LOGON_SERVERS)。
  • ping在 DC 的名称以及 FQDN 上导致找不到主机的错误
  • ping在 DC 的 IP 上起作用了！
  • nslookup在 DC 和 _ldap._tcp.dc._msdcs 上...起作用了！
  • 此时缓存中不保存 DC 的条目，因为它因 TTL 而被删除

我已经从域中删除了 NAV 服务器，然后重新加入，没有任何变化。似乎唯一能修复这个问题的是 DNS 缓存刷新。之后，对 DC 的身份验证也再次正常工作，并且 NAV 客户端软件启动。

为了进行测试，我将 DC-DNS 服务器上的 TTL 减少到一分钟。DNS 条目从缓存中删除后（1 分钟后），ping对 DC 名称的 a 会恢复该条目（正如我所期望的那样）。

如果 NAV 服务器上没有活动，几个小时后，名称解析将再次失败。

更新：我进行了更深入的调查，并检查了从客户端发送的 DNS 流量。只要一切正常，azure-vm 就会发送 DNS 请求并从 DC 接收答案。一个请求，一个回复。一旦名称解析失败，行为如下。

  1. azure-vm 向 DC 发送请求
  2. azure-vm 立即向辅助 DNS 服务器 (1.1.1.1) 发送具有相同 QueryId 的请求 - 这是正常的吗？
  3. 辅助 DNS 服务器回复（名称错误，当然是因为我的 DC 不为 1.1.1.1 所知）
  4. DC 回复正确的 IP 地址

这并不是我想象中的 DNS 客户端的工作方式，而且对我来说它似乎不正确。

答案1

检查所有虚拟机的时间。如果有任何虚拟机的时间不准确，那么你可能会遇到类似的问题。

尤其是在虚拟机环境中。通常主机会向客户端提供时间，但管理员经常会忘记在 PDC 中使用外部时间源，这意味着时间是根据主机内部时钟设置的，而主机内部时钟会随着时间的推移而变化。

相关内容