Dlaczego MagicDNS rozwiązuje urządzenia, ale nie nazwy hostów biurowych

MagicDNS nadaje każdemu urządzeniu w tailnecie nazwę wyprowadzoną z nazwy jego maszyny i domeny DNS tailnetu. Ta nazwa jest tworzona przez Tailscale i odpowiada się na nią ścieżką resolvera Tailscale. Nazwa hosta biurowego, taka jak files.office.example, należy do strefy, której Tailscale nigdy nie zapisał, więc zmiana nazwy urządzenia nie może jej utworzyć. Obie przestrzenie nazw współistnieją; mają po prostu różnych właścicieli.

Ten mechanizm stoi za bardzo częstym zgłoszeniem: host Tailscale odpowiada, a serwer plików nadal zwraca błąd rozwiązywania.

Dwie przestrzenie nazw, dwóch właścicieli

Nazwa urządzenia jest generowana z własnej nazwy hosta maszyny, kolizje rozwiązuje Tailscale, a wynik żyje w domenie tailnetu. Strefą biurową zarządza ten, kto obsługuje resolver biura, a rekordy tworzy administrator lub rejestracja dynamiczna. Krótkie nazwy ukrywają różnicę: files może być rozszerzeniem sufiksu wyszukiwania, na które odpowiada biurowy DNS, urządzeniem tailnetu albo niczym. Zapytanie o pełną nazwę pokazuje, który system naprawdę odpowiedział.

Zmiana nazwy maszyny routera podsieci nie robi nic dla strefy biura. Zmienia nazwę jednego urządzenia Tailscale i pozostawia rekord na serwerze biurowym nietknięty, dlatego zmiana nazwy i ponowna próba nigdy się nie spotykają.

Skieruj strefę biurową do jej resolvera

Podzielony DNS Tailscale wysyła zapytania o wybrane domeny do wskazanego serwera nazw, a wszystko inne podlega pozostałej polityce. Dodaj domenę, której resolver biura naprawdę obsługuje, a nie sufiks wyszukiwania, który przypadkiem wpisujesz. Sufiks wyszukiwania mówi klientowi, co dołączyć; nie mówi resolverowi, gdzie szukać. Te dwa ustawienia wyglądają w konsoli podobnie i zachowują się zupełnie inaczej.

Ograniczony serwer nazw musi być autorytatywny dla powiązanej z nim domeny, inaczej odpowiedź będzie skierowaniem, a nie adresem.

Osiągalność przychodzi przed rozwiązywaniem

Klient musi także dotrzeć do tego serwera nazw. Dla resolvera w prywatnej sieci LAN trasa podsieci musi być ogłoszona i zaakceptowana, polityka dostępu musi zezwalać na zapytanie, a ścieżka powrotna musi istnieć. Prawidłowy adres DNS w konsoli administracyjnej dowodzi tylko, że konfiguracja została zapisana. Jeśli pakiety nie mogą dotrzeć do resolvera, objawem jest przekroczenie limitu czasu, które wygląda inaczej niż autorytatywna odpowiedź, że nie ma takiego rekordu.

Ta różnica jest diagnostyczna. Przekroczenie limitu czasu wskazuje na routing lub politykę, podczas gdy natychmiastowa odpowiedź negatywna wskazuje na rekord lub strefę. Przeczytaj, którą otrzymujesz, zanim zmienisz dowolne ustawienie DNS.

Oddziel awarię nazwy od awarii usługi

Jeśli zasób odpowiada pod swoim prywatnym adresem, ale nie pod nazwą hosta, dochodzenie pozostaje przy DNS. Jeśli żadne z nich nie działa, najpierw napraw routing lub usługę, ponieważ nazwa rozwiązująca się na nieosiągalny adres nie jest postępem. Zapytaj o pełną nazwę i zanotuj, który serwer odpowiedział. W systemie macOS niektóre narzędzia wiersza poleceń podążają inną ścieżką niż zwykłe aplikacje, więc terminal dig i przeglądarka mogą się nie zgadzać co do tej samej nazwy.

Powtórz test z wybranym węzłem wyjściowym, jeśli to normalny tryb urządzenia. Obsługa DNS węzła wyjściowego różni się od konfiguracji bez węzła wyjściowego, a testowanie tylko w jednym trybie może pominąć awarię, którą użytkownicy naprawdę widzą.

Zanotuj strefę, adres resolvera i trasę, która przenosi zapytanie. Te trzy wyjaśniają większość niespodzianek MagicDNS bez kolejnej rundy zmiany nazw.