Kvifor MagicDNS løyser opp einingar, men ikkje kontorvertsnamn

MagicDNS gir kvar eining i eit tailnet eit namn avleidd frå maskinnamnet og DNS-domenet til tailnettet. Det namnet blir oppretta av Tailscale, og det blir svart på langs resolvarbana til Tailscale. Eit kontorvertsnamn som files.office.example høyrer til ei sone som Tailscale aldri skreiv, så å gje ei eining nytt namn kan ikkje opprette det. Dei to namneromma finst side om side; dei har berre ulike eigarar.

Den mekanismen ligg bak ein svært vanleg rapport: Tailscale-verten svarar, og filserveren returnerer framleis ein oppløysingsfeil.

To namnerom, to eigarar

Eit einingnamn blir generert frå det eigne vertsnamnet til maskina, kollisjonar blir løyste av Tailscale, og resultatet bur under tailnet-domenet. Ei kontorsone blir vedlikehalden av den som driv kontorets resolvar, med postar oppretta av ein administrator eller ved dynamisk registrering. Korte namn skjuler skilnaden: files kan vere ei utviding av søkjesuffikset som kontorets DNS svarar på, ei tailnet-eining eller ingenting i det heile. Førespurnad på heile namnet viser kva system som faktisk svara.

Endring av maskinnamnet på subnett-rutaren gjer ingenting for kontorsona. Ho gir éi Tailscale-eining nytt namn og lèt posten på kontorserveren vere urørd, og difor konvergerer aldri nytt namn og nytt forsøk.

Pek kontorsona mot resolvaren sin

Den delte DNS-en til Tailscale sender førespurnader for valde domene til ein namneserver du oppgir, og alt anna følgjer den gjenverande policyen. Legg til domenet som kontorets resolvar faktisk betener, ikkje søkjesuffikset du tilfeldigvis skriv. Eit søkjesuffiks fortel klienten kva som skal leggjast til; det fortel ikkje resolvaren kvar han skal sjå. Desse to innstillingane ser like ut i ein konsoll og oppfører seg heilt ulikt.

Ein avgrensa namneserver må vere autoritativ for domenet som er knytt til han, elles blir svaret ei tilvising i staden for ei adresse.

Tilgjenge kjem før oppløysing

Klienten må òg nå den namneserveren. For ein resolvar på eit privat LAN må subnett-ruta annonserast og aksepterast, tilgangspolicyen må tillate førespurnaden, og det må finnast ein returveg. Ei korrekt DNS-adresse i administrasjonskonsollen beviser berre at konfigurasjonen vart lagra. Viss pakkar ikkje kan nå resolvaren, er symptomet eit tidsavbrot, som ser annleis ut enn eit autoritativt svar om at det ikkje finst ein slik post.

Den skilnaden er diagnostisk. Eit tidsavbrot peikar på rutingsval eller policy, medan eit umiddelbart negativt svar peikar på posten eller sona. Les kva du får før du endrar noka DNS-innstilling.

Skil namnefeilen frå tenestefeilen

Viss ressursen svarar på si private adresse, men ikkje på vertsnamn, held undersøkinga seg til DNS. Viss ingen av dei verkar, rett først rutinga eller tenesta, fordi eit namn som blir løyst opp til ei utilgjengeleg adresse ikkje er framgang. Spør på heile namnet og noter kva server som svara. På macOS tek nokre kommandolinjeverktøy ein annan veg enn vanlege program, så ein terminal dig og ein nettlesar kan vere usamde om same namnet.

Gjenta testen med ein utgangsnode vald viss det er den normale modusen for eininga. DNS-handteringa til ein utgangsnode skil seg frå konfigurasjonen utan utgangsnode, og testing i berre éin modus kan oversjå feilen brukarane faktisk ser.

Noter sona, resolvaradressa og ruta som ber førespurnaden. Desse tre forklarer dei fleste MagicDNS-overraskingane utan endå ein runde med namnebyte.