Внутрішній сервіс працює не для всіх: як упорядкувати приватний DNS без ризикованого перемикання

Коли «перепідключи VPN» допомагає лише випадково

Робочий ранок починається зі скарги: внутрішній застосунок не відкривається. В одних колег він працює, в інших завершується тайм-аутом. Після перепідключення VPN проблема іноді зникає, але ніхто не може пояснити чому.

Це швидко перетворюється на виснажливий пошук винного між мережею, VPN, хмарою та самим застосунком. Проте сервіс може бути справним. Розбіжність часто виникає раніше: клієнти надсилають однаковий DNS-запит різними маршрутами й отримують різні адреси.

Не починайте з масового очищення кешу або заміни всіх резолверів. Спочатку простежте один невдалий запит. Це покаже, де саме очікувана відповідь змінилася, зникла або потрапила не до тієї групи користувачів.

Простежте шлях одного запиту

Візьміть ім’я проблемного сервісу та два пристрої: один, на якому все працює, і один із помилкою. Для кожного зафіксуйте мережу, стан VPN, налаштований рекурсивний резолвер, отриману відповідь, TTL і час перевірки.

Далі визначте, куди резолвер передав запит. Це може бути приватна авторитетна зона в офісі, окрема зона в хмарі або публічний DNS. Якщо однакове ім’я повертає різні адреси, перевірте, чи це запланований split-horizon DNS, чи випадковий наслідок двох незалежних конфігурацій.

Корисно намалювати просту карту:

клієнт → офіс або VPN → рекурсивний резолвер → правило маршрутизації → авторитетна зона → відповідь

Додайте до неї хмарні мережі, запасні резолвери й публічний DNS. Схема має показувати не назви продуктів, а реальні шляхи запиту.

Знайдіть конфлікти та приховані правила

Зберіть перелік приватних і публічних зон. Для кожної вкажіть власника, місце редагування, сервери публікації та групи клієнтів, які повинні її бачити. Потім порівняйте записи однакових імен.

Особливо небезпечні три ситуації:

• одна зона вручну підтримується в офісі та хмарі;
• старий резолвер має неописане правило лише для VPN;
• приватне ім’я відсутнє у внутрішній зоні, тому запит несподівано йде в публічний DNS.

DNS view має бути явним рішенням, а не побічним ефектом топології. Наприклад, офісні пристрої та керовані VPN-клієнти можуть отримувати приватну адресу, а зовнішні клієнти — публічну. Запишіть, за якою ознакою вибирається кожна DNS view і яке правило має пріоритет у разі збігу.

Створіть єдиний шлях внесення змін

Головна причина дрейфу — не кількість DNS-серверів, а кількість місць, де люди незалежно змінюють той самий запис. У цільовій схемі має бути одне контрольоване джерело змін. З нього записи можуть публікуватися до кількох зон або середовищ, але ручне паралельне редагування слід припинити.

Оголошення Cloudflare про Internal DNS показує один сучасний варіант реалізації: окремі рекурсивні й авторитетні ролі, внутрішні зони, DNS views та політики маршрутизації. Це приклад, а не обов’язкова платформа. Ті самі питання потрібно розв’язати в будь-якому продукті: хто приймає запит, яка зона відповідає, яке правило вибирає відповідь і що відбувається, коли внутрішнього збігу немає.

Резервний перехід до публічного DNS не варто вмикати безумовно. Для кожної приватної зони визначте, чи допустима публічна відповідь. Помилка в приватному імені не повинна непомітно перетворюватися на зовнішній запит.

Мігруйте хвилями, а не одним перемиканням

Спочатку зберіть базові показники: частку успішних відповідей, затримку, часті NXDOMAIN і відповіді для контрольних імен. Завчасно зменште TTL записів, які змінюватимуться. Зниження TTL у момент перемикання не прибере відповіді, уже збережені за старим значенням.

Першою хвилею переведіть невелику тестову групу з різними умовами доступу: офіс, VPN і віддалена мережа. Порівнюйте не лише доступність застосунку, а й фактичні DNS-відповіді. Визначте критерії переходу заздалегідь: очікувана адреса для кожної групи, прийнятна затримка, відсутність витоку приватних імен і стабільна частка успішних запитів.

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

Перевірте відмови до того, як їх побачать користувачі

Для кожної DNS view виконайте щонайменше такі тести:

• наявне приватне ім’я повертає правильну адресу;
• неіснуюче приватне ім’я повертає очікуваний NXDOMAIN і не витікає назовні;
• публічне ім’я продовжує нормально відкриватися;
• недоступність авторитетного сервера дає передбачуваний результат;
• старий кеш оновлюється після завершення TTL;
• пристрій поза VPN не отримує приватну відповідь;
• клієнт, що відповідає кільком правилам, потрапляє до правильної DNS view.

Не плутайте NXDOMAIN із тайм-аутом або помилкою недоступного сервера. Для користувача результат може виглядати однаково, але виправлення буде різним.

Антипатерни, які повертають дрейф

Не проводьте велике перемикання без тестової групи. Не використовуйте очищення кешу як основний план міграції. Не залишайте правила вибору DNS view лише в головах адміністраторів. Не підтримуйте однакову зону вручну в кількох системах. І не вважайте автоматичний перехід до публічного DNS безпечним для всіх приватних імен.

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

Короткий шаблон плану

Зафіксуйте поточний маршрут, конфліктні зони, цільові DNS views, єдине місце змін, контрольні імена та базові показники. Для кожної хвилі вкажіть групу клієнтів, час початку, критерії успіху, відповідального за рішення і точний крок відкату. Окремо запишіть, коли можна вимкнути старий маршрут і як довго потрібно спостерігати за кешем та помилками.

Джерела

• Cloudflare, «Internal DNS is now generally available»: https://blog.cloudflare.com/internal-dns/