Защо 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 без пореден кръг преименуване.