Perché MagicDNS risolve i dispositivi ma non i nomi host dell’ufficio

MagicDNS assegna a ogni dispositivo di una tailnet un nome derivato dal nome della sua macchina e dal dominio DNS della tailnet. Quel nome è creato da Tailscale e vi si risponde lungo il percorso del resolver di Tailscale. Un nome host dell’ufficio come files.office.example appartiene a una zona che Tailscale non ha mai scritto, quindi rinominare un dispositivo non può crearlo. I due spazi dei nomi convivono; hanno semplicemente proprietari diversi.

Quel meccanismo sta dietro a una segnalazione molto comune: l’host Tailscale risponde e il file server restituisce ancora un errore di risoluzione.

Due spazi dei nomi, due proprietari

Il nome di un dispositivo è generato dal nome host della macchina stessa, le collisioni sono risolte da Tailscale e il risultato vive sotto il dominio della tailnet. La zona dell’ufficio è mantenuta da chi gestisce il resolver dell’ufficio, con record creati da un amministratore o dalla registrazione dinamica. I nomi brevi nascondono la differenza: files può essere un’espansione di suffisso di ricerca a cui risponde il DNS dell’ufficio, un dispositivo della tailnet, o nulla. Interrogare il nome completo mostra quale sistema ha risposto davvero.

Cambiare il nome macchina del router di sottorete non fa nulla per la zona dell’ufficio. Rinomina un dispositivo Tailscale e lascia intatto il record sul server dell’ufficio, per questo rinominare e riprovare non converge mai.

Punta la zona dell’ufficio al suo resolver

Il DNS diviso di Tailscale invia le query per i domini scelti a un server dei nomi che specifichi, e tutto il resto segue la politica rimanente. Aggiungi il dominio che il resolver dell’ufficio serve davvero, non il suffisso di ricerca che digiti per caso. Un suffisso di ricerca dice al client cosa aggiungere; non dice al resolver dove guardare. Queste due impostazioni sembrano simili in una console e si comportano in modo del tutto diverso.

Un server dei nomi limitato deve essere autoritativo per il dominio a esso associato, altrimenti la risposta sarà un rinvio invece di un indirizzo.

La raggiungibilità viene prima della risoluzione

Il client deve anche raggiungere quel server dei nomi. Per un resolver su una LAN privata, la route della sottorete deve essere annunciata e accettata, la politica di accesso deve consentire la query e deve esistere un percorso di ritorno. Un indirizzo DNS corretto nella console di amministrazione dimostra solo che la configurazione è stata salvata. Se i pacchetti non riescono a raggiungere il resolver, il sintomo è un timeout, che appare diverso da una risposta autoritativa secondo cui un tale record non esiste.

Questa differenza è diagnostica. Un timeout indica il routing o la politica, mentre una risposta negativa immediata indica il record o la zona. Leggi quale delle due ottieni prima di cambiare qualsiasi impostazione DNS.

Separa il guasto del nome dal guasto del servizio

Se la risorsa risponde al suo indirizzo privato ma non per nome host, l’indagine resta sul DNS. Se nessuno dei due funziona, correggi prima il routing o il servizio, perché un nome che risolve a un indirizzo irraggiungibile non è un progresso. Interroga il nome completo e annota quale server ha risposto. Su macOS alcuni strumenti da riga di comando seguono un percorso diverso dalle normali applicazioni, quindi un terminale dig e un browser possono non essere d’accordo sullo stesso nome.

Ripeti il test con un nodo di uscita selezionato se questa è la modalità normale del dispositivo. La gestione DNS del nodo di uscita differisce dalla configurazione senza nodo di uscita, e testare in una sola modalità può mancare il guasto che gli utenti vedono davvero.

Annota la zona, l’indirizzo del resolver e la route che trasporta la query. Questi tre spiegano la maggior parte delle sorprese di MagicDNS senza un altro giro di rinomine.