☰

计算机未在域中解析

tag-icon • tag-icon windows-10 networking dns
计算机未在域中解析

以下情况：

  • 我有 2 台（戴尔）笔记本电脑，类型不同，但使用年限大致相同
  • 两款产品均运行 Windows 10 Pro，补丁级别均为最新
  • 两者都位于 Windows Server 2016 域中
  • 找到一个笔记本，可以通过名称进行 ping 操作（RemoteDesktop 有效）
  • 未找到另一台笔记本，无法通过名称 ping 连接（并且 RemoteDesktop 不起作用）

我做了几项调查/试验：

  • 比较网络设置
  • 比较防火墙设置（包括禁用防火墙）
  • 退出/重新加入域（包括删除域控制器的租约）
  • 检查它们是否属于同一域组
  • 重置 ARP 缓存

仍然：一个笔记本仍然隐藏。nslookup 只对其中一个笔记本有效。请注意，例如通过 IP 地址 ping 和访问远程桌面有效！但由于我们有 DHCP，因此这不是一个好的“解决方案”。

我不知道问题可能出在哪里。我还能检查什么来找出为什么一台笔记本可以正常工作而其他笔记本却不能？

答案1

Active Directory 域中的名称解析使用常规 DNS – 每台计算机通过向 DNS 域的主服务器（这是您的 AD 域控制器之一）发送 DNS“更新”请求来注册自己的地址。

目录 OU（和组）无关紧要；实际的 AD 域加入与计算机使用 Kerberos 验证其发送的更新的程度略有关系，并且您的 DC/DNS 服务器很可能设置为“仅安全更新”（这很好）。但实际的名称解析并不通过 AD。

（ARP 缓存非常无关紧要。防火墙规则与使用“.local”名称的 mDNS/LLMNR 相关，尽管 Windows 防火墙已经为这些规则内置了规则；但是，它们与普通 DNS 无关，因为响应的是 DC，而不是机器本身。）

  1. 运行ipconfig /all并验证是否配置了正确的“域后缀”，包括全局配置（应作为 AD 加入的一部分进行设置）和每个接口配置（从 DHCP 租约中获取）。当您尝试解析“somename”时，操作系统会自动附加此后缀，并且实际查找的是“somename.ad.example.com”，而不仅仅是“somename”。

  2. 查看 ipconfig 时，请确保两个系统都设置了正确的 DNS 服务器。如果您的 AD 域是“内部”域（使用虚构的名称而不是真实的 DNS 域），这一点尤其重要 –两个都机器需要能够查询域名。

    通常这意味着配置机器以使用 AD DC 作为其 DNS 服务器。

    （如果计算机使用 AD DC 作为其 DNS 服务器，则它们应该使用仅有的AD DC 作为其 DNS 服务器 – 即不要将 AD 与 8.8.8.8 或其他任何服务器混合。）

  3. 在丢失的主机上，运行nslookup -q=soa ad.example.com（当然使用您的实际 AD 域名）并确保它收到 SOA 响应，并且第二个字段指向工作的 AD DC（DNS 更新将被发送到那里）。

    然后确保您可以知道nslookup该服务器的名称；确保您可以 ping 它；并确保它响应 DNS 查询（例如nslookup google.com dc01.ad.example.com）。

  4. 打开 DNS 服务器管理控制台 ( dnsmgmt.msc) 并连接到您的其中一个 AD 域控制器。检查两台主机是否都为自己创建了正确的 DNS 记录。

  5. 在丢失的主机上，运行ipconfig /registerdns以使其重新发送 DNS 更新。（您可能需要安装 Wireshark 并查看正在发送的数据包 - 它们是否到达正确的服务器？它们是否携带 GSS-TSIG 身份验证数据？）

    完成此操作后，打开主机上的事件查看器（eventvwr.msc）并在“应用程序”日志中查找与 DNS 更新相关的任何事件。

    如果它们正确到达您的 AD 域控制器但被拒绝，这也应该记录在 DC 的事件日志中（不确定具体是哪个日志）。

  6. 如果更新似乎已成功，请使用 DNS 服务器控制台重新检查。如果有记录，请nslookup在两台计算机上使用 进行测试。

相关内容