Registos DNS dos clientes VPN: proprietário, TTL e limpeza são coisas distintas

Os portáteis ligam-se, recebem um endereço VPN, e o nome que os outros sistemas resolvem ainda aponta para o endereço de escritório de ontem. Nada falhou: um endereço foi atribuído, um registo não foi atualizado e uma cache ainda guarda a resposta antiga. São três objetos com três proprietários, e apenas um deles pertence à VPN. Planear a publicação significa decidir quem escreve o nome, que interfaces participam e quando os dados obsoletos desaparecem.

O sintoma: um nome que segue o endereço errado

No dispositivo, o túnel está ativo e o endereço VPN responde. Na estação de trabalho de um colega, o mesmo nome de anfitrião resolve para um endereço privado que o dispositivo já não tem, pelo que a ligação expira contra uma máquina que se mudou. O registo é autoritativo e errado, o que é pior do que ausente. Todos confiam nele e ninguém consegue ligar-se.

O caso inverso é mais silencioso: o registo desaparece e o nome deixa de resolver por completo. Ambos os resultados vêm da mesma lacuna de conceção, e nenhum deles é corrigido baixando o TTL. Uma vida de cache mais curta altera quanto tempo a resposta errada sobrevive, não se é escrita.

Comece por perguntar qual objeto está obsoleto. O endereço atribuído pela VPN, o registo na zona e a resposta na cache de um resolvedor têm vidas diferentes e proprietários diferentes.

Três objetos, três proprietários

A VPN possui a atribuição de endereços, e pode entregar o endereço a partir de um pool interno sem que nenhuma troca DHCP chegue ao portátil. A zona DNS possui o registo, e o seu modelo de segurança decide quem o pode criar ou alterar. A cache do resolvedor possui a cópia que um leitor está a usar agora, e nada do que o dispositivo faz consegue chegar lá.

Presumir que um único componente faz as três coisas é onde o desenho se quebra. Um endereço que parece vir de um intervalo gerido não prova que um servidor DHCP tenha feito o registo, e um registo bem-sucedido não prova que os leitores tenham atualizado a cache.

Quem pode atualizar o registo

Numa zona integrada no Active Directory e com atualizações dinâmicas seguras, as permissões vivem no próprio registo. Um registo criado por uma conta de serviço DHCP pode não ser escrevível pela conta de computador do portátil, e mudar o modelo de propriedade mais tarde é uma transição, não um interruptor. É por isso que um conflito de propriedade sobrevive a qualquer definição do lado do cliente.

As orientações da Microsoft sobre atualizações dinâmicas preferem o registo do lado do cliente para pontos finais híbridos associados ao domínio. Adotá-las significa transferir deliberadamente os registos existentes, e não apenas marcar uma caixa no adaptador VPN e esperar que o antigo proprietário ceda.

Quando um serviço DHCP tem de registar para outras classes de dispositivos, dê-lhe o modelo de credenciais e permissões suportado para essa função. Mantenha os registos diretos e inversos no mesmo plano, porque são frequentemente mantidos por componentes diferentes e um deles costuma ser esquecido.

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

O primeiro comando mostra que endereços o dispositivo pensa ter e se a ligação está configurada para os registar. O segundo e o terceiro comparam o que um cliente resolve com o que a zona armazena realmente, e isso separa um problema de cache de um problema autoritativo.

Três relógios, não um

A publicação e a atualização são o primeiro relógio: quando o atualizador autorizado anuncia que um endereço mudou. O TTL da cache é o segundo: quanto tempo um resolvedor pode guardar a resposta recebida. A limpeza autoritativa é o terceiro: como os registos obsoletos são removidos pelo processo de registo ou pelo envelhecimento e pela limpeza.

Estes relógios são independentes, e confundi-los produz correções que não funcionam. Uma alteração num é invisível para os outros dois. Um TTL curto encurta a vida de uma resposta em cache e não concede qualquer permissão de atualização. A limpeza remove registos que não foram atualizados, e não pode reparar um registo que nunca foi escrito pelo proprietário correto.

Defina o TTL pela rapidez com que os leitores devem ver uma alteração, e a limpeza pelo tempo que um dispositivo abandonado deve conservar um nome. Nenhum dos dois números decide quem pode escrever o registo, e nenhum valor de TTL transforma a atribuição de endereços em direitos de administração de DNS.

Planeie a publicação para um dispositivo itinerante

Decida que interfaces participam no registo. Um endereço Wi-Fi doméstico, um endereço VPN e um endereço de escritório antigo servem públicos diferentes, e publicá-los todos produz um nome com várias respostas de utilidade desigual. Registe as interfaces que os leitores previstos conseguem realmente alcançar.

Mantenha o nome do computador estável como identidade e trate os endereços como atributos dele. Preserve os registos de descoberta de domínio de que o dispositivo precisa, e não desative o registo em bloco para resolver um problema de registos duplicados que uma alteração de permissões resolveria.

Escreva o atribuidor, o atualizador e o proprietário da limpeza num único registo, com os leitores previstos nomeados. Quando o nome voltar a apontar para o endereço errado, esse registo diz-lhe qual dos três inspecionar primeiro em vez de reiniciar a investigação.