Почему MagicDNS разрешает устройства, но не имена офисных узлов

MagicDNS даёт каждому устройству в tailnet имя, образованное от имени его машины и DNS-домена tailnet. Это имя создаёт Tailscale, и ответ на него идёт по пути резолвера Tailscale. Офисное имя узла, например files.office.example, принадлежит зоне, которую Tailscale никогда не записывал, поэтому переименование устройства не может его создать. Два пространства имён сосуществуют; просто у них разные владельцы.

Этот механизм стоит за очень частой жалобой: узел Tailscale отвечает, а файловый сервер всё равно возвращает ошибку разрешения.

Два пространства имён, два владельца

Имя устройства генерируется из собственного имени узла машины, коллизии разрешает Tailscale, а результат живёт под доменом tailnet. Офисную зону поддерживает тот, кто управляет офисным резолвером, а записи создаёт администратор или динамическая регистрация. Короткие имена скрывают разницу: files может быть расширением поискового суффикса, на которое отвечает офисный DNS, устройством в tailnet или вообще ничем. Запрос по полному имени показывает, какая система действительно ответила.

Смена имени машины маршрутизатора подсети ничего не делает для офисной зоны. Она переименовывает одно устройство Tailscale и оставляет запись на офисном сервере нетронутой, поэтому переименование и повторная попытка никогда не сходятся.

Направьте офисную зону на её резолвер

Раздельный DNS Tailscale отправляет запросы для выбранных доменов на указанный вами сервер имён, а всё остальное следует оставшейся политике. Добавьте домен, который офисный резолвер действительно обслуживает, а не поисковый суффикс, который вы случайно вводите. Поисковый суффикс говорит клиенту, что дописать; он не говорит резолверу, где искать. Эти две настройки похожи в консоли и ведут себя совершенно по-разному.

Ограниченный сервер имён должен быть авторитетным для связанного с ним домена, иначе ответом будет пересылка, а не адрес.

Доступность идёт прежде разрешения

Клиент также должен достигать этого сервера имён. Для резолвера в частной LAN маршрут подсети должен быть анонсирован и принят, политика доступа должна разрешать запрос, и должен существовать обратный путь. Правильный DNS-адрес в консоли администратора доказывает лишь то, что конфигурация сохранена. Если пакеты не могут достичь резолвера, симптом — тайм-аут, который выглядит иначе, чем авторитетный ответ об отсутствии такой записи.

Эта разница диагностична. Тайм-аут указывает на маршрутизацию или политику, тогда как немедленный отрицательный ответ указывает на запись или зону. Прочитайте, какой из них вы получаете, прежде чем менять любую настройку DNS.

Отделите отказ имени от отказа службы

Если ресурс отвечает по своему частному адресу, но не по имени узла, расследование остаётся в DNS. Если не работает ни то, ни другое, сначала исправьте маршрутизацию или службу, потому что имя, разрешающееся в недоступный адрес, не является прогрессом. Запросите полное имя и отметьте, какой сервер ответил. В macOS некоторые инструменты командной строки идут другим путём, чем обычные приложения, поэтому терминал dig и браузер могут расходиться насчёт одного и того же имени.

Повторите тест с выбранным выходным узлом, если это обычный режим для устройства. Обработка DNS выходного узла отличается от конфигурации без выходного узла, и тестирование только в одном режиме может пропустить сбой, который пользователи действительно видят.

Запишите зону, адрес резолвера и маршрут, по которому идёт запрос. Эти три объясняют большинство сюрпризов MagicDNS без очередного круга переименования.