Última sexta-feira, liguei a eliminação de DNS num dos meus controladores de domínio. Isso foi feito com o objetivo de remover antigos registros A não usados de computadores desativados. No entanto, descobriu-se que nosso DHCP (fornecido pelo hardware da Meraki) estava mal configurado e não retransmitia informações para o DNS, portanto, os computadores geralmente só criavam registros A quando eram unidos ao domínio pela primeira vez. Devido a isso, depois que a limpeza foi executada no sábado, 600 dos 900 registros A foram removidos. Esse não é o problema que estou perguntando embora.
O problema real é que, desde a execução do DNS Scavenging, vários computadores não conseguiam acessar os recursos internos pelo nome. Isso afetou principalmente laptops de trabalhadores remotos que se conectam à nossa VPN, mas também tivemos laptops afetados que nunca deixaram a nossa rede corporativa, bem como um servidor. Alguns sintomas mais precisos:
Os computadores afetados não podem fazer ping em nenhum de nossos servidores pelo nome, recuperando um erro "A solicitação de ping não pôde encontrar o host x. Verifique o nome e tente novamente." A execução do wireshark mostra que o ping inicia uma solicitação de DNS, que retorna o resultado "0x8182 resposta de consulta padrão, falha do servidor". Os computadores afetados podem executar o nslookup em qualquer um de nossos servidores, recuperando o nome e o endereço IP adequados. Os computadores afetados podem efetuar ping em qualquer um dos nossos servidores por endereço IP. Os computadores afetados tiveram seus registros A excluídos do DNS, mas muitos outros computadores tiveram seus registros A excluídos e continuaram funcionando bem. O DNS externo funciona bem para computadores afetados. Executar ipconfig / registerdns de um computador afetado não cria um novo registro de zona de pesquisa direta.
A única solução bem-sucedida que conseguimos até agora envolve a remoção de um computador de nosso domínio e a leitura dele. Na maioria dos casos, isso corrige problemas e o computador pode acessar recursos de rede com êxito. No entanto, isso não cria novos registros A para computadores no DNS, e alguns computadores afetados não são corrigidos e continuam sendo incapazes de acessar recursos de rede ou servidores de ping.
Tentativas de correção:
Executando vários comandos para limpar as configurações de rede dos computadores afetados: ipconfig / flushdns, ipconfig / registerdns, ipconfig / release, ipconfig / renew, netsh winsock reset catalog, netsh int ip reset reset.log, route / f. Junto com as reinicializações, nenhuma delas mudou o problema. Navegar para um computador afetado no AD e clicar em Redefinir conta. Isso também não mudou. Reiniciar controladores de domínio várias vezes - sem alteração. Habilitando o log de depuração de DNS - isso mostra que as consultas internas de DNS dos PCs afetados estão recebendo de volta mensagens com um RCODE de 2, indicando uma falha do servidor. Veja o final para um exemplo completo de pacote. Atualizações dinâmicas atualizadas da zona de pesquisa direta para permitir atualizações não seguras e seguras. - Nenhuma mudança. Criamos um novo controlador de domínio virtual do servidor 2016 no Azure e reconfiguramos o DHCP para direcionar alguns computadores afetados a usá-lo como seu servidor DNS primário. - Depois disso, os computadores afetados que o usam como servidor DNS criam novos registros A no DNS. Eles ainda não podem acessar os recursos de rede pelo nome.
Portanto, ainda não conseguimos fazer com que todos os computadores afetados funcionem novamente, e tivemos que remover e reintegrar muitos computadores de nosso domínio como solução alternativa. Se algum de vocês sabe o que poderia causar esta ou outras correções potenciais, por favor me avise.
Exemplo de retorno de pacote DNS:
5/15/2018 9:11:07 AM 17CC PACKET 00000211E32038A0 UDP Snd 10.2.151.35 aa53 R Q [8281 DR SERVFAIL] A (7)dcazure(0)
UDP response info at 00000211E32038A0
Socket = 724
Remote addr 10.2.151.35, port 50641
Time Query=40319, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0019 (25)
Message:
XID 0xaa53
Flags 0x8182
QR 1 (RESPONSE)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 1
Z 0
CD 0
AD 0
RCODE 2 (SERVFAIL)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(7)dcazure(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
Após uma solução de problemas adicional, descobrimos que esse problema era devido ao fato de o Directaccess estar mal configurado nas máquinas clientes e fazer com que eles acreditassem que não estavam em nossa rede corporativa quando estavam. Corrigido isso ajustando nossa política de grupo do Directaccess e excluindo uma chave do Registro nos clientes afetados para forçá-los a limpar as configurações existentes.