我不认为我会在这里发疯……
我们的 AD 域控制器 (Server 2016) 是 的 DNS 服务器foo.example。在其中，我们有一个委派，r53.foo.example，它指向 Amazon Route 53 中该区域的名称服务器。
Route 53 区域中的一条记录是 EC2 实例的公共 DNS 名称的 CNAME，即
bar.r53.foo.example IN A ec2-1-2-3-4.us-west-1.compute.amazonaws.com.
Windows DNS 服务器设置为使用 Google 公共 DNS 服务器作为转发器，并且禁用根提示。启用递归。
从客户端，如果我查询ec2-1-2-3-4.us-west-1.compute.amazonaws.com，它会正确解析。然后，清除所有 DNS 缓存。
如果我现在查询bar.r53.foo.example，Windows DNS 服务器将查询委派区域的 DNS 服务器（因为委派），并获取 CNAME 结果，但该上游服务器不会递归解析 A 记录。
然后，Windows 向委派区域的名称服务器（而不是 的 NS）发送 A 记录查询us-west-1.compute.amazonaws.com，并收到 REFUSED 响应。
我原本希望它使用已配置的转发器（因为ec2-1-2-3-4.us-west-1.compute.amazonaws.com它不在其授权托管的区域或委托区域中），或者至少使用 NS 递归解析us-west-1.compute.amazonaws.com。相反，它让客户端无法完全解析。
如果ec2-1-2-3-4.us-west-1.compute.amazonaws.com IN A 1.2.3.4记录恰好已经在服务器的缓存中，那么客户端查询就会完全解析，但显然这并不能保证。
这闻起来像是一个错误，但也许我忽略了什么东西？
编辑以添加：这仅在 Server 2016 DNS 服务器下才有效。2012 R2 下的相同配置可产生预期的行为。
答案1
由于看起来有几个人遇到了这个问题，我们的解决方法是：
我们运行一个运行 ISC Bind 的小型 Ubuntu VM。它充当递归解析器，并被所有客户端 PC 用作 DNS 服务器。它已将转发器配置为我们的 ISP 的 DNS 服务器，用于“外部”区域，以及 AD 域的从属区域：
zone "internal.domain" { type forward; forward only; forwarders { domain.controller.ip; }; };
这样，Windows DNS 服务器仅充当权威解析器，而递归解析由 Bind 处理。
（如果您想要高可用性，则可以使用 VRRP 或类似技术来集群一对递归解析器 - 我们在常规虚拟化基础架构上运行主解析器，在 Raspberry Pi 上运行辅助解析器，因为我们可以......）