DNS público a funcionar não significa que o Active Directory seja encontrado

A VPN liga, o navegador abre um site público e o portátil continua sem conseguir iniciar sessão no domínio. A conclusão habitual é que o DNS está bem porque os nomes se resolvem. Não está, e a razão é que um teste no navegador exercita apenas uma consulta de uma cadeia que um cliente associado ao domínio precisa. A descoberta do domínio pede primeiro registos de serviço, depois os endereços dos controladores que esses registos nomeiam e por fim uma rota para as portas em que esses controladores escutam. Uma resposta pública não satisfaz nenhum desses passos.

O mito: os nomes resolvem-se, logo o DNS está concluído

Que um site público se resolva diz apenas que algum resolvedor respondeu a uma consulta A ou AAAA para um nome numa zona pública. O Active Directory usa o mesmo protocolo para outra pergunta: onde estão os serviços do domínio e que controlador deve este cliente usar. A pergunta é expressa como registos SRV sob uma zona com o nome do domínio, e um resolvedor público recursivo não tem motivo para os guardar.

Quando o registo falta, o resolvedor devolve uma resposta negativa, que é uma resposta DNS válida e não uma falha. O cliente recorre então a informação de controlador em cache se a tiver, e é exatamente por isso que um posto de trabalho pode parecer bem durante horas e falhar após um reinício ou uma mudança de palavra-passe.

O que um cliente de domínio pede na realidade, por ordem

Para um domínio como corp.example, a consulta genérica de localizador é _ldap._tcp.dc._msdcs.corp.example. As respostas SRV nomeiam controladores candidatos e as suas portas, e depois o cliente precisa de registos de endereço para esses nomes de anfitrião antes de abrir uma ligação. A descoberta consciente do site acrescenta consultas sob o subdomínio do site, e as respostas determinam que controladores são preferidos, não qual é obrigatório.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Siga a cadeia por essa ordem, a partir da rede onde o problema ocorre. Um nome de anfitrião que se resolve num endereço inalcançável é uma falha de encaminhamento, não uma falha de DNS. Um controlador alcançável cujos registos de localizador faltam é uma falha de DNS, não uma falha de encaminhamento. Os dois produzem queixas de utilizador semelhantes e reparações completamente diferentes.

Porque é que um resolvedor público responde e o início de sessão continua a falhar

Se o adaptador entrega ao cliente um resolvedor público, os nomes públicos funcionam e o espaço de nomes interno não. Acrescentar um segundo resolvedor público não ajuda, porque nenhum dos dois detém a zona. Também a lista habitual «interno primeiro, público depois» não se comporta como uma regra por domínio: uma resposta negativa do primeiro servidor é uma resposta legítima, e o cliente não volta a tentar o segundo servidor só porque a resposta estava vazia.

Ambos os resolvedores internos, se mantiver dois, devem deter o espaço de nomes do AD e ser alcançáveis a partir da rede atual do cliente. É esta a parte que os desenhos de túnel dividido quebram: a VPN pode transportar a sub-rede do túnel enquanto o resolvedor interno fica num prefixo que o túnel não encaminha, pelo que a consulta sai para um resolvedor que não a consegue responder.

O Windows aplica também uma política de resolução de nomes que pode encaminhar espaços de nomes específicos para servidores específicos, e os endereços DNS que o adaptador mostra não são toda a história. Alterar a lista do adaptador sem alterar essa política pode deixar a configuração efetiva intacta, e é por isso que uma correção que parece aplicada não tem efeito nenhum.

Mantenha o DNS do túnel e as suas rotas em acordo

Um perfil de VPN que empurra um resolvedor mas não o prefixo que o contém cria um resolvedor que o cliente não alcança; um que empurra o prefixo sem resolvedor deixa o cliente a perguntar ao local. Trate o par como um único item de configuração e verifique ambos após cada alteração de perfil, porque um envio reordenado ou uma nova política de túnel dividido os pode separar.

Verifique também o que o cliente faz com a definição enviada. Alguns clientes aplicam o servidor DNS apenas à interface do túnel e deixam o resolvedor do adaptador físico no lugar, pelo que qual ganha depende da métrica da interface e do nome consultado. Se a resposta interna só chega quando o adaptador físico está desativado, esse é o mecanismo a corrigir, não os registos do domínio.

Aceite com uma chamada de descoberta e uma operação real

Um teste de aceitação útil executa a consulta de localizador e depois realiza uma operação autenticada real, como abrir uma partilha suportada pelo diretório ou pedir um bilhete. Faça-o antes da transição da VPN e de novo depois, na mesma máquina, sem reiniciar pelo meio. Credenciais em cache e sessões já abertas farão com gosto um caminho quebrado parecer saudável, por isso um início de sessão bem-sucedido no ambiente de trabalho não é o teste.

As recomendações da Microsoft para o cliente DNS traçam a mesma linha entre resolver o espaço de nomes interno e reencaminhar as consultas públicas para cima, e é essa a disposição a preservar quando se introduz uma VPN.

Se a falha for apenas lenta e não falhada, mantenha o atraso separado do diagnóstico. Um tempo limite durante a descoberta pode vir de um controlador inalcançável, de uma porta bloqueada ou de um resolvedor que responde tarde, e nada disso fica provado apenas pela espera. Capture a consulta real, a sua resposta e a tentativa de ligação antes de alterar qualquer definição do resolvedor.