Por qué MagicDNS resuelve dispositivos pero no nombres de host de oficina

MagicDNS da a cada dispositivo de una tailnet un nombre derivado del nombre de su máquina y del dominio DNS de la tailnet. Tailscale crea ese nombre y se responde por la ruta del resolutor de Tailscale. Un nombre de host de oficina como files.office.example pertenece a una zona que Tailscale nunca escribió, así que cambiar el nombre de un dispositivo no puede crearlo. Los dos espacios de nombres coexisten; sencillamente tienen propietarios distintos.

Ese mecanismo está detrás de un informe muy común: el host de Tailscale responde y el servidor de archivos sigue devolviendo un error de resolución.

Dos espacios de nombres, dos propietarios

El nombre de un dispositivo se genera a partir del nombre de host de la propia máquina, las colisiones las resuelve Tailscale y el resultado vive bajo el dominio de la tailnet. La zona de oficina la mantiene quien administra el resolutor de la oficina, con registros creados por un administrador o por registro dinámico. Los nombres cortos ocultan la diferencia: files puede ser una expansión de sufijo de búsqueda que responde el DNS de la oficina, un dispositivo de la tailnet o nada en absoluto. Consultar el nombre completo muestra qué sistema respondió realmente.

Cambiar el nombre de máquina del enrutador de subred no hace nada por la zona de oficina. Renombra un dispositivo de Tailscale y deja intacto el registro del servidor de oficina, por eso renombrar y reintentar nunca converge.

Apunte la zona de oficina a su resolutor

El DNS dividido de Tailscale envía las consultas de los dominios elegidos a un servidor de nombres que usted especifique, y todo lo demás sigue la política restante. Añada el dominio que el resolutor de la oficina sirve realmente, no el sufijo de búsqueda que escriba por casualidad. Un sufijo de búsqueda dice al cliente qué añadir; no dice al resolutor dónde mirar. Esos dos ajustes se parecen en una consola y se comportan de forma completamente distinta.

Un servidor de nombres restringido debe ser autoritativo para el dominio asociado a él, o la respuesta será una derivación en lugar de una dirección.

La accesibilidad va antes que la resolución

El cliente también tiene que llegar a ese servidor de nombres. Para un resolutor en una LAN privada, la ruta de la subred debe anunciarse y aceptarse, la política de acceso debe permitir la consulta y debe existir un camino de vuelta. Una dirección DNS correcta en la consola de administración solo demuestra que la configuración se guardó. Si los paquetes no pueden llegar al resolutor, el síntoma es un tiempo de espera, que se ve distinto de una respuesta autoritativa de que no existe tal registro.

Esa diferencia es diagnóstica. Un tiempo de espera apunta al enrutamiento o a la política, mientras que una respuesta negativa inmediata apunta al registro o a la zona. Lea cuál obtiene antes de cambiar cualquier ajuste de DNS.

Separe el fallo del nombre del fallo del servicio

Si el recurso responde en su dirección privada pero no por nombre de host, la investigación se queda en DNS. Si no funciona ninguna de las dos, corrija primero el enrutamiento o el servicio, porque un nombre que resuelve a una dirección inalcanzable no es progreso. Consulte el nombre completo y anote qué servidor respondió. En macOS algunas herramientas de línea de comandos siguen un camino distinto del de las aplicaciones normales, así que un terminal dig y un navegador pueden discrepar sobre el mismo nombre.

Repita la prueba con un nodo de salida seleccionado si ese es el modo normal del dispositivo. El manejo de DNS del nodo de salida difiere de la configuración sin nodo de salida, y probar solo en un modo puede pasar por alto el fallo que los usuarios ven realmente.

Anote la zona, la dirección del resolutor y la ruta que transporta la consulta. Esas tres cosas explican la mayoría de las sorpresas de MagicDNS sin otra ronda de cambios de nombre.