Registros DNS de clientes VPN: propietario, TTL y limpieza son cosas distintas

Los portátiles se conectan, reciben una dirección VPN, y el nombre que resuelven otros sistemas sigue apuntando a la dirección de oficina de ayer. Nada falló: se asignó una dirección, no se actualizó un registro y una caché aún guarda la respuesta anterior. Son tres objetos con tres propietarios, y solo uno de ellos pertenece a la VPN. Planificar la publicación significa decidir quién escribe el nombre, qué interfaces participan y cuándo desaparecen los datos obsoletos.

El síntoma: un nombre que sigue a la dirección equivocada

Desde el dispositivo, el túnel está activo y la dirección VPN responde. Desde la estación de trabajo de un colega, el mismo nombre de host resuelve a una dirección privada que el dispositivo ya no tiene, así que la conexión agota el tiempo contra una máquina que se ha movido. El registro es autoritativo y erróneo, lo que es peor que ausente. Todos confían en él y nadie puede conectar.

El caso inverso es más silencioso: el registro desaparece y el nombre deja de resolverse por completo. Ambos resultados vienen del mismo hueco de diseño, y ninguno se corrige bajando el TTL. Una vida de caché más corta cambia cuánto sobrevive la respuesta equivocada, no si se escribe.

Empiece preguntando qué objeto está obsoleto. La dirección que asignó la VPN, el registro en la zona y la respuesta en la caché de un resolutor tienen vidas distintas y propietarios distintos.

Tres objetos, tres propietarios

La VPN posee la asignación de direcciones, y puede entregar la dirección desde un pool interno sin que ningún intercambio DHCP llegue al portátil. La zona DNS posee el registro, y su modelo de seguridad decide quién puede crearlo o modificarlo. La caché del resolutor posee la copia que un lector está usando ahora, y nada de lo que hace el dispositivo puede llegar a ella.

Suponer que un solo componente hace las tres cosas es donde se rompe el diseño. Una dirección que parece venir de un rango gestionado no demuestra que un servidor DHCP hiciera el registro, y un registro correcto no demuestra que los lectores hayan refrescado su caché.

Quién puede actualizar el registro

En una zona integrada con Active Directory y con actualizaciones dinámicas seguras, los permisos viven en el propio registro. Un registro creado por una cuenta de servicio DHCP puede no ser escribible por la cuenta de equipo del portátil, y cambiar el modelo de propiedad después es una transición, no un interruptor. Por eso un conflicto de propiedad sobrevive a cualquier ajuste del lado del cliente.

Las directrices de Microsoft sobre actualizaciones dinámicas favorecen el registro del lado del cliente para puntos de conexión híbridos unidos al dominio. Adoptarlo significa trasladar los registros existentes de forma deliberada, no solo marcar una casilla en el adaptador VPN y esperar que el propietario antiguo ceda.

Cuando un servicio DHCP debe registrar otras clases de dispositivos, dele el modelo de credenciales y permisos admitido para ese rol. Mantenga los registros directos e inversos en un mismo plan, porque a menudo los mantienen componentes distintos y uno de ellos suele olvidarse.

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

El primer comando muestra qué direcciones cree tener el dispositivo y si la conexión está configurada para registrarlas. El segundo y el tercero comparan lo que resuelve un cliente con lo que la zona almacena realmente, lo que separa un problema de caché de uno autoritativo.

Tres relojes, no uno

La publicación y la actualización es el primer reloj: cuándo el actualizador autorizado anuncia que una dirección cambió. El TTL de la caché es el segundo: cuánto tiempo un resolutor puede conservar la respuesta recibida. La limpieza autoritativa es el tercero: cómo se eliminan los registros obsoletos mediante el proceso de registro o mediante el envejecimiento y la exploración.

Estos relojes son independientes, y confundirlos produce correcciones que no funcionan. Un cambio en uno es invisible para los otros dos. Un TTL corto acorta la vida de una respuesta en caché y no concede ningún permiso de actualización. La exploración elimina registros que no se refrescaron, y no puede reparar un registro que nunca escribió el propietario correcto.

Fije el TTL según la rapidez con que los lectores deben ver un cambio, y la exploración según cuánto tiempo un dispositivo abandonado debe conservar un nombre. Ninguno de los dos números decide quién puede escribir el registro, y ningún valor de TTL convierte la asignación de direcciones en derechos de administración de DNS.

Planifique la publicación para un dispositivo itinerante

Decida qué interfaces participan en el registro. Una dirección Wi-Fi doméstica, una dirección VPN y una dirección de oficina antigua sirven a públicos distintos, y publicarlas todas produce un nombre con varias respuestas de utilidad desigual. Registre las interfaces que los lectores previstos pueden alcanzar de verdad.

Mantenga el nombre de equipo estable como identidad y trate las direcciones como atributos suyos. Conserve los registros de descubrimiento de dominio que el dispositivo necesita, y no desactive el registro por completo para resolver un problema de registros duplicados que un cambio de permisos arreglaría.

Escriba el asignador, el actualizador y el propietario de la limpieza en un solo registro, con los lectores previstos nombrados. Cuando el nombre vuelva a apuntar a la dirección equivocada, ese registro le dice cuál de los tres inspeccionar primero en lugar de reiniciar la investigación.