Hvorfor MagicDNS opløser enheder, men ikke kontorværtsnavne

MagicDNS giver hver enhed i en tailnet et navn, der er afledt af dens maskinnavn og tailnettets DNS-domæne. Det navn oprettes af Tailscale og besvares ad Tailscales resolversti. Et kontorværtsnavn som files.office.example tilhører en zone, som Tailscale aldrig har skrevet, så omdøbning af en enhed kan ikke oprette det. De to navnerum eksisterer side om side; de har bare forskellige ejere.

Den mekanisme ligger bag en meget almindelig rapport: Tailscale-værten svarer, og fileserveren returnerer stadig en opløsningsfejl.

To navnerum, to ejere

Et enhedsnavn genereres ud fra maskinens eget værtsnavn, kollisioner løses af Tailscale, og resultatet ligger under tailnet-domænet. En kontorzone vedligeholdes af den, der driver kontorets resolver, med poster oprettet af en administrator eller ved dynamisk registrering. Korte navne skjuler forskellen: files kan være en søge-suffiksudvidelse, som kontorets DNS svarer på, en tailnet-enhed eller slet intet. Forespørgsel på det fulde navn viser, hvilket system der faktisk svarede.

Ændring af maskinnavnet på subnet-routeren gør intet for kontorzonen. Den omdøber én Tailscale-enhed og lader posten på kontorserveren være urørt, og derfor konvergerer omdøb-og-prøv-igen aldrig.

Ret kontorzonen mod dens resolver

Tailscales opdelte DNS sender forespørgsler for udvalgte domæner til en navneserver, du angiver, og alt andet følger den resterende politik. Tilføj det domæne, som kontorets resolver faktisk betjener, ikke det søgesuffiks, du tilfældigvis skriver. Et søgesuffiks fortæller klienten, hvad der skal tilføjes; det fortæller ikke resolveren, hvor den skal kigge. De to indstillinger ser ens ud i en konsol og opfører sig helt forskelligt.

En begrænset navneserver skal være autoritativ for det domæne, der er knyttet til den, ellers bliver svaret en henvisning i stedet for en adresse.

Tilgængelighed kommer før opløsning

Klienten skal også kunne nå den navneserver. For en resolver på et privat LAN skal subnet-ruten annonceres og accepteres, adgangspolitikken skal tillade forespørgslen, og der skal findes en returvej. En korrekt DNS-adresse i administrationskonsollen beviser kun, at konfigurationen er gemt. Hvis pakker ikke kan nå resolveren, er symptomet en timeout, som ser anderledes ud end et autoritativt svar om, at der ikke findes en sådan post.

Forskellen er diagnostisk. En timeout peger på routing eller politik, mens et øjeblikkeligt negativt svar peger på posten eller zonen. Læs, hvilket af dem du får, før du ændrer nogen DNS-indstilling.

Adskil navnefejlen fra servicefejlen

Hvis ressourcen svarer på sin private adresse men ikke på værtsnavn, bliver undersøgelsen på DNS. Hvis ingen af delene virker, skal du først rette routing eller tjenesten, for et navn, der opløses til en utilgængelig adresse, er ikke fremskridt. Forespørg på det fulde navn, og noter hvilken server der svarede. På macOS tager nogle kommandolinjeværktøjer en anden vej end almindelige programmer, så en terminal dig og en browser kan være uenige om det samme navn.

Gentag testen med en exit-node valgt, hvis det er enhedens normale tilstand. DNS-håndtering på exit-noder adskiller sig fra konfigurationen uden exit-node, og test i kun én tilstand kan overse den fejl, brugerne faktisk ser.

Noter zonen, resolverens adresse og den rute, der bærer forespørgslen. De tre forklarer de fleste MagicDNS-overraskelser uden endnu en runde omdøbning.