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 і стара адреса офісу обслуговують різні аудиторії, а публікація всіх дає ім’я з кількома відповідями нерівної корисності. Реєструйте інтерфейси, до яких передбачені читачі справді можуть дістатися.

Тримайте стабільне ім’я комп’ютера як ідентичність, а адреси розглядайте як його атрибути. Зберігайте записи виявлення домену, потрібні пристрою, і не вимикайте реєстрацію цілком, щоб розв’язати проблему дубльованих записів, яку виправила б зміна дозволів.

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