Tailscale MagicDNS verkar, men nslookup feilar på macOS

På ein Mac løyser ping eit tailnet-maskinnamn medan nslookup returnerer ein feil, og begge kommandoane seier sanninga. Appar løyser via systemoppløysaren, som Tailscale konfigurerer per grensesnitt, medan nslookup og host les ei statisk fil som MagicDNS aldri rører. Dei to vegane kan vere usamde utan at ein einaste pakke går tapt. Avgjer kva veg den feilande applikasjonen din tok, før du endrar noka DNS-innstilling.

To oppløysingsvegar, to ulike svar

Apptrafikk på macOS går gjennom systemoppløysaren, og grensesnittbundne oppløysaroppføringar avgjer kva tenar som svarer for kva domene. Tailscale installerer si MagicDNS-oppføring der, og difor finn Safari og ssh tailnet-namn. nslookup, host og dig les i staden /etc/resolv.conf eller tek ein tenar på kommandolinja, og den fila nemner vanlegvis framleis rutaren eller ein kontortenar. Eit tailnet-namn sendt til den fila har ikkje noko autoritativt svar som ventar på det, så verktøyet rapporterer feil medan systemvegen lykkast.

Ingen av verktøya oppfører seg feil. Dei spør ulike tenarar, og berre éin av desse tenarane kjenner tailnettet ditt.

Test det same namnet gjennom systemvegen

Bruk systemets oppslagskall som den første testen, og samanlikn det deretter med ein førespurnad retta direkte mot MagicDNS-oppløysaren. Hald stavemåten identisk i begge, inkludert tailnet-domenet, fordi eit kort namn og eit fullt kvalifisert namn er ulike spørsmål med ulike svar.

dscacheutil -q host -a name nas-01.tailnet-a1b2.ts.net
scutil --dns
dig @100.100.100.100 nas-01.tailnet-a1b2.ts.net

Desse tre utdataa svarar på tre spørsmål: kva systemet returnerer, kva oppløysarar som er konfigurerte for kva domene, og kva MagicDNS sjølv veit. Eit namn som finst i det andre og tredje, men manglar i det første, peikar på lokal konfigurasjon og ikkje på tailnettet.

Når namnet er oppløyst, test tenesta

Eit korrekt DNS-svar beviser berre at eit namn peikar på ei adresse. Tenesta bak kan vere stoppa, porten kan vere filtrert av ein tilgangsregel, og eit sertifikat kan namngje ein annan vert enn den du skreiv.

nc -vz nas-01.tailnet-a1b2.ts.net 445
ping -c 3 nas-01.tailnet-a1b2.ts.net

Ta vare på den opphavlege feilteksten, fordi ei sertifikatåtvaring, eit tilkoplingsstidsavbrot og eit ikkje-funne namn fører kvar til noko ulikt. Å endre namnetenarar reparerer det tredje og kastar bort ein ettermiddag på dei to første.

MagicDNS erstattar ikkje kontor-DNS

Eit namn i ei kontorsone er ikkje eit tailnet-einingsnamn sjølv når den same klienten kan nå begge. Når målet ligg bak ein subnett-rutar, treng klienten split DNS for den sona som peikar på den interne oppløysaren, som er ei anna innstilling enn MagicDNS og er dokumentert ved sida av ho.

Søkjedomene betyr også noko. Eit ikkje-kvalifisert kort namn får kvart konfigurerte suffiks lagt til i rekkjefølgje, så ein berbar datamaskin som nyleg vart med i eit anna nettverk, kan løyse via eit utdatert suffiks. Sjekk kva suffiks som vart brukt, før du erklærer sona øydelagd.

Når begge vegane feilar, avgjer tailnet-fakta

Viss både systemoppslaget og den direkte førespurnaden feilar for ein eining du trur finst, ligg problemet over oppløysaren til Macen.

Stadfest maskinnamnet og tailnet-domenet i administrasjonskonsollen, stadfest at eininga er på nett og godkjend, og stadfest at DNS-innstillingane til klienten ikkje er deaktiverte lokalt. Ei eining som er fråkopla, behaldar namnet sitt og har rett og slett inga adresse å returnere.

Vel deretter ut frå bevis. Eit namn som løyser på systemvegen og feilar i nslookup, er ein skilnad i verktøyvegen; eit namn som løyser medan tenesta avviser, er eit tilgangs- eller sertifikatproblem; eit namn som ikkje løyser nokon stad, er eit tailnet- eller DNS-konfigurasjonsproblem. Tre eigarar, tre rettingar, og MagicDNS-dokumentasjonen dekkjer macOS-spesialitetane ved det første tilfellet.