Tailscale MagicDNS fungerar, men nslookup misslyckas på macOS

På en Mac löser ping ett tailnet-maskinnamn medan nslookup returnerar ett fel, och båda kommandona talar sanning. Appar löser via systemets resolver, som Tailscale konfigurerar per gränssnitt, medan nslookup och host läser en statisk fil som MagicDNS aldrig rör. De två vägarna kan skilja sig utan att en enda paket går förlorad. Bestäm vilken väg din misslyckade app tog innan du ändrar någon DNS-inställning.

Två upplösningsvägar, två olika svar

Apptrafik på macOS går via systemets resolver, och gränssnittsbegränsade resolverposter avgör vilken server som svarar för vilken domän. Tailscale installerar sin MagicDNS-post där, därför hittar Safari och ssh tailnet-namn. nslookup, host och dig läser i stället /etc/resolv.conf eller tar en server på kommandoraden, och den filen namnger vanligtvis fortfarande routern eller en kontorsserver. Ett tailnet-namn som skickas till den filen har inget auktoritativt svar som väntar på det, så verktyget rapporterar fel medan systemvägen lyckas.

Inget av verktygen beter sig fel. De frågar olika servrar, och bara en av dessa servrar känner till ditt tailnet.

Testa samma namn via systemvägen

Använd systemets uppslagningsanrop som första test och jämför det sedan med en fråga som riktas direkt mot MagicDNS-resolvern. Håll stavningen identisk i båda, inklusive tailnet-domänen, eftersom ett kort namn och ett fullt kvalificerat namn är olika frågor med olika 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

Dessa tre utdata svarar på tre frågor: vad systemet returnerar, vilka resolvers som är konfigurerade för vilka domäner, och vad MagicDNS självt vet. Ett namn som finns i det andra och tredje men saknas i det första pekar på lokal konfiguration och inte på tailnet.

När namnet har lösts, testa tjänsten

Ett korrekt DNS-svar bevisar bara att ett namn pekar på en adress. Tjänsten bakom kan vara stoppad, porten kan filtreras av en åtkomstregel, och ett certifikat kan namnge en annan värd än den du skrev.

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

Behåll den ursprungliga feltexten, eftersom en certifikatvarning, en anslutningstimeout och ett namn som inte hittades leder var och en någon annanstans. Att byta namnservrar reparerar den tredje och slösar bort en eftermiddag på de två första.

MagicDNS ersätter inte kontors-DNS

Ett namn i en kontorszon är inte ett tailnet-enhetsnamn även när samma klient kan nå båda. När destinationen ligger bakom en subnätrouter, behöver klienten split DNS för den zonen som pekar på den interna resolvern, vilket är en annan inställning än MagicDNS och dokumenteras bredvid den.

Sökdomäner spelar också roll. Ett icke-kvalificerat kort namn får varje konfigurerat suffix tillagt i ordning, så en bärbar dator som nyligen anslöt till ett annat nätverk kan lösa via ett föråldrat suffix. Kontrollera vilket suffix som användes innan du förklarar zonen trasig.

När båda vägarna misslyckas avgör tailnet-fakta

Om både systemuppslagningen och den direkta frågan misslyckas för en enhet du tror finns, ligger problemet ovanför Macens resolver.

Bekräfta maskinnamnet och tailnet-domänen i administrationskonsolen, bekräfta att enheten är online och godkänd, och bekräfta att klientens DNS-inställningar inte har inaktiverats lokalt. En enhet som är offline behåller sitt namn och har helt enkelt ingen adress att returnera.

Välj sedan utifrån bevis. Ett namn som löses på systemvägen och misslyckas i nslookup är en skillnad i verktygsväg; ett namn som löses medan tjänsten vägrar är ett åtkomst- eller certifikatproblem; ett namn som inte löses någonstans är ett tailnet- eller DNS-konfigurationsproblem. Tre ägare, tre rättelser, och MagicDNS-dokumentationen täcker macOS-särdragen för det första fallet.