如何防止与 IPv6 AAAA 记录相关的延迟？

Question

我们的 Windows 服务器正在AAAA向我们的 Windows DNS 服务器注册 IPv6记录。但是，我们的网络上没有启用 IPv6 路由，因此这经常导致停顿行为。

Microsoft RDP 是最严重的罪犯。当连接到AAAA在 DNS中有记录的服务器时，远程桌面客户端将首先尝试 IPv6，并且在连接超时之前不会回退到 IPv4。高级用户可以通过直接连接到 IP 地址来解决此问题。使用ping -4 hostname.foo始终可以立即解析 IPv4 地址。

我该怎么做才能避免这种延迟？

• 在客户端上禁用 IPv6？
  • 不，微软表示IPv6 是 Windows 操作系统的强制性部分。
  • 客户端太多，无法确保在任何地方一致设置。
  • 以后我们最终实现IPv6的时候会引起更多的问题。
• 在服务器上禁用 IPv6？
  • 不，微软表示IPv6 是 Windows 操作系统的强制性部分。
  • 需要一个不方便的注册表黑客来禁用整个 IPv6 堆栈。
  • 确保在所有服务器上正确设置这一点很不方便。
  • 以后我们最终实现IPv6的时候会引起更多的问题。
• 屏蔽用户身份 DNS 递归上的 IPv6 记录？
  • 不，我们正在使用 NLNet Unbound 而它不支持。
• 阻止在 Microsoft DNS 服务器上注册 IPv6 AAAA 记录？
  • 我认为这甚至不可能。

此时，我正在考虑编写一个脚本，从我们的 DNS 区域中清除所有 AAAA 记录。请帮我找到更好的方法。

---

更新： DNS 解析不是问题。正如@joeqwerty 在他的回答中指出的那样，DNS 记录会立即返回。双方A并AAAA记录立即可用。问题是某些客户端 ( mstsc.exe) 将优先尝试通过 IPv6 进行连接，并需要一段时间才能回退到 IPv4。

这似乎是一个路由问题。ping由于目标地址不可路由，该命令会产生“一般故障”错误消息。

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

我无法获得此行为的数据包捕获。运行此（失败）ping 命令不会在 Microsoft 网络监视器中生成任何数据包。同样，尝试连接mstsc.exe到具有AAAA记录的主机不会产生流量，直到它回退到 IPv4。

更新：我们的主机都在使用可公开路由的 IPv4 地址。我认为这个问题可能归结为损坏的 6to4 配置。6to4 在具有公共 IP 地址和 RFC1918 地址的主机上的行为不同。

更新：我的网络上 6to4 肯定有问题。当我在 Windows 客户端上禁用 6to4 时，连接会立即解析。

netsh int ipv6 6to4 set state disabled

但正如@joeqwerty 所说，这只掩盖了问题。我仍在尝试找出为什么我们网络上的 IPv6 通信完全不起作用。

Answer 1

这个问题很有趣，我必须承认我从未见过这种行为。在做一些摆弄以尝试更好地理解它时，我从另一台 W2K8R2 服务器中获取了一段 nslookup 查询我的 W2K8R2 RDS 服务器的片段，并且我还捕获了来自同一测试服务器的同一 RDS 服务器的 RDP 会话片段. Nslookup 显示返回 IPv6 记录没有延迟，并且 nslookup 显示我的测试服务器在查询 IPv6 记录之前查询 IPv4 记录。捕获中的时间增量显示在任一查询中都没有明显的延迟（我可以确定）。

编辑

现在你正在做一些事情。

确保您正在捕获 Microsoft 6To4 适配器的流量，否则您将看不到 IPv6：

这是我的 RDS 服务器的 nslookup 结果。记下 IPv6 地址：

现在这是我捕获的片段：

最后，这是 netstat 中显示连接的片段：

很明显，正如您所确认的，DNS 解析不是问题所在。问题是 RDP 连接更喜欢 IPv6 而不是 IPv4（这是 Windows 的默认设置 - Windows 更喜欢 IPv6 而不是 IPv4），并且因为 IPv6 无法正常运行，它会导致延迟（如您所述）从 IPv6 回退到IPv4。您可以通过将客户端配置为更喜欢 IPv4 而不是 IPv6 来解决此问题，但我认为这只会掩盖问题。更好的解决方案是找出 IPv6 不起作用的原因并修复它。我对 IPv6 的了解不够，但我的猜测是 DNS 返回的 IPv6 记录是“本地”地址，仅在存在 RDS 主机的子网中有效，并且由于客户端位于不同的子网中，因此它们不能t 到达这些 IPv6 地址。

Answer 2

称为 6to4 的 IPv6 过渡技术因引发此类问题而臭名昭著。有几个因素在起作用。单独而言，它们是无害的，但综合效果是最终用户可能会遇到连接延迟。

下面列出了一系列促成因素和对其缓解的想法。

Windows 默认启用 6to4

如果您的主机运行的是最新版本的 Windows（Vista 或更高版本），当可公开路由的 IPv4 地址可用时，Windows 将机会性地启用 6to4 隧道。至关重要的是，这适用于服务器和客户端。

要确定系统是否正在使用 6to4，请运行ipconfig并查找以 6to4 前缀开头的 IPv6 地址2002:。它看起来像这样。

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• 如果您的端点连接到 Active Directory，您可以使用组策略禁用 6to4 和 Teredo 等过渡协议。这在KB929852中有详细记录。（将此应用于您的客户端或服务器就足够了，但如果您正在执行此步骤，则在客户端和服务器上的任何地方禁用它可能是有意义的。）
• 如果您只管理几台主机，则可以根据具体情况禁用 6to4。这比完全禁用 IPv6 好得多。netsh int ipv6 6to4 set state disabled
• 使用不同的客户端操作系统。例如，Mac OS X 默认没有启用 6to4。

正在使用可公开路由的 IPv4 地址

6to4 仅适用于具有可公开路由的 IPv4 地址的主机，因此此问题永远不会影响 NAT 防火墙后面的主机。

• 您可以将客户端和/或服务器移到 NAT 防火墙后面，并开始使用 RFC1918 寻址。但在某些情况下，公共可路由地址实际上是首选。改变整个网络的寻址也可能是一个不切实际的选择。

6to4 在网络上运行不正常

在任播模式下对 6to4 进行故障排除是出了名的困难。麻烦的是，IETF 正式要求6to4 应重新归类为历史版本。在作者看来，6to4 已被弃用。

简而言之，6to4 的工作原理是使用称为 6in4（IP 协议 = 41）的协议将 IPv6 数据包封装为 IPv4 数据包。IPv4 数据包被寻址到任播地址192.88.99.1，希望它能够到达互联网上某处工作的 6to4 中继。如果幸运的话，它甚至可能在地理位置上很近。

在实践中，一些 6to4 中继设置不正确，很多网络甚至不允许 6in4 流量穿过防火墙。通常，当防火墙允许所有出站流量，但没有明确允许 IP 协议 41 数据包通过防火墙返回时，就会发生这种情况。（TODO 请注意相关 RFC 以进行故障排除。）此故障（“入站黑洞”）和许多其他故障在RFC 6343 中进行了描述。

• 将防火墙设置为在从网络内部主机发送时大声拒绝 IP 协议 41（带有 TCP 重置）。这应该会导致“快速失败”行为，这比非确定性连接延迟更有意义。这已被证明可以在有限的测试环境中工作。
• 要求您的 ISP 或第一跳传输提供商设置一个有效的 6to4 中继。如果这样做得当，它将为最终用户带来最佳体验。任何拥有可公开路由的 IPv4 地址的最终用户都能够参与 IPv6 互联网。

动态DNS注册

在典型的 Active Directory 环境中，每台计算机都可以向 DNS 服务器注册自己的地址。当主机是多宿主时，它将注册其所有地址，即使是来自 6to4 隧道。

大多数 Internet 服务不使用动态 DNS，因此此问题通常仅限于客户端和服务器都在同一网络“内部”的企业站点。

• 您可以选择禁用动态 DNS 更新。然后，如果您不将任何 AAAA 资源记录放入区域文件，它们将永远不会被提供。但是，内部 DNS 服务器通常需要动态 DNS。（如果您这样做，请确保同时删除可能已经存在的所有 AAAA 记录。）
• 设置 DNS 服务器不为 AAAA 资源记录提供答案。但是不要这样做，因为当您要开始实施 IPv6 时，它真的会给您带来麻烦。（有人知道免费/开源 DNS 防火墙吗？）

客户端应用程序不会正常失败

Microsoft 的 RDP 客户端是无法妥善处理 IPv6 路由问题的客户端应用程序的一个示例。大多数 Web 浏览器更擅长处理像这样的 IPv6 边缘情况，因此它们不会表现出这种行为。

• 尝试使用不同的客户端。也许你会走运。