我不认为我在这里生气…
我们的AD域控制器（Server 2016）是foo.example的DNS服务器。 在那里面，我们有一个委托r53.foo.example ，它指向Amazon Route 53中该区域的名称服务器。
路由53区域中的logging之一是一个ECNAME实例的公有DNS名称的CNAME，即
bar.r53.foo.example IN A ec2-1-2-3-4.us-west-1.compute.amazonaws.com.
Windows DNS服务器设置为使用Google公共DNS服务器作为转发器，并禁用根提示。 recursion已启用。
从客户端，如果我查询ec2-1-2-3-4.us-west-1.compute.amazonaws.com ，它解决正确。 然后，清除所有的DNScaching。
如果我现在查询bar.r53.foo.example ，则Windows DNS服务器将查询委派区域的DNS服务器（由于委派），并获取CNAME结果，但上游服务器不会recursionparsingAlogging。
Windows然后发送一个Alogging查询到委托区域的名称服务器 – 而不是NS为us-west-1.compute.amazonaws.com ，并得到一个us-west-1.compute.amazonaws.com响应。
我会期望它使用configuration的转发器（因为ec2-1-2-3-4.us-west-1.compute.amazonaws.com是不是在一个区域，它主办权威，也不是一个委托区域）， 或至less使用NS为us-west-1.compute.amazonaws.comrecursion解决。 相反，它会让客户没有完整的解决scheme。
如果ec2-1-2-3-4.us-west-1.compute.amazonaws.com IN A 1.2.3.4logging碰巧已经在服务器的caching中，那么客户端查询就完全解决了，但显然这是不可能的，保证。
这味道像臭虫，但也许我错过了什么？
编辑以添加：这只是在Server 2016 DNS服务器下。 在2012 R2下的相同的configuration给出了预期的行为。
由于看起来有几个人正在打这个，我们的解决方法是：
我们运行一个运行ISC绑定的小型Ubuntu虚拟机。 这充当recursionparsing器，并被所有客户端PC用作DNS服务器。 这有转发器configuration为我们的ISP的DNS服务器的“外部”区域和AD域的从属区域：
zone "internal.domain" { type forward; forward only; forwarders { domain.controller.ip; }; };
这样的Windows DNS服务器只作为一个权威的parsing器，recursion解决scheme是由绑定处理。
（如果您希望获得高可用性，则可以使用VRRP或类似的方法来聚合一对recursionparsing器 – 我们在常规虚拟化基础架构上运行我们的主服务器，而在Raspberry Pi上运行我们的主服务器，因为我们可以…）