Varför MagicDNS löser enheter men inte kontorsvärdnamn

MagicDNS ger varje enhet i ett tailnet ett namn som härleds från dess maskinnamn och tailnets DNS-domän. Namnet skapas av Tailscale och besvaras längs Tailscales resolverväg. Ett kontorsvärdnamn som files.office.example tillhör en zon som Tailscale aldrig skrev, så att byta namn på en enhet kan inte skapa det. De två namnrymderna samexisterar; de har bara olika ägare.

Den mekanismen ligger bakom en mycket vanlig rapport: Tailscale-värden svarar, och filservern returnerar fortfarande ett upplösningsfel.

Två namnrymder, två ägare

Ett enhetsnamn genereras från maskinens eget värdnamn, kollisioner löses av Tailscale, och resultatet lever under tailnet-domänen. En kontorszon underhålls av den som driver kontorets resolver, med poster som skapas av en administratör eller genom dynamisk registrering. Korta namn döljer skillnaden: files kan vara en utökning av söksuffixet som kontorets DNS svarar på, en tailnet-enhet eller ingenting alls. En fråga på hela namnet visar vilket system som faktiskt svarade.

Ändring av maskinnamnet på undernätsroutern gör ingenting för kontorszonen. Den byter namn på en Tailscale-enhet och lämnar posten på kontorsservern orörd, och därför möts aldrig namnbyte och nytt försök.

Rikta kontorszonen mot dess resolver

Tailscales delade DNS skickar frågor för valda domäner till en namnserver som du anger, och allt annat följer den återstående policyn. Lägg till den domän som kontorets resolver faktiskt betjänar, inte det söksuffix du råkar skriva. Ett söksuffix talar om för klienten vad som ska läggas till; det talar inte om för resolvern var den ska titta. Dessa två inställningar ser likadana ut i en konsol och beter sig helt olika.

En begränsad namnserver måste vara auktoritativ för den domän som är kopplad till den, annars blir svaret en hänvisning i stället för en adress.

Nåbarhet kommer före upplösning

Klienten måste också nå den namnservern. För en resolver på ett privat LAN måste undernätsrutten annonseras och accepteras, åtkomstpolicyn måste tillåta frågan, och det måste finnas en returväg. En korrekt DNS-adress i administrationskonsolen bevisar bara att konfigurationen sparades. Om paketen inte kan nå resolvern är symtomet en timeout, som ser annorlunda ut än ett auktoritativt svar att det inte finns någon sådan post.

Den skillnaden är diagnostisk. En timeout pekar på routing eller policy, medan ett omedelbart negativt svar pekar på posten eller zonen. Läs vilket du får innan du ändrar någon DNS-inställning.

Separera namnfelt från tjänstefelt

Om resursen svarar på sin privata adress men inte på värdnamn stannar utredningen vid DNS. Om ingen av dem fungerar, åtgärda först routing eller tjänsten, eftersom ett namn som löses till en onåbar adress inte är framsteg. Fråga på hela namnet och notera vilken server som svarade. På macOS tar vissa kommandoradsverktyg en annan väg än vanliga program, så en terminal dig och en webbläsare kan vara oeniga om samma namn.

Upprepa testet med en vald utgångsnod om det är enhetens normala läge. DNS-hanteringen för en utgångsnod skiljer sig från konfigurationen utan utgångsnod, och test i bara ett läge kan missa det fel som användarna faktiskt ser.

Notera zonen, resolverns adress och rutten som bär frågan. Dessa tre förklarar de flesta MagicDNS-överraskningar utan ännu en omgång namnbyten.