DNS-сервер як єдина точка відмови: де саме ламається
Поки DNS-сервер один, він і є єдина точка відмови.
Падіння процесу, переповнення диска під журнали або мережевий збій на вузлі миттєво перетворюються на збій розв'язання імен для всіх одразу — і для зовнішніх відвідувачів, і для внутрішніх сервісів, які знаходять одне одного за іменами.
Ззовні це виглядає як повільний відгук сайту: резолвер не отримує відповідь, чекає таймаут і лише потім іде на резервну адресу, а частина запитів віддає помилку.
Усередині каскад помітніший — сервіси, зав'язані на розв'язання імен, відмовляють ланцюжком, а застарілі записи живуть у кешах до закінчення TTL, тому й після підйому вузла трафік якийсь час іде на виведені адреси.
Друга причина — ручні правки зон. Записи додають прямо на робочому вузлі, серійний номер зони не збільшують, і вторинні копії мовчки залишаються на старій версії.
Через кілька місяців конфігурації на вузлах розходяться, ніхто не знає, яка з них правильна, а перенесення змін між середовищами перетворюється на окрему ризиковану операцію.
Третя — відсутність реплікації: оновлення, обслуговування або переїзд вузла потребують вікна простою, бо переключитися нікуди. Підхід не залежить від реалізації — і Bind, і PowerDNS однаково погано переносять єдиний вузол із ручним редагуванням зон.
Усі три збої закриваються однією архітектурою: кілька вузлів, автоматична передача зон, перевірка живості та передбачуване перемикання. Розбираємо, як це влаштовано.
Що дає керований DNS-сервер: швидкість, стійкість, контроль
Керований DNS-сервер — це не історія «поставили й забули». Основу обираємо під задачу: BIND зручний, коли зони живуть у текстовому вигляді та правляться рідко, PowerDNS — коли записи зберігаються в базі та змінюються автоматично. Далі — три ефекти, які видно в метриках.
Зниження часу відгуку розв'язання імен
Кешувальний резолвер віддає повторні запити з локального кешу, не виходячи в зовнішню мережу: на прогрітому кеші частка влучань тримається на рівні 90–95%, а TTL внутрішніх зон підбирається під реальну частоту змін.
Прямі звернення до авторитетних серверів замість довгого ланцюжка чужих резолверів прибирають зайві кроки в розв'язанні. Час відгуку скорочується в рази, і зникає клас відмов «застосунок чекає відповіді чужого резолвера».
Відмовостійкість при відмові вузла
Один сервер — одна точка відмови: падіння вузла означає, що домен просто не відкривається, хоча сам застосунок працює.
Схема з кількох інстансів із реплікацією зон і зовнішнім моніторингом знімає це: недоступність вузла фіксується перевіркою, трафік переводиться на живий сервер без ручних правок і чергового адміна вночі.
Розв'язання імен тримається в межах цільової доступності 99,99%, а клас відмов «сайт живий, але домен не резолвиться» зникає зовсім.
Контроль трафіку
Кожен запит пишеться в лог і розбирається за джерелом і типом, тому аномалія видна на графіку в момент появи, а не за фактом простою.
Політики відповідей і обмеження частоти гасять звернення до відомих шкідливих доменів і сплески від заражених хостів усередині мережі, ACL за підмережами закриває резолвер від відкритого рекурсивного використання ззовні. Сплеск навантаження перестає бути сюрпризом — за логами відразу видно, який сегмент його створив.
Авторитетний, кешувальний і режим пересилання: що вибрати
Той самий сервер рідко працює в одному режимі. Авторитетний сервер віддає лише свої зони та не відповідає за чужі домени, кешувальний приймає запити клієнтів і тримає відповіді до закінчення часу життя, а режим пересилання запитів передає все зовнішнє на вищі резолвери.
Плутанина між ролями дає два класи збоїв: відкритий резолвер, який використовують для підсилених атак, і «залиплі» відповіді під час зміни делегування.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Авторитетний сервер | Свої домени й піддомени: публікація зон, поштові та сервісні записи | За зовнішні імена не відповідає; відкритий доступ до нього по мережі не потрібен |
| Кешувальний сервер | Внутрішня мережа, офіси, майданчики: прискорює повторні запити | Потребує обмеження списку клієнтів і захисту від підміни відповідей |
| Режим пересилання запитів | Філії та сегменти за міжмережевим екраном, де прямий вихід закритий | Залежить від доступності вищих резолверів, менше контролю над кешем |
Розділення зон і делегування
Ролі розносимо за різними екземплярами: авторитетний шар тримає зони та передає їх між вузлами, кешувальний слухає лише внутрішні адреси.
Делегування піддоменів оформлюємо окремими зонами зі своїм набором серверів — правка однієї зони не зачіпає інші, а передача змін не впирається в єдиний вузол.
Захист кешу від підміни відповідей
Кеш приймає відповідь лише від сервера, якому делеговано домен, і перевіряє ланцюжок підписів зони там, де вона налаштована. Обмеження джерел запитів і відмова від рекурсії для зовнішніх адрес прибирають сценарій, у якому клієнт отримує підставлену адресу замість справжньої.
Етапи впровадження: від інвентаризації зон до передачі в підтримку
Порядок впровадження DNS будується так, щоб кожен наступний крок спирався на зафіксований результат попереднього: спочатку описуємо поточний стан, потім відтворюємо його на ізольованому контурі й лише потім випускаємо зміни в бойову експлуатацію. Такий порядок залишає можливість відкату на будь-якому кроці.
Інвентаризація та схема зон
- Збираємо перелік зон з усіх джерел: конфігурації працюючих серверів, панелі реєстраторів, внутрішні документи. На виході — таблиця зон із власником, призначенням і поточним розміщенням.
- Розмічаємо межі: зовнішні та внутрішні зони, розщеплення відповідей, зворотні зони для адресного простору, делегування піддоменів.
- Фіксуємо типи записів, TTL і зв'язки з поштою. Розбіжності між джерелами знімаємо до початку робіт, а не по ходу.
Перевірка на тестовому контурі перед викаткою
- Розгортаємо копію конфігурації на ізольованому стенді та проганяємо автоматичну перевірку синтаксису й цілісності зон, окремо — підписи та коректність делегування.
- Порівнюємо відповіді тестового та бойового контуру за контрольними іменами: розбіжність — це або помилка перенесення, або навмисна зміна, і тоді її підтверджує власник зони.
- Викочуємо без зупинки сервісу: спочатку вводимо другий сервер і переводимо на нього навантаження, потім змінюємо налаштування основного, стежачи за часткою успішних розв'язань.
Передача в підтримку — окремий крок: конфігурації, схеми зон і порядок дій при типових збоях ідуть у документацію, доступи розмежовані за ролями, у чергового є точка входу та зрозуміла ескалація.
Конфігурації, схеми зон і регламенти оновлення записів
Робота здається не лише налаштованими серверами: у команди замовника залишається комплект документів, за якими інфраструктуру можна супроводжувати без нас. Нижче — що входить до цього комплекту та як кожен артефакт використовується в щоденній роботі.
Схеми зон і ролі доступу
- Схема зон прямого та зворотного перегляду: які зони обслуговуються, де розміщені, як пов'язані між собою та з іншими сервісами.
- Карта ролей доступу: хто лише читає записи, хто вносить правки, хто змінює серверну конфігурацію — із зазначенням відповідальних.
- Опис записів із призначенням: які імена вказують на сайти та застосунки, які обслуговують пошту, які службові.
Регламенти оновлення та відновлення
- Регламент оновлення записів: як оформлюється заявка, хто погоджує, як перевіряється результат і в який момент можна відкотитися.
- Правила ведення зон: порядок зміни серійних номерів і значення часу життя записів за замовчуванням.
- Порядок резервного копіювання конфігурацій: що копіюється, з якою періодичністю, де зберігаються копії та як перевіряється їхня цілісність.
- Інструкція відновлення: покроковий підйом сервісу з копії та перевірка, що всі зони відповідають коректно.
- Журнал змін: хто й коли вносив правки, щоб розбір збою займав хвилини.
Документація з DNS ведеться поруч із конфігураціями в системі контролю версій: правки проходять перевірку до застосування, а історія змін залишається доступною. Такий комплект дозволяє передати супровід вашій команді або іншому підряднику без відновлення знань по пам'яті.
Кейс: як прибрали єдину точку відмови та скоротили простої
Клієнт — сервіс з особистим кабінетом і відкритим API, де всі зони обслуговував один сервер, а другий стояв «на всякий випадок» і оновлювався вручну.
Під час мережевих збоїв і планових робіт записи на вузлах розходилися, а перемикання займало десятки хвилин: частина користувачів не могла розв'язати ім'я та бачила помилку замість сторінки входу.
Що змінили в схемі зон і реплікації
Замість ручного копіювання файлів зон налаштували головний вузол і кілька реплік, які забирають зони автоматично та підтверджують актуальну версію. Правки проходять перевірку синтаксису та порівняння з поточним станом до публікації, тому бита зона не доходить до серверів.
Для записів виставили різні строки життя: короткі там, де адреси змінюються під час перемикання сервісів, довгі — для статичних.
| Показник | До | Після |
|---|---|---|
| Точок відмови в розв'язанні імен | 1 | 0 |
| Перемикання при збої вузла | до 40 хвилин | менше 2 хвилин |
| Ручних кроків при правці зони | 4-6 | 1 |
| Частка інцидентів через розходження зон | близько третини | 0 |
| Відновлення вузла з копії | за інструкцією вручну | автоматично |
Схему зібрали на актуальній гілці PowerDNS із зоною, винесеною в систему контролю версій: будь-яка зміна видна в історії та відкочується однією командою.
Після перенесення простій, пов'язаний із розв'язанням імен, перестав потрапляти у звітність — за квартал жодного випадку, коли домен не відкривався.
Чим відрізняється кешувальний режим від авторитетного?
Авторитетний сервер — джерело істини для своєї зони: записи (A, AAAA, MX, TXT, SOA, NS) він зберігає в себе та віддає рівно в тому вигляді, у якому їх внесли. За відповіддю він нікуди не ходить: немає запису — отже NXDOMAIN, а не запит до сусідів.
Зміни потрапляють у відповідь лише через правку зони та її перезавантаження з оповіщенням вторинних серверів.
Кешувальний, він же рекурсивний, резолвер чужих зон не зберігає взагалі. Він приймає запит від клієнта, сам обходить ланцюжок авторитетних джерел і тримає отриману відповідь у тимчасовому сховищі до закінчення TTL.
Джерело істини для нього — зовнішні зони, а його роль — не дати повторним зверненням знову проходити цей ланцюжок. Клієнти ходять лише до нього, назовні він виходить сам.
Різниця режимів різко проявляється при збої. Падіння авторитетного сервера позбавляє домен розв'язання одразу й для всіх: поки не підніметься другий екземпляр і не отримає зону передачею, клієнти бачать відмову.
Тому публічні зони тримають щонайменше на двох серверах у різних мережах. У кешувального деградація м'якша: відповіді віддаються до закінчення TTL, але при довгому простої нові імена вже не розв'язуються.
По-різному поводиться й помилка в даних. Неправильний запис на авторитетному сервері видно всім одразу — він джерело істини. У кеші вона живе до кінця TTL, і правка на джерелі не допомагає, поки запис не протухне, тому перед перемиканнями TTL знижують заздалегідь.
Вибір режиму роботи диктує роль сервера: свої зони назовні — авторитетний, клієнти внутрішньої мережі — кешувальний резолвер.
Обидва режими нерідко сусідять на одному хості, але різними процесами та інтерфейсами, і змішувати їхні ролі не варто: відкрита назовні рекурсія перетворює сервер на підсилювач чужих атак, тому її обмежують адресами своєї мережі.
Часті сумніви: навантаження, реплікація, зони та доступ
Перед стартом майже кожна команда ставить один і той самий набір питань: чи витримає сервер пік, як зміни доїжджають до другого вузла, хто і що може правити в зонах. Нижче — короткі відповіді наших інженерів, без загальних слів.
Схема зазвичай будується на зв'язці BIND і PowerDNS: перший віддає авторитетні відповіді, другий зручніший в автоматизації та розмежуванні прав. Далі — те, що найчастіше уточнюють до підписання робіт.
Чи витримає один сервер пікове навантаження?
Авторитетний сервер відповідає з пам'яті та легко тримає десятки тисяч запитів за секунду на одному вузлі, а кешувальні резолвери гасять повторювані звернення. Якщо запас потрібен із запасом, ставимо другий вузол за спільною адресою та розносимо їх за різними майданчиками. Навантаження, час відповіді та частку відмов видно в моніторингу.
Як реплікація зон доводить зміни до всіх вузлів?
Основний сервер позначає зону новим номером, вторинні забирають зміни за оповіщенням, а не за розкладом — зазвичай це секунди. Повна копія потрібна лише при першому підключенні або після збою.
Ми звіряємо зони на всіх вузлах автоматично, щоб розходження спливало до того, як його помітять користувачі.
Що буде з уже працюючими зонами при перенесенні?
Зони вивантажуються в текстовому вигляді, переносяться записи, делегування та параметри часу життя. Перед перемиканням піднімаємо копію на новому сервері та звіряємо відповіді з поточним — построково, за кожним іменем. Перемикання робимо з можливістю повернутися на попередній сервер протягом кількох хвилин.
Як розмежовуються права доступу до зон?
У кожного адміністратора та кожної автоматизованої системи — свій ключ, прив'язаний до конкретних зон і типів записів. Динамічні оновлення приймаються лише від довірених джерел, передача зон — лише за списком дозволених адрес. Усі зміни потрапляють у журнал із зазначенням, хто і що змінив.
Чи захищаєте ви від підміни відповідей?
Так, зони підписуються, а на резолверах вмикається перевірка справжності відповідей — підроблена відповідь просто не приймається. Відкриту рекурсію закриваємо, щоб сервер не використовували для підсилення атак, і обмежуємо коло джерел, яким він відповідає. Окремо налаштовуємо оповіщення про спроби перебору та нетипові запити.
Обговоримо задачу та повернемося з оцінкою і планом робіт
Щоб оцінка була по суті, а не «середньою по ринку», нам потрібні вхідні дані щодо вашої інфраструктури. Аудит інфраструктури починаємо саме з цих даних — інакше план робіт будується на здогадках, а строки доводиться переглядати вже в процесі.
- Поточна схема: які зони обслуговуються, де розміщені сервери, яке навантаження за запитами вони тримають і хто сьогодні править записи.
- Дані зон: файли зон або записи в базі, чинні TTL, стан DNSSEC, чи є спадщина у вигляді ручних правок, які ніхто не документував.
- Відмовостійкість: скільки серверів працює, чи є прихований мастер і допоміжні сервери в різних мережах, як розподіляється трафік між ними.
- Точки інтеграції: реєстратор доменів, системи керування адресами, автоматика випуску сертифікатів, інвентар — усе, що змінює записи без участі адміністратора.
- Доступи та обмеження: кому і як видається керування, вимоги до журналювання та зберігання логів, вікна обслуговування, внутрішні регламенти безпеки.
- Симптоми: що вже болить — затримки при розв'язанні імен, розходження між серверами, ручні правки в робочому середовищі, збої після оновлень.
Опишіть задачу вільним текстом — частина даних зазвичай уже є у вигляді схем і вивантажень, окремо готувати нічого не потрібно.
Розберемо вхідні дані, повернемося з оцінкою, варіантами налаштувати DNS-сервер під ключ і планом робіт за етапами — від міграції зон до регламенту чергування.
