FailoverClustering EventID 1196 | Network Name Resource

Nesse post iremos abordar um evento relativamente comum que é logado no System EventLog de nós do Cluster que estejam enfrentando problemas relacionados a registros DNS.

O EventID 1196 (Source: FailoverClustering) indica que a atualização do registro DNS de um determinado Cluster Network Name falhou. E, no caso desse cliente, a mensagem de erro trazida foi "DNS operation refused". Esse erro é logado de forma consistente a cada 15 minutos, a cada tentativa de registro DNS em que ocorre falha:

No cluster.log o que vemos é a sequência de eventos a seguir:

d54:274.01/12[13:00:31.698](000000) INFO [RES] Network Name <<-ResourceName->> : Dns: Registering into DNS Name: <-ResourceName-> (Type: Singleton)...
d54:274.01/12[13:00:31.698](000000) INFO [RES] Network Name: Agent: Sending request Netname/GetToken to NN:2265e20f-56e3-40a4-bea6-9e9052c7d61e:Identity
d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NN] IdentityLocal Begin Impersonating
d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] Registering name <-ResourceName-> on DNS Network: contoso.com, with 3 DNS Servers, 1 Virtual Addresses, 1 Domain Names
d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] DNS.S: 172.16.100.xx
d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] DNS.S: 172.16.200.xx
d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] DNS.S: 172.16.100.xx
d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] V.Addr: 172.31.10.xx
d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] Registering: <-ResourceName->.corp.contoso.com
d54:274.01/12[13:00:32.710](000000) INFO [RES] Network Name: [NNLIB] DNS Record there for <-ResourceName->.corp.contoso.com, proceeding
d54:274.01/12[13:00:34.750](000000) ERR [RES] Network Name: [NNLIB] Error 9005 on DNS DnsReplaceRecordSetW for A records, name <-ResourceName->.corp.contoso.com (ipv4Count 1, ipv6Count 0)
d54:274.01/12[13:00:34.750](000000) INFO [RES] Network Name: [NNLIB] Second Phase for DNS Network: corp.ihf (3 DNS Servers)
d54:274.01/12[13:00:34.750](000000) INFO [RES] Network Name: [NN] IdentityLocal End Impersonating
d54:274.01/12[13:00:34.750](000000) ERR [RES] Network Name <<-ResourceName->> : Dns: Failed DNS registration with error 9005 for Name: <-ResourceName-> (Type: Singleton)

O código de erro "9005" traduz exatamente para DNS_ERROR_RCODE_REFUSED:

C:\Users\diegoalb>err 9005
# for decimal 9005 / hex 0x232d :
SQL_9005_severity_16 sql_err
# Either start LSN or end LSN specified in OpenRowset(DBLog,
# ...) is invalid.
DNS_ERROR_RCODE_REFUSED winerror.h
# DNS operation refused.
# for hex 0x9005 / decimal 36869 :
SSLEVENT_NO_PRIVATE_KEY lsapmsgs.mc
# The SSL %1 credential's private key has the following
# 3 matches found for "9005"

Observe que todos os endereços IP associados a um recurso Network Name são registrados dinamicamente no DNS (se estiver configurado para dynamic updates) quando eles são trazidos online - Esse é o comportamento padrão do Cluster.

Para determinar a solução para esse evento teremos de investigar os vários aspectos que envolvem DNS, sobretudo:

• Se os Servidores DNS estão plenamente operacionais e acessíveis;
• Se as zonas e configuração de registro dinâmico estão configuradas de forma apropriada;
• Se a ACL do registro daquele recurso está correta: Na console do DNS clique com o botão direito no registro e em seguida na aba Security - Confirme que o objeto do CNO (Cluster Name Object, tipicamente seguido de "$" como na imagem-exemplo abaixo) tem Full Control;

• Se o registro NÂO está estático (foi criado de forma manual), dessa forma a ACL dele possivelmente estaria errada e incorreríamos no bullet anterior.

Especificamente nesse cliente encontramos que durante o setup do ambiente os administradores tinham um procedimento que envolvia criar o registro de forma manual no Console do DNS para fins de testes (!). Na medida em que o registro era estático, evidentemente o Cluster não tinha permissões suficientes para atualizá-lo.

A solução foi simplesmente apagar o registro estático e forçar novo registro do recurso através do comando Powershell :

Get-ClusterResource <NomedoRecurso> | Update-ClusterNetworkNameResource

Referências:
https://blogs.msdn.microsoft.com/clustering/2009/07/17/dns-registration-with-the-network-name-resource/ https://technet.microsoft.com/en-us/library/hh847276.aspx