De ce MagicDNS rezolvă dispozitivele, dar nu numele de gazdă ale biroului

MagicDNS dă fiecărui dispozitiv dintr-un tailnet un nume derivat din numele mașinii sale și din domeniul DNS al tailnetului. Acel nume este creat de Tailscale și se răspunde la el pe calea resolverului Tailscale. Un nume de gazdă de birou precum files.office.example aparține unei zone pe care Tailscale nu a scris-o niciodată, așa că redenumirea unui dispozitiv nu îl poate crea. Cele două spații de nume coexistă; pur și simplu au proprietari diferiți.

Acest mecanism stă în spatele unei raportări foarte frecvente: gazda Tailscale răspunde, iar serverul de fișiere returnează în continuare o eroare de rezolvare.

Două spații de nume, doi proprietari

Numele unui dispozitiv este generat din numele de gazdă al mașinii, coliziunile sunt rezolvate de Tailscale, iar rezultatul trăiește sub domeniul tailnetului. Zona biroului este întreținută de cel care administrează resolverul biroului, cu înregistrări create de un administrator sau prin înregistrare dinamică. Numele scurte ascund diferența: files poate fi o extindere a sufixului de căutare la care răspunde DNS-ul biroului, un dispozitiv din tailnet sau nimic. Interogarea numelui complet arată ce sistem a răspuns de fapt.

Schimbarea numelui mașinii routerului de subrețea nu face nimic pentru zona biroului. Redenumește un dispozitiv Tailscale și lasă neatinsă înregistrarea de pe serverul biroului, de aceea redenumirea și reîncercarea nu converg niciodată.

Îndreptați zona biroului spre resolverul ei

DNS-ul divizat al Tailscale trimite interogările pentru domeniile alese către un server de nume pe care îl specificați, iar tot restul urmează politica rămasă. Adăugați domeniul pe care resolverul biroului îl deservește cu adevărat, nu sufixul de căutare pe care îl tastați din întâmplare. Un sufix de căutare îi spune clientului ce să adauge; nu îi spune resolverului unde să se uite. Aceste două setări seamănă într-o consolă și se comportă complet diferit.

Un server de nume restricționat trebuie să fie autoritativ pentru domeniul asociat cu el, altfel răspunsul va fi o trimitere în loc de o adresă.

Accesibilitatea vine înaintea rezolvării

Clientul trebuie să ajungă și la acel server de nume. Pentru un resolver într-o LAN privată, ruta subrețelei trebuie anunțată și acceptată, politica de acces trebuie să permită interogarea, iar o cale de întoarcere trebuie să existe. O adresă DNS corectă în consola de administrare dovedește doar că s-a salvat configurația. Dacă pachetele nu pot ajunge la resolver, simptomul este un timeout, care arată diferit de un răspuns autoritativ că nu există o astfel de înregistrare.

Această diferență este diagnostică. Un timeout indică rutarea sau politica, în timp ce un răspuns negativ imediat indică înregistrarea sau zona. Citiți pe care îl primiți înainte de a schimba orice setare DNS.

Separați eșecul numelui de eșecul serviciului

Dacă resursa răspunde la adresa ei privată, dar nu la numele de gazdă, investigația rămâne la DNS. Dacă niciuna nu funcționează, reparați mai întâi rutarea sau serviciul, pentru că un nume care se rezolvă la o adresă inaccesibilă nu este progres. Interogați numele complet și notați ce server a răspuns. În macOS unele instrumente de linie de comandă urmează o cale diferită de aplicațiile obișnuite, așa că un terminal dig și un browser pot să nu fie de acord asupra aceluiași nume.

Repetați testul cu un nod de ieșire selectat dacă acesta este modul normal al dispozitivului. Gestionarea DNS a nodului de ieșire diferă de configurația fără nod de ieșire, iar testarea doar într-un singur mod poate rata eșecul pe care utilizatorii îl văd cu adevărat.

Notați zona, adresa resolverului și ruta care transportă interogarea. Aceste trei explică majoritatea surprizelor MagicDNS fără încă o rundă de redenumire.