背景：
我有一个包含两个不同 AD 域的环境，每个域都在自己的林中，每个域都有两个 Windows Server 2008 R2 域控制器充当 DNS 服务器。域之间没有信任。
每个 DNS 服务器管理其 AD 域的主 DNS 区域，然后管理一些其他区域，包括其 IP 子网的反向查找区域；所有区域都与 AD 集成；管理某个区域的所有 DNS 服务器都被正确列为该区域的权威名称服务器。
那么，情况是这样的（使用假名和 IP 地址）：
域 A：
DNS 域：domainA.dom
IP 子网：192.168.1
DC/DNS 服务器：serverA1.domainA.dom( 192.168.1.1)，serverA2.domainA.dom( 192.168.1.2)
权威区域：domainA.dom，，1.168.192.in-addr.arpasomezone.local
域 B：
DNS 域：domainB.dom
IP 子网：10.0.0
DC/DNS 服务器：serverB1.domainB.dom( 10.0.0.1)，serverB2.domainB.dom( 10.0.0.2)
权威区域：domainB.dom，，0.0.10.in-addr.arpasomeotherzone.local
域 A 中的 DNS 服务器为域 B 中的 DNS 服务器管理的每个区域定义了条件转发器，转发到域 B 的两个 DNS 服务器；域 B 中的 DNS 服务器具有相反的配置。所有转发器都存储在 Active Directory 中。
一切运行正常，每个域中的计算机都可以使用其域的 DNS 服务器解析两个域的正向和反向 DNS 查询。
问题：
我在域 A 中部署了 SCOM 2012，并且在两个 DC 上都安装了 SCOM 代理；Active Directory 和 DNS 服务器的管理包已安装并且是最新的。
我在两个域控制器上都收到了一系列类似以下的警报；每个转发区域和每个转发服务器都会生成每个警报：
Forwarder someotherzone.local (10.0.0.1) cannot resolve the host name 192.168.1.1,someotherzone.local for serverA1.domainA.dom
Forwarder someotherzone.local (10.0.0.2) cannot resolve the host name 192.168.1.1,someotherzone.local for serverA1.domainA.dom
Forwarder someotherzone.local (10.0.0.1) cannot resolve the host name 192.168.1.2,someotherzone.local for serverA2.domainA.dom
Forwarder someotherzone.local (10.0.0.2) cannot resolve the host name 192.168.1.2,someotherzone.local for serverA2.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.1) cannot resolve the host name 192.168.1.1,0.0.10.in-addr.arpa for serverA1.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.2) cannot resolve the host name 192.168.1.1,0.0.10.in-addr.arpa for serverA1.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.1) cannot resolve the host name 192.168.1.2,0.0.10.in-addr.arpa for serverA2.domainA.dom
Forwarder 0.0.10.in-addr.arpa (10.0.0.2) cannot resolve the host name 192.168.1.2,0.0.10.in-addr.arpa for serverA2.domainA.dom
唯一的例外是域 B 的 DNS 服务器（“domainB.dom”）管理的主 AD DNS 区域：对于该条件转发器，不会生成任何警报并且转发器可用性监视器为绿色。
好吧，这是什么意思？
这些监视器想要告诉我什么？
它们在检查什么？
到底出了什么问题？
为什么配置的“domainB.dom”区域没有错误以同样的方式和其他的一样，既作为域 B 的 DNS 服务器中的区域，又作为域 A 的 DNS 服务器中的转发器？
答案1
找到了答案，但有点不愉快（至少如果你期望创建管理包的人真正知道他们在做什么）。
摘自监视器的描述：
该监视器通过对目标转发器执行 NSLOOKUP 来验证转发器的可用性。
脚本执行
nslookup -timeout=<value> -querytype=<type> <name> <server>
<type>是 A、NS、SOA。
<name>是要解析的目标 DNS 名称。如果是无条件转发器，则使用覆盖值，否则使用转发器域名。
<server>是发生 NSLOOKUP 查询的服务器的名称。
该值为$Target/Property[Type="DNS!Microsoft.Windows.DNSServer.Library.Server"]/ListeningIP$提供当前 DNS 服务器正在监听的所有 IP 地址的列表。
<value>是超时秒数/3，因为超时秒数用于设置脚本可以运行的最大时间。无条件转发器示例：
NSLOOKUP -timeout=30 -querytype=a www.microsoft.com 10.0.0.5将查询服务器 10.0.0.5 以获取 www.microsoft.com 的 DNS 名称。在这种情况下，您可以将实际超时秒数设置为 90 监视器覆盖。条件转发器示例：
NSLOOKUP -timeout=30 -querytype=a www.msn.com 10.0.0.5将查询服务器 10.0.0.5 以获取此监视器所针对的条件转发器的实际名称。
这意味着 SCOM 代理将尝试执行如下查询：
nslookup -timeout=30 -querytype=a domainB.dom <server>
nslookup -timeout=30 -querytype=a someotherzone.local <server>
nslookup -timeout=30 -querytype=a 0.0.10.in-addr.arpa <server>
这对于主 AD 域的 DNS 区域有效（因为 DC 会自动将自己注册A为该区域的空记录），但对于没有任何空A记录的“someotherzone.local”会失败（我可以确认，在手动创建空记录后，警报消失，监视器恢复为绿色）。
当然，第三个查询总是会失败，因为它只是毫无意义A在反向查找区域中查找记录。
解决方案：覆盖 DNS 转发器可用性监视器来执行转发区域的NS或查询，而不是查询。SOAA
这正是它从一开始就应该做的事情。