Rexistros DNS dos clientes VPN: propietario, TTL e limpeza son cousas distintas
Un enderezo VPN, un rexistro DNS e unha entrada de caché teñen propietarios distintos: decida quen pode publicar o nome, que interfaces se rexistran e cando caducan os rexistros.
Os portátiles conéctanse, reciben un enderezo VPN, e o nome que resolven outros sistemas segue apuntando ao enderezo de oficina de onte. Nada fallou: asignouse un enderezo, non se actualizou un rexistro e unha caché aínda garda a resposta antiga. Son tres obxectos con tres propietarios, e só un deles pertence á VPN. Planificar a publicación significa decidir quen escribe o nome, que interfaces participan e cando desaparecen os datos obsoletos.
O síntoma: un nome que segue o enderezo equivocado
Desde o dispositivo, o túnel está activo e o enderezo VPN responde. Desde a estación de traballo dun compañeiro, o mesmo nome de host resolve nun enderezo privado que o dispositivo xa non ten, así que a conexión esgota o tempo contra unha máquina que se moveu. O rexistro é autoritativo e erróneo, o que é peor que ausente. Todos confían nel e ninguén pode conectar.
O caso inverso é máis silencioso: o rexistro desaparece e o nome deixa de resolverse por completo. Ambos os resultados veñen do mesmo oco de deseño, e ningún se corrixe baixando o TTL. Unha vida de caché máis curta cambia canto sobrevive a resposta equivocada, non se se escribe.
Comece preguntando que obxecto está obsoleto. O enderezo que asignou a VPN, o rexistro na zona e a resposta na caché dun resolvedor teñen vidas distintas e propietarios distintos.
Tres obxectos, tres propietarios
A VPN posúe a asignación de enderezos, e pode entregar o enderezo desde un pool interno sen que ningún intercambio DHCP chegue ao portátil. A zona DNS posúe o rexistro, e o seu modelo de seguridade decide quen pode crealo ou modificalo. A caché do resolvedor posúe a copia que un lector está a usar agora, e nada do que fai o dispositivo pode chegar a ela.
Supor que un só compoñente fai as tres cousas é onde se rompe o deseño. Un enderezo que parece vir dun rango xestionado non demostra que un servidor DHCP fixese o rexistro, e un rexistro correcto non demostra que os lectores refrescasen a súa caché.
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
Quen pode actualizar o rexistro
Nunha zona integrada con Active Directory e con actualizacións dinámicas seguras, os permisos viven no propio rexistro. Un rexistro creado por unha conta de servizo DHCP pode non ser escribible pola conta de equipo do portátil, e cambiar o modelo de propiedade despois é unha transición, non un interruptor. Por iso un conflito de propiedade sobrevive a calquera axuste do lado do cliente.
As directrices de Microsoft sobre actualizacións dinámicas favorecen o rexistro do lado do cliente para puntos de conexión híbridos unidos ao dominio. Adoptalo significa trasladar os rexistros existentes de forma deliberada, non só marcar unha casilla no adaptador VPN e esperar que o propietario antigo ceda.
Cando un servizo DHCP debe rexistrar outras clases de dispositivos, déalle o modelo de credenciais e permisos admitido para ese rol. Manteña os rexistros directos e inversos nun mesmo plan, porque a miúdo mantéños compoñentes distintos e un deles adoita esquecerse.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042O primeiro comando mostra que enderezos cre ter o dispositivo e se a conexión está configurada para rexistralos. O segundo e o terceiro comparan o que resolve un cliente co que a zona almacena realmente, o que separa un problema de caché dun autoritativo.
Tres reloxos, non un
A publicación e a actualización é o primeiro reloxo: cando o actualizador autorizado anuncia que un enderezo cambiou. O TTL da caché é o segundo: canto tempo un resolvedor pode conservar a resposta recibida. A limpeza autoritativa é o terceiro: como se eliminan os rexistros obsoletos mediante o proceso de rexistro ou mediante o envellecemento e a exploración.
Estes reloxos son independentes, e confundilos produce correccións que non funcionan. Un cambio nun é invisible para os outros dous. Un TTL curto acurta a vida dunha resposta en caché e non concede ningún permiso de actualización. A exploración elimina rexistros que non se refrescaron, e non pode reparar un rexistro que nunca escribiu o propietario correcto.
Fixe o TTL segundo a rapidez con que os lectores deben ver un cambio, e a exploración segundo canto tempo un dispositivo abandonado debe conservar un nome. Ningún dos dous números decide quen pode escribir o rexistro, e ningún valor de TTL converte a asignación de enderezos en dereitos de administración de DNS.
Planifique a publicación para un dispositivo itinerante
Decida que interfaces participan no rexistro. Un enderezo Wi-Fi doméstico, un enderezo VPN e un enderezo de oficina antigo serven a públicos distintos, e publicalos todos produce un nome con varias respostas de utilidade desigual. Registre as interfaces que os lectores previstos poden alcanzar de verdade.
Manteña o nome de equipo estable como identidade e trate os enderezos como atributos seus. Conserve os rexistros de descubrimento de dominio que o dispositivo necesita, e non desactive o rexistro por completo para resolver un problema de rexistros duplicados que un cambio de permisos arranxaría.
Escriba o asignador, o actualizador e o propietario da limpeza nun só rexistro, cos lectores previstos nomeados. Cando o nome volva apuntar ao enderezo equivocado, ese rexistro dille cal dos tres inspeccionar primeiro en lugar de reiniciar a investigación.