Por que MagicDNS resolve dispositivos pero non nomes de host de oficina

MagicDNS dá a cada dispositivo dunha tailnet un nome derivado do nome da súa máquina e do dominio DNS da tailnet. Tailscale crea ese nome e respóndese pola ruta do resolutor de Tailscale. Un nome de host de oficina como files.office.example pertence a unha zona que Tailscale nunca escribiu, así que cambiar o nome dun dispositivo non pode crealo. Os dous espazos de nomes coexisten; simplemente teñen propietarios distintos.

Ese mecanismo está detrás dun informe moi común: o host de Tailscale responde e o servidor de ficheiros segue devolvendo un erro de resolución.

Dous espazos de nomes, dous propietarios

O nome dun dispositivo xérase a partir do nome de host da propia máquina, as colisións resólveas Tailscale e o resultado vive baixo o dominio da tailnet. A zona de oficina manténa quen administra o resolutor da oficina, con rexistros creados por un administrador ou por rexistro dinámico. Os nomes curtos ocultan a diferenza: files pode ser unha expansión de sufixo de busca que responde o DNS da oficina, un dispositivo da tailnet ou nada de nada. Consultar o nome completo mostra que sistema respondeu realmente.

Cambiar o nome de máquina do encamiñador de subrede non fai nada pola zona de oficina. Renomea un dispositivo de Tailscale e deixa intacto o rexistro do servidor de oficina, por iso renomear e reintentar nunca converxe.

Apunte a zona de oficina ao seu resolutor

O DNS dividido de Tailscale envía as consultas dos dominios elixidos a un servidor de nomes que vostede especifique, e todo o demais segue a política restante. Engada o dominio que o resolutor da oficina serve realmente, non o sufixo de busca que escriba por casualidade. Un sufixo de busca di ao cliente que engadir; non di ao resolutor onde mirar. Eses dous axustes parecen similares nunha consola e compórtanse de xeito completamente distinto.

Un servidor de nomes restrinxido debe ser autoritativo para o dominio asociado a el, ou a resposta será unha derivación en lugar dun enderezo.

A accesibilidade vai antes ca a resolución

O cliente tamén ten que chegar a ese servidor de nomes. Para un resolutor nunha LAN privada, a ruta da subrede debe anunciarse e aceptarse, a política de acceso debe permitir a consulta e debe existir un camiño de volta. Un enderezo DNS correcto na consola de administración só demostra que a configuración se gardou. Se os paquetes non poden chegar ao resolutor, o síntoma é un tempo de espera, que se ve distinto dunha resposta autoritativa de que non existe tal rexistro.

Esa diferenza é diagnóstica. Un tempo de espera apunta ao encamiñamento ou á política, mentres que unha resposta negativa inmediata apunta ao rexistro ou á zona. Lea cal obtén antes de cambiar calquera axuste de DNS.

Separe o fallo do nome do fallo do servizo

Se o recurso responde no seu enderezo privado pero non polo nome de host, a investigación queda en DNS. Se non funciona ningunha das dúas, corrixa primeiro o encamiñamento ou o servizo, porque un nome que resolve a un enderezo inalcanzable non é progreso. Consulte o nome completo e anote que servidor respondeu. En macOS algunhas ferramentas de liña de ordes seguen un camiño distinto do das aplicacións normais, así que un terminal dig e un navegador poden discrepar sobre o mesmo nome.

Repita a proba cun nodo de saída seleccionado se ese é o modo normal do dispositivo. O tratamento de DNS do nodo de saída difire da configuración sen nodo de saída, e probar só nun modo pode pasar por alto o fallo que os usuarios ven realmente.

Anote a zona, o enderezo do resolutor e a ruta que leva a consulta. Eses tres explican a maioría das sorpresas de MagicDNS sen outra rolda de renomeamentos.