Proč MagicDNS překládá zařízení, ale ne kancelářská jména hostitelů

MagicDNS přiděluje každému zařízení v tailnetu jméno odvozené z názvu jeho stroje a z DNS domény tailnetu. Toto jméno vytváří Tailscale a odpovídá se na něj po cestě resolveru Tailscale. Kancelářské jméno hostitele, například files.office.example, patří do zóny, kterou Tailscale nikdy nezapsal, takže přejmenování zařízení ho nemůže vytvořit. Oba jmenné prostory koexistují; prostě mají různé vlastníky.

Tento mechanismus stojí za velmi častou stížností: hostitel Tailscale odpovídá a souborový server stále vrací chybu překladu.

Dva jmenné prostory, dva vlastníci

Jméno zařízení se generuje z vlastního jména hostitele stroje, kolize řeší Tailscale a výsledek žije pod doménou tailnetu. Kancelářskou zónu spravuje ten, kdo provozuje kancelářský resolver, a záznamy vytváří správce nebo dynamická registrace. Krátká jména rozdíl skrývají: files může být rozšíření vyhledávací přípony, na které odpovídá kancelářský DNS, zařízení v tailnetu, nebo vůbec nic. Dotaz na plné jméno ukáže, který systém skutečně odpověděl.

Změna názvu stroje podsíťového routeru pro kancelářskou zónu nic neudělá. Přejmenuje jedno zařízení Tailscale a záznam na kancelářském serveru nechá nedotčený, proto přejmenování a opakování pokusu nikdy nekonverguje.

Nasměrujte kancelářskou zónu na její resolver

Rozdělený DNS v Tailscale posílá dotazy na vybrané domény na server jmen, který určíte, a vše ostatní se řídí zbývající politikou. Přidejte doménu, kterou kancelářský resolver skutečně obsluhuje, ne vyhledávací příponu, kterou náhodou napíšete. Vyhledávací přípona říká klientovi, co připojit; neříká resolveru, kam se dívat. Tato dvě nastavení vypadají v konzoli podobně a chovají se zcela odlišně.

Omezený server jmen musí být autoritativní pro doménu, s níž je spojen, jinak bude odpovědí odkaz, a ne adresa.

Dostupnost přichází před překladem

Klient se také musí k tomuto serveru jmen dostat. Pro resolver v soukromé LAN musí být trasa podsítě inzerována a přijata, přístupová politika musí dotaz povolit a musí existovat zpáteční cesta. Správná adresa DNS v administrační konzoli dokazuje jen to, že konfigurace byla uložena. Pokud pakety nemohou resolver dosáhnout, je příznakem časový limit, který vypadá jinak než autoritativní odpověď, že takový záznam neexistuje.

Tento rozdíl je diagnostický. Časový limit ukazuje na směrování nebo politiku, zatímco okamžitá negativní odpověď ukazuje na záznam nebo zónu. Přečtěte si, kterou z nich dostáváte, než změníte jakékoli nastavení DNS.

Oddělte selhání jména od selhání služby

Pokud zdroj odpovídá na své soukromé adrese, ale ne podle jména hostitele, vyšetřování zůstává u DNS. Pokud nefunguje ani jedno, opravte nejprve směrování nebo službu, protože jméno, které se překládá na nedostupnou adresu, není pokrok. Zeptejte se na plné jméno a poznamenejte si, který server odpověděl. V macOS některé nástroje příkazového řádku jdou jinou cestou než běžné aplikace, takže terminál dig a prohlížeč se mohou o stejném jménu rozcházet.

Zopakujte test s vybraným výstupním uzlem, pokud je to pro zařízení běžný režim. Zpracování DNS výstupního uzlu se liší od konfigurace bez výstupního uzlu a testování jen v jednom režimu může minout selhání, které uživatelé skutečně vidí.

Zapište zónu, adresu resolveru a trasu, která dotaz nese. Tyto tři věci vysvětlí většinu překvapení s MagicDNS bez dalšího kola přejmenovávání.