Hvorfor MagicDNS løser opp enheter, men ikke kontorvertsnavn

MagicDNS gir hver enhet i et tailnet et navn avledet av maskinnavnet og DNS-domenet til tailnettet. Det navnet opprettes av Tailscale, og det svares på langs resolverbanen til Tailscale. Et kontorvertsnavn som files.office.example tilhører en sone som Tailscale aldri skrev, så å gi en enhet nytt navn kan ikke opprette det. De to navnerommene eksisterer side om side; de har bare forskjellige eiere.

Den mekanismen ligger bak en svært vanlig rapport: Tailscale-verten svarer, og filserveren returnerer fortsatt en oppløsningsfeil.

To navnerom, to eiere

Et enhetsnavn genereres fra maskinens eget vertsnavn, kollisjoner løses av Tailscale, og resultatet bor under tailnet-domenet. En kontorsone vedlikeholdes av den som driver kontorets resolver, med poster opprettet av en administrator eller ved dynamisk registrering. Korte navn skjuler forskjellen: files kan være en utvidelse av søkesuffikset som kontorets DNS svarer på, en tailnet-enhet eller ingenting i det hele tatt. Forespørsel på hele navnet viser hvilket system som faktisk svarte.

Endring av maskinnavnet på subnettruteren gjør ingenting for kontorsonen. Den gir én Tailscale-enhet nytt navn og lar posten på kontorserveren være urørt, og derfor konvergerer aldri nytt navn og nytt forsøk.

Pek kontorsonen mot resolveren sin

Den delte DNS-en til Tailscale sender forespørsler for valgte domener til en navneserver du angir, og alt annet følger den gjenværende policyen. Legg til domenet som kontorets resolver faktisk betjener, ikke søkesuffikset du tilfeldigvis skriver. Et søkesuffiks forteller klienten hva som skal legges til; det forteller ikke resolveren hvor den skal se. Disse to innstillingene ser like ut i en konsoll og oppfører seg helt forskjellig.

En begrenset navneserver må være autoritativ for domenet som er knyttet til den, ellers blir svaret en henvisning i stedet for en adresse.

Tilgjengelighet kommer før oppløsning

Klienten må også nå den navneserveren. For en resolver på et privat LAN må subnett-ruten annonseres og aksepteres, tilgangspolicyen må tillate forespørselen, og det må finnes en returvei. En korrekt DNS-adresse i administrasjonskonsollen beviser bare at konfigurasjonen ble lagret. Hvis pakker ikke kan nå resolveren, er symptomet en tidsavbrudd, som ser annerledes ut enn et autoritativt svar om at det ikke finnes en slik post.

Den forskjellen er diagnostisk. En tidsavbrudd peker på ruting eller policy, mens et umiddelbart negativt svar peker på posten eller sonen. Les hvilken av dem du får før du endrer noen DNS-innstilling.

Skill navnefeilen fra tjenestefeilen

Hvis ressursen svarer på sin private adresse, men ikke på vertsnavn, holder undersøkelsen seg til DNS. Hvis ingen av dem virker, fiks først ruting eller tjenesten, fordi et navn som løses opp til en utilgjengelig adresse ikke er fremgang. Spør på hele navnet og noter hvilken server som svarte. På macOS tar noen kommandolinjeverktøy en annen vei enn vanlige programmer, så en terminal dig og en nettleser kan være uenige om samme navn.

Gjenta testen med en utgangsnode valgt hvis det er den normale modusen for enheten. DNS-håndteringen til en utgangsnode skiller seg fra konfigurasjonen uten utgangsnode, og testing i bare én modus kan overse feilen brukerne faktisk ser.

Noter sonen, resolveradressen og ruten som bærer forespørselen. Disse tre forklarer de fleste MagicDNS-overraskelser uten enda en runde med navnebytte.