Чому 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 без чергового кола перейменування.