Налаштування DNS-резолвера: де ламається розв'язання імен
Розв'язання імен на сервері — це ланцюжок: застосунок, локальний розпізнавач, вищі сервери й коренева зона. Ламається зазвичай не сам ланцюжок, а його стики: порожній кеш після перезапуску, єдина вища адреса в конфігурації та передбачувано непередбачуваний перший запит.
Під час перезапуску служби розв'язання імен локальний кеш обнуляється, і перший запит після перезапуску йде повним шляхом — рекурсивний обхід, перевірка підписів, а за усіченої відповіді ще й повтор іншим транспортом.
На старті застосунку таких запитів десятки, вони вишиковуються в чергу, і відгук сервісу в перші секунди помітно просідає. Постійний кеш із прогрівом під час старту прибирає ефект: імена віддаються з локальної бази, поки вищі лише опитуються.
Друга точка відмови — прив'язка до однієї вищої адреси: вона йде в тайм-аут або відповідає повільно, і чекає весь застосунок, а не лише службова служба.
Третя — файл конфігурації розв'язання імен перезаписується менеджером мережі під час наступного підняття інтерфейсу, а вбудований розпізнавач займає локальну адресу й конфліктує з власними зонами та спільними каталогами.
Вибір між вбудованим механізмом і окремим сервісом — systemd-resolved чи Unbound — це вибір між «працює з коробки» і «керовано налаштовується»: окремий сервіс дає негативне кешування, кілька вищих із перевіркою доступності, розділення зон за доменами та статистику запитів. Як закривається кожна з цих точок відмови під час налаштування DNS-резолвера — нижче.
Локальний кеш, відмовостійкість і приватність запитів
Локальний кеш імен змінює профіль навантаження сервісу загалом. Замість мережевого звернення на кожен виклик застосунок отримує відповідь із пам'яті резолвера, і повторні розв'язання тих самих імен перестають залежати від зовнішньої мережі.
Час відгуку застосунку на типовому профілі визначається обробкою, а не очікуванням розв'язання, і тримається на одному рівні навіть за перевантаження зовнішніх серверів. Негативний кеш працює так само: ім'я, якого немає, не перепитується на кожен виклик.
Відмовостійкість будується на резервних серверах розв'язання, а не на надії, що провайдер не впаде. У конфігурації прописують кілька зовнішніх адрес із пріоритетом і тайм-аутом: недоступність однієї переводить запит на наступну, а не валить розв'язання цілком.
Стійкість до недоступності провайдера дає й сам кеш — уже відомі імена продовжують відповідати, поки зовнішній канал лежить, і сервіс не втрачає зв'язність із тими, з ким уже обмінювався трафіком.
Приватність — наслідок того самого кешу. Назовні йде лише частка запитів, решта гаситься локально, тому зовнішній спостерігач бачить не повну картину звернень сервісу, а її фрагмент. Транспорт до зовнішніх серверів закривають шифруванням, щоб запити не читалися в дорозі.
Що саме ставити — питання сценарію. Unbound як повноцінний рекурсивний резолвер дає контроль над зонами, лімітами та розміром кешу, але потребує власної експлуатації; systemd-resolved ближчий до ролі локальної заглушки, дешевший у підтримці й штатно лягає на більшість серверів.
Обидва варіанти закривають кеш, резервні сервери та вихід трафіку назовні — різниця в тому, кому ви віддаєте керування розв'язанням.
Варіанти організації розв'язання імен: порівняння режимів
Розв'язання імен на сервері майже ніколи не зводиться до «поставити резолвер і забути»: значення має те, хто володіє конфігурацією вузла і як поводитиметься розв'язання, коли вищий сервер перестане відповідати.
Вбудована служба розв'язання живе поруч із мережевою підсистемою й керується тими самими засобами, а окремий кешувальний сервер — самостійний процес зі своїм конфігом, кешем і правилами пересилання.
На практиці обирають між трьома схемами, і різниця проявляється не у швидкості однієї відповіді, а в тому, як схему супроводжують, спостерігають і налагоджують. Нижче — реальні альтернативи, між якими найчастіше постає вибір.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудована служба розв'язання | Одиничний вузол або невеликий контур, де мережею вже керує системний менеджер | Кеш і статистика обмежені, тонкої політики за зонами немає, поведінка залежить від збірки дистрибутива |
| Окремий кешувальний сервер | Кілька вузлів, потрібен спільний кеш і власна локальна зона для внутрішніх імен | Потребує власного конфігу, моніторингу й оновлення — це ще один сервіс, за яким стежать |
| Комбінована схема з перенаправленням запитів | Внутрішні зони обслуговуються локально, зовнішні йдуть на довірені вищі резолвери | Шлях запиту проходить дві ланки, складніше налагодження й розмежування зон |
Ключовий критерій — не «який варіант сучасніший», а скільки у вас вузлів, чи потрібна локальна зона для внутрішніх імен і наскільки легко ви знайдете причину, коли конкретне ім'я не розв'язується. Опишіть ваш контур — повернемося з оцінкою та планом переходу.
Етапи впровадження: від аудиту поточних налаштувань до передачі
Порядок робіт вибудовуємо так, щоб зміна резолвера не перетворювалася на аварію: спочатку фіксуємо поточну картину, потім змінюємо. Кожен етап закінчується артефактом — конфігом, схемою або звітом перевірки, тому рішення залишається відтворюваним.
- Аудит налаштувань сервера. Збираємо, хто і як розв'язує імена: інтерфейси та їхній стан, статичні записи, умовні перенаправлення для внутрішніх зон, перевизначення, які служби звертаються до локального обробника напряму. Окремо дивимося хости, де прописано сторонню адресу — зазвичай саме вони дають розбіжності після перемикання.
- Проєктування схеми. Порівнюємо systemd-resolved і Unbound під задачу: чи потрібна валідація підписів, власні зони, розділення внутрішніх і зовнішніх імен, окремий кеш для сервісів. Фіксуємо, де буде точка відмови і як вона переживає недоступність вищого сервера.
- Стенд. Розгортаємо конфігурацію в ізоляції та звіряємо відповіді з поточною схемою за критичними іменами: ті самі адреси, ті самі терміни життя запису, передбачувана поведінка за недоступності джерела.
- План відкату. Вихідні файли й параметри запуску зберігаємо до правок, порядок повернення описуємо порядково. Перемикаємо по одному вузлу, а не весь парк одразу — у разі відхилення повернення займає хвилини.
- Перемикання. Змінюємо системні обробники імен, перезапускаємо службу й стежимо за часткою відмов і часом відповіді. Зростання звернень до зовнішніх серверів — перша ознака, що кеш не прогрівся.
- Перевірка після перемикання. Контрольні запити за внутрішніми та зовнішніми зонами, поведінка кешу, реакція на перезапуск служби й на розрив зв'язку з вищим сервером. Результати фіксуємо у звіті.
- Передача. Конфіги йдуть у репозиторій, до них — схема, політика оновлення зон і коротка інструкція для чергового: що дивитися й що відкочувати.
Опишіть поточну схему розв'язання імен — повернемося з оцінкою та планом робіт.
Конфігурації, схеми зон і регламенти: що залишається у вас
Резолвер перестає бути чорною скринькою, коли вся його конфігурація лежить у репозиторії та описана словами.
Ми передаємо не набір «магічних» файлів, а робочу систему: за нею ваш інженер підніме такий самий вузол з нуля, повторить конфігурацію на стенді й відкотить зміну, не розбираючись у чужих нотатках.
- Файли налаштувань — основна конфігурація та додаткові файли перевизначення в системі контролю версій, з історією правок і осмисленим описом кожної зміни.
- Схема зон і перенаправлень — які домени розв'язуються локально, які йдуть на вищі резолвери, де стоять умовні перенаправлення для внутрішніх зон і як це пов'язано з доменом пошуку.
- Правила доступу — з яких підмереж дозволені запити до службових портів, кому відкрита рекурсія, що закрито назовні й чому.
- Регламент обслуговування — періодичність перевірки зон, оновлення кореневих підказок, ротація службових записів і перезапуск служби без простою.
- Порядок дій у разі збою — з чого починати діагностику, як переключитися на резервний резолвер, якою командою відкотити конфігурацію до останньої робочої ревізії.
- Документація з інфраструктури — адреси й ролі вузлів, точки моніторингу, відповідальні, зв'язки резолвера з іншими сервісами.
- Набір перевірок після правки — час відповіді, частка відмов, доступність внутрішніх зон; алерти прив'язані саме до цих метрик. Пакет залишається у вас разом із розбором на дзвінку: що перевіряти після кожної правки і за якими ознаками видно деградацію. Експлуатація не повинна залежати від однієї людини.
Приклад впровадження: розв'язання імен перестало залежати від провайдера
Серверний парк замовника — близько 60 машин на двох майданчиках — ходив за іменами напряму до резолверів провайдера, а на частині хостів працював локальний кеш зі складу дистрибутива, і налаштування з часом роз'їхалися.
Частка невдалих запитів на піку трималася близько 4%, а прикладний сервіс, який на старті розбирає десятки внутрішніх імен, відповідав удвічі довше за звичайне.
Що змінили
Підняли рекурсивний резолвер на Unbound і поставили два незалежні вузли на різних майданчиках — відмова будь-якого з них більше не зупиняє розв'язання імен.
Локальні кеші на хостах вимкнули, машини перевели на дві адреси через керований параметр, внутрішні зони описали окремо від зовнішніх. Доступність вузлів, час відгуку й частку помилок віддали в моніторинг з автоматичними перевірками.
Метрики до і після
- Частка невдалих запитів: близько 4% на піку → стабільно нижче 0,2%, одинична відмова закривається повтором на другий вузол.
- Час відгуку прикладного сервісу на старті скоротився удвічі — завдяки кешу та передбачуваному маршруту запитів.
- Звернення за інцидентами з розв'язанням імен: 8–10 на місяць → одне за квартал, і те із внутрішньої зони.
Єдина точка відмови зникла: зовнішні резолвери залишилися резервним шляхом, але перестали бути єдиним джерелом відповідей. Далі розвиваємо схему — додаємо розділення зон за майданчиками та перевірки, які ловлять розходження налаштувань до того, як його помітять користувачі.
Вбудований резолвер чи окремий: коли потрібен другий?
Коротка відповідь: вбудована служба закриває одиничний сервер, а окремий екземпляр потрібен, коли з'являється парк машин, ізольований контур або вимога бачити кожен запит.
Вбудований резолвер стартує разом із системою й віддає кеш усім локальним процесам — цього достатньо, поки мережеві налаштування не змінюються з-під нього.
Вбудований резолвер читає параметри від менеджера мережі та перезаписує вищі сервери за кожного оновлення адрес.
Журналювання запитів у нього спільне із системним журналом, без розбивки за клієнтами, а обсяг кешу нічим обмежити — на навантаженому хості це перше, що хочеться винести назовні.
Окремий Unbound дає явні зони, локальні перевизначення, кеш із прогрівом популярних імен і окремий журнал: видно, хто, що і коли запитував.
Навантаження на сервер стає передбачуваним — процес живе під своїм обмежувачем ресурсів, а на парку машин його виносять на виділений вузол із доступом за списком підмереж.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудована служба | Одиничний сервер, проста мережа | Налаштування перезаписує менеджер мережі, журналу за клієнтами немає |
| Окремий екземпляр на тому самому хості | Потрібні локальні зони й розбір запитів | Один хост — одна точка відмови, ділить ресурси із застосунками |
| Окремий вузол для парку машин | Спільний кеш на десятки серверів | Потрібні обмеження доступу й контроль доступності |
| Резолвер в ізольованому контурі | Внутрішні імена не повинні виходити назовні | Лише власні джерела та форвардер периметра |
В ізольованому контурі резолвер узагалі не ходить назовні: внутрішні зони віддає авторитетне джерело, зовнішні — форвардер на периметрі. Відповіді йдуть лише дозволеними маршрутами, витік внутрішніх імен через публічні резолвери виключено.
Сумніви інженера: кеш, шифрування, відкат налаштувань
Перед стартом робіт інженери ставлять той самий набір запитань: що буде з уже накопиченим кешем, чи йдуть запити назовні у відкритому вигляді, чи не зламається розв'язання імен у служб, які вже розгорнуто, і як повернутися до попередньої схеми, якщо щось піде не так. Нижче — короткі відповіді за кожним пунктом.
Що робити із застарілими записами в кеші?
Кеш живе за часом життя запису, тому стара зона після переїзду сервісу — звична річ. У нас є явне скидання кешу, а перед змінами ми знижуємо час життя записів і повертаємо попереднє значення після перевірки.
Чи передаються запити назовні в зашифрованому вигляді?
Вихідні запити можна загортати в шифрований транспорт, щоб провайдер і проміжні вузли не бачили імена. Усередині периметра резолвер відповідає звичайним портом — інакше контейнери й старі служби перестануть розв'язувати імена.
Сумісність зі службами, які вже працюють?
Перед заміною знімаємо список тих, хто і як запитує DNS: системні служби, контейнери, VPN, домени. Розділення зон — внутрішні локально, зовнішні назовні — налаштовується до перемикання, тому служби бачать звичні імена.
Як проходить відкат налаштувань?
Конфігурації лежать у системі контролю версій, застосування й відкат — перемиканням на попередній набір файлів. Старий резолвер не видаляємо, поки нова схема не відпрацює під навантаженням; повернення займає хвилини й не потребує перезавантаження сервера.
Обговоримо задачу: як ми приходимо до плану впровадження
Щоб оцінка спиралася на факти, а не на здогадки, потрібен мінімум вхідних даних: як влаштовані контури, хто і як розв'язує імена зараз, які вимоги ставляться до ізоляції запитів.
Саме це визначає вибір між локальним кешувальним резолвером і Unbound із власними зонами та пересиланням у закриті контури.
Що запитуємо на вході:
- Схему контурів: сегменти мережі, де стоять споживачі, як трафік ходить між ними.
- Перелік серверів і ролей: де локальний резолвер, де кешувальний, де форвардер.
- Вимоги до ізоляції: які зони не повинні йти у зовнішні резолвери, чи потрібен DNSSEC і як обробляти відповіді з помилкою підпису.
- Поточний стан: робочі конфігурації, спосіб розповсюдження resolv.conf, керування через конфігураційний менеджер.
- Вікно перемикання, допустимий час недоступності розв'язання імен, доступи й відповідальні за приймання.
У відповідь ви отримуєте план впровадження за етапами з критеріями готовності кожного, склад робіт із розподілом зон відповідальності та склад артефактів: конфігурації, unit-файли, політики кешування й пересилання, схему відкату до попереднього резолвера.
Окремо узгодимо порядок перемикання споживачів і перевірок після нього, а також регламент передачі в експлуатацію — метрики, алерти, інструкцію для чергового. Опишіть задачу — повернемося з оцінкою, планом і складом робіт.
