我正在用我们的AD Dnsparsing器遇到一些奇怪的行为。 我们的Windowsnetworking使用AD作为DNSparsing器，然后parsing像Google.com等查询。 在那里所有的罚款和花花公子。
有一天，我开始挖掘（在Windows上，耶！），向同事展示问题，我查询： $ dig ANY google.com 。 结果是非常less的，只有Alogging，最初让我想到谷歌已经杀了他们的服务。 更好的想法盛行，我问： $ dig ANY @8.8.8.8 google.com ，当然这给所有logging预期humongous结果。
我已经发现了微软方面似乎是一个caching技巧，根据当前的caching，它们将ANY查询的响应拼凑在一起。 以下步骤将有助于重现此问题。 对AD和AD DNS服务器执行所有这些步骤。
使用ANY查询来查询目标域： $ dig ANY example.com 。 注意结果只有A和AAAAlogging。
使用其他types（例如MX或TXT查询目标域： $ dig MX example.com 。 validation结果是否符合预期。
再次发出原始的ANY查询，现在注意结果包括来自步骤2的MXlogging。
我发现最好在每个testing中select一个新域，因为之前的testing将在AD DNS中caching结果。 使用Google的parsing器（或其他parsing器）来validation预期结果，例如： $ dig ANY example.com @8.8.8.8 。
任何人都可以确认吗？ 这是在AD DNS设置，防止它recursion解决ANY查询 – 因为它们在某种程度上比其他任何东西都更昂贵？
我一个人发现这种行为是完全错误的。
答案是ANY实际上不是DNS资源types。 相反，它指的是查询types*。 根据wikipedia，“返回名称服务器已知的所有types的所有logging，如果名称服务器没有关于名称的任何信息，请求将被转发，返回的logging可能不完整，例如，如果有既是名称的A也是MX，但名称服务器只有Alogging被caching，只有Alogging被返回。 如果你好奇的话，这个想法在RFCs 1034和1035中更加明确地expression出来。
因此，您的Windows AD DNS服务器正在响应，因为您已经要求它响应 – 目前已caching的信息。
尝试做一个挖掘MX google.com或挖TXT google.com然后重复您的挖掘任何google.com。
祝你好运。