Per què MagicDNS resol dispositius però no noms d’amfitrió d’oficina

MagicDNS dona a cada dispositiu d’una tailnet un nom derivat del nom de la seva màquina i del domini DNS de la tailnet. Aquest nom el crea Tailscale i es respon pel camí del resolutor de Tailscale. Un nom d’amfitrió d’oficina com files.office.example pertany a una zona que Tailscale mai no va escriure, així que canviar el nom d’un dispositiu no el pot crear. Els dos espais de noms coexisteixen; simplement tenen propietaris diferents.

Aquest mecanisme hi ha darrere d’una queixa molt habitual: l’amfitrió de Tailscale respon, i el servidor de fitxers encara retorna un error de resolució.

Dos espais de noms, dos propietaris

El nom d’un dispositiu es genera a partir del nom d’amfitrió de la màquina, les col·lisions les resol Tailscale, i el resultat viu sota el domini de la tailnet. La zona d’oficina la manté qui gestiona el resolutor de l’oficina, amb registres creats per un administrador o per registre dinàmic. Els noms curts amaguen la diferència: files pot ser una expansió de sufix de cerca que respon el DNS de l’oficina, un dispositiu de la tailnet o res de res. Consultar el nom complet mostra quin sistema ha respost realment.

Canviar el nom de màquina de l’encaminador de subxarxa no fa res per a la zona d’oficina. Reanomena un dispositiu de Tailscale i deixa el registre del servidor d’oficina intacte, i per això reanomenar i tornar-ho a provar mai no convergeix.

Apunteu la zona d’oficina al seu resolutor

El DNS dividit de Tailscale envia les consultes dels dominis triats a un servidor de noms que especifiqueu, i tota la resta segueix la política restant. Afegiu el domini que el resolutor de l’oficina serveix realment, no el sufix de cerca que escriviu per casualitat. Un sufix de cerca diu al client què ha d’afegir; no diu al resolutor on ha de mirar. Aquests dos paràmetres semblen similars en una consola i es comporten de manera completament diferent.

Un servidor de noms restringit ha de ser autoritatiu per al domini que hi està associat, o la resposta serà una derivació en lloc d’una adreça.

L’abastabilitat va abans de la resolució

El client també ha d’arribar a aquest servidor de noms. Per a un resolutor en una LAN privada, la ruta de la subxarxa s’ha d’anunciar i acceptar, la política d’accés ha de permetre la consulta i ha d’existir un camí de tornada. Una adreça DNS correcta a la consola d’administració només demostra que la configuració s’ha desat. Si els paquets no poden arribar al resolutor, el símptoma és un temps d’espera, que es veu diferent d’una resposta autoritativa de no hi ha aquest registre.

Aquesta diferència és diagnòstica. Un temps d’espera assenyala l’encaminament o la política, mentre que una resposta negativa immediata assenyala el registre o la zona. Llegiu quina obteniu abans de canviar cap paràmetre de DNS.

Separeu la fallada del nom de la fallada del servei

Si el recurs respon a la seva adreça privada però no pel nom d’amfitrió, la investigació es queda al DNS. Si no funciona cap de les dues, arregleu primer l’encaminament o el servei, perquè un nom que resol a una adreça inabastable no és cap progrés. Consulteu el nom complet i anoteu quin servidor ha respost. A macOS algunes eines de línia d’ordres segueixen un camí diferent del de les aplicacions ordinàries, així que un terminal dig i un navegador poden discrepar sobre el mateix nom.

Repetiu la prova amb un node de sortida seleccionat si aquest és el mode normal del dispositiu. El tractament del DNS del node de sortida difereix de la configuració sense node de sortida, i provar només en un mode pot deixar escapar la fallada que els usuaris veuen realment.

Anoteu la zona, l’adreça del resolutor i la ruta que porta la consulta. Aquests tres expliquen la majoria de sorpreses de MagicDNS sense una altra ronda de reanomenaments.