DNS-записи VPN-клиентов: владелец, TTL и очистка — разные вещи

Ноутбуки подключаются, получают адрес VPN, а имя, которое разрешают другие системы, всё ещё указывает на вчерашний адрес офиса. Ничего не сломалось: адрес был выделен, запись не обновлена, а кэш всё ещё хранит старый ответ. Это три объекта с тремя владельцами, и только один из них принадлежит VPN. Планировать публикацию — значит решать, кто пишет имя, какие интерфейсы участвуют и когда исчезают устаревшие данные.

Симптом: имя, которое следует за неверным адресом

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

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

Начните с вопроса, какой объект устарел. У адреса, выделенного VPN, записи в зоне и ответа в кэше резолвера разные сроки жизни и разные владельцы.

Три объекта, три владельца

VPN владеет выделением адресов и может выдать адрес из внутреннего пула, даже если обмен DHCP до ноутбука не доходит. Зона DNS владеет записью, и её модель безопасности решает, кто может её создать или изменить. Кэш резолвера владеет копией, которую читатель использует прямо сейчас, и ничто из того, что делает устройство, до неё не дотянется.

Предположение, что один компонент делает всё три, — это место, где проект ломается. Адрес, который выглядит пришедшим из управляемого диапазона, не доказывает, что регистрацию выполнил сервер DHCP, а успешная регистрация не доказывает, что читатели обновили кэш.

Кто может обновлять запись

В зоне, интегрированной с Active Directory и с безопасными динамическими обновлениями, разрешения живут на самой записи. Запись, созданная служебной учётной записью DHCP, может быть недоступна для записи учётной записью компьютера ноутбука, а смена модели владения позже — это переход, а не переключатель. Поэтому конфликт владения переживает любую настройку на стороне клиента.

Рекомендации Microsoft по динамическим обновлениям отдают предпочтение регистрации на стороне клиента для гибридных конечных точек в домене. Принять это — значит осознанно перенести существующие записи, а не просто поставить галочку на адаптере VPN и надеяться, что старый владелец уступит.

Там, где служба DHCP должна регистрировать другие классы устройств, дайте ей поддерживаемую модель учётных данных и разрешений для этой роли. Держите прямые и обратные записи в одном плане, потому что их часто обслуживают разные компоненты, и одну из них обычно забывают.

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

Первая команда показывает, какие адреса устройство считает своими и настроено ли подключение их регистрировать. Вторая и третья сравнивают то, что разрешает клиент, с тем, что зона действительно хранит, и это отделяет проблему кэша от авторитетной.

Трое часов, а не одни

Публикация и обновление — первые часы: когда уполномоченный обновляющий объявляет, что адрес изменился. TTL кэша — вторые: как долго резолвер может хранить полученный ответ. Авторитетная очистка — третьи: как устаревшие записи удаляются процессом регистрации или старением и очисткой.

Эти часы независимы, и их смешение даёт исправления, которые не работают. Изменение в одних невидимо для двух других. Короткий TTL сокращает жизнь кэшированного ответа и не даёт никаких прав на обновление. Очистка удаляет записи, которые не обновлялись, и не может починить запись, которую никогда не писал правильный владелец.

Задайте TTL по тому, как быстро читатели должны увидеть изменение, а очистку — по тому, как долго заброшенное устройство должно держать имя. Ни одно из этих чисел не решает, кому можно писать запись, и никакое значение TTL не превращает выделение адресов в права администрирования DNS.

Спланируйте публикацию для перемещающегося устройства

Решите, какие интерфейсы участвуют в регистрации. Домашний адрес Wi-Fi, адрес VPN и старый адрес офиса обслуживают разные аудитории, а публикация всех даёт имя с несколькими ответами неравной полезности. Регистрируйте интерфейсы, до которых предполагаемые читатели действительно могут добраться.

Держите стабильное имя компьютера как идентичность, а адреса рассматривайте как его атрибуты. Сохраняйте записи обнаружения домена, нужные устройству, и не отключайте регистрацию целиком, чтобы решить проблему дублирующихся записей, которую исправило бы изменение разрешений.

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