Monitor de disponibilidade do encaminhador de DNS do SCOM 2012

Question

Histórico:

Eu tenho um ambiente com dois domínios do AD diferentes, cada um em sua própria floresta, cada um com dois controladores de domínio do Windows Server 2008 R2 atuando como servidores DNS. Não há confiança entre os domínios.

Cada servidor DNS gerencia a zona DNS principal para seu domínio do AD e, em seguida, algumas outras zonas, incluindo a zona de pesquisa inversa para suas sub-redes IP; todas as zonas são integradas por AD; todos os servidores DNS que gerenciam uma zona são listados corretamente como servidores de nomes autoritativos para essa zona.

Então, a situação é assim (usando nomes falsos e endereços IP):

Domínio A:
Domínio DNS: domainA.dom
Sub-rede IP: 192.168.1
DCs / Servidores DNS: serverA1.domainA.dom ( 192.168.1.1 ), serverA2.domainA.dom ( 192.168.1.2 )
Zonas autoritativas: domainA.dom , 1.168.192.in-addr.arpa , somezone.local

Domínio B:
Domínio DNS: domainB.dom
Sub-rede IP: 10.0.0
DCs / Servidores DNS: serverB1.domainB.dom ( 10.0.0.1 ), serverB2.domainB.dom ( 10.0.0.2 )
Zonas autoritativas: domainB.dom , 0.0.10.in-addr.arpa , someotherzone.local

Os servidores DNS no domínio A têm encaminhadores condicionais definidos para cada zona gerenciada pelos servidores DNS no domínio B, encaminhando para os dois servidores DNS do domínio B; Servidores DNS no domínio B têm a configuração oposta. Todos os encaminhadores são armazenados no Active Directory.

Tudo funciona perfeitamente e os computadores em cada domínio podem resolver consultas DNS avançadas e reversas de ambos os domínios, usando os servidores DNS de seu domínio.

O problema:

Eu tenho o SCOM 2012 implantado no domínio A, com o agente SCOM instalado em ambos os DCs; os pacotes de gerenciamento do Active Directory e do Servidor DNS estão instalados e atualizados.

Eu tenho uma série de alertas como os seguintes em ambos os controladores de domínio; cada alerta é gerado para cada zona encaminhada e para cada servidor encaminhado:

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

A única exceção é a principal zona DNS do AD gerenciada pelos servidores DNS do domínio B ("domainB.dom"): para esse encaminhador condicional, nenhum alerta é gerado e o monitor de disponibilidade do encaminhador é verde.

Ok, o que isso significa?
Quais são esses monitores tentando me dizer?
O que eles estão checando?
O que há de errado?

E por que não há erro para a zona "domainB.dom", que é configurada exatamente da mesma forma como as outras, como zona nos servidores DNS do domínio B e como encaminhador em servidores DNS do domínio A?

    

Answer 1

A resposta foi encontrada e é um pouco desagradável (pelo menos se você estivesse esperando que as pessoas que criassem pacotes de gerenciamento realmente soubessem o que estão fazendo).

Extraído da descrição do monitor:

This monitor verifies forwarder availability by performing an NSLOOKUP on the targeted forwarder.

The script executes nslookup -timeout=<value> -querytype=<type> <name> <server>

<type> is A, NS, SOA.

<name> is target DNS name to resolve. If unconditional forwarder, the override value is used else the forwarder domain name is used.

<server> is the name of the server where the NSLOOKUP query occurs.
The value is $Target/Property[Type="DNS!Microsoft.Windows.DNSServer.Library.Server"]/ListeningIP$ which provides a listing of all IP addresses that the current DNS server is listening on.

<value> is timeout seconds/3 because timeout seconds is used to set the maximum time the script can run.

Unconditional Forwarder Example: NSLOOKUP -timeout=30 -querytype=a www.microsoft.com 10.0.0.5 would query server 10.0.0.5 for the DNS name for www.microsoft.com. In this case, you would set the actual timeout seconds to 90 monitor override.

Conditional Forwarder Example: NSLOOKUP -timeout=30 -querytype=a www.msn.com 10.0.0.5 would query server 10.0.0.5 for the actual name of the conditional forwarder targeted by this monitor.

O que isto significa é que o agente SCOM tentará realizar consultas como estas:

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>

Isso funcionaria para a zona DNS do domínio principal do AD (porque os CDs se registram automaticamente como A registros vazios para essa zona), mas falhariam em "someotherzone.local", que não tinha nenhum A vazio gravar (posso confirmar que, depois de criar manualmente um, o alerta desapareceu e o monitor voltou a ficar verde).

A terceira consulta, é claro, sempre falharia, porque apenas não faz sentido algum procurar por um registro A em uma zona de pesquisa inversa.

Resolução: substitua o Monitor de disponibilidade do encaminhador de DNS para executar uma consulta NS para a zona encaminhada em vez de uma consulta A . Qual é o que deveria ter feito desde o início.