Waarom MagicDNS toestelle oplos, maar nie kantoor-gasheername nie

MagicDNS gee elke toestel in ’n tailnet ’n naam wat van sy masjiennaam en die tailnet se DNS-domein afgelei word. Daardie naam word deur Tailscale geskep en op Tailscale se oplosserpad beantwoord. ’n Kantoor-gasheernaam soos files.office.example behoort aan ’n sone wat Tailscale nooit geskryf het nie, so die hernoeming van ’n toestel kan dit nie skep nie. Die twee naamruimtes bestaan saam; hulle het bloot verskillende eienaars.

Daardie meganisme sit agter ’n baie algemene verslag: die Tailscale-gasheer antwoord, en die lêerbediener gee steeds ’n oplossingsfout terug.

Twee naamruimtes, twee eienaars

’n Toestelnaam word uit die masjien se eie gasheernaam geskep, botsings word deur Tailscale opgelos, en die resultaat woon onder die tailnet-domein. ’n Kantoorsone word onderhou deur wie die kantooroplosser ook al bestuur, met rekords wat deur ’n administrateur of deur dinamiese registrasie geskep word. Kort name verberg die verskil: files kan ’n soek-agtervoegsel-uitbreiding wees wat deur die kantoor-DNS beantwoord word, ’n tailnet-toestel, of glad niks. Die volle naam navraag wys watter stelsel werklik geantwoord het.

Die verandering van die masjiennaam van die subnet-router doen niks vir die kantoorsone nie. Dit hernoem een Tailscale-toestel en laat die rekord op die kantoorbediener onaangeraak, en daarom kom hernoem-en-probeer nooit tot ’n oplossing nie.

Rig die kantoorsone na sy oplosser

Tailscale se geskeide DNS stuur navrae vir gekose domeine na ’n naamdiens wat jy spesifiseer, en alles anders volg die oorblywende beleid. Voeg die domein by wat die kantooroplosser werklik bedien, nie die soek-agtervoegsel wat jy toevallig tik nie. ’n Soek-agtervoegsel sê vir die kliënt wat om by te voeg; dit sê nie vir die oplosser waar om te kyk nie. Daardie twee instellings lyk in ’n konsole soortgelyk en gedra hulle heeltemal anders.

’n Beperkte naamdiens moet gesaghebbend wees vir die domein wat daarmee geassosieer word, anders sal die antwoord ’n verwysing eerder as ’n adres wees.

Bereikbaarheid kom voor oplossing

Die kliënt moet ook daardie naamdiens bereik. Vir ’n oplosser op ’n private LAN moet die subnet-roete geadverteer en aanvaar word, die toegangsbeleid moet die navraag toelaat, en ’n terugpad moet bestaan. ’n Korrekte DNS-adres in die administrasiekonsole bewys slegs dat die konfigurasie gestoor is. As pakkette die oplosser nie kan bereik nie, is die simptoom ’n tydsverloop, wat anders lyk as ’n gesaghebbende antwoord dat geen sodanige rekord bestaan nie.

Daardie verskil is diagnosties. ’n Tydsverloop wys na roetering of beleid, terwyl ’n onmiddellike negatiewe antwoord na die rekord of die sone wys. Lees watter een jy kry voordat jy enige DNS-instelling verander.

Skei die naamfout van die diensfout

As die hulpbron by sy private adres reageer maar nie by gasheernaam nie, bly die ondersoek by DNS. As nie een van die twee werk nie, herstel eers roetering of die diens, want ’n naam wat na ’n onbereikbare adres oplos, is nie vordering nie. Vra die volle naam navraag en let op die bediener wat geantwoord het. Op macOS volg sommige opdragreël-gereedskap ’n ander pad as gewone toepassings, so ’n terminale dig en ’n blaaier kan oor dieselfde naam verskil.

Herhaal die toets met ’n uitgangsknoop gekies as dit die normale modus vir die toestel is. Die hantering van DNS by ’n uitgangsknoop verskil van die konfigurasie sonder uitgangsknoop, en om net in een modus te toets kan die fout mis wat gebruikers werklik sien.

Teken die sone, die oplosseradres en die roete wat die navraag dra, op. Daardie drie verduidelik die meeste MagicDNS-verrassings sonder nog ’n rondte hernoemings.