Налаштування DNSSEC під ключ: захист DNS від підміни

DNSSEC налаштування: де ламається ланцюг довіри

DNSSEC відповідає на одне вузьке питання: відповідь надійшла із самої зони чи від посередника.

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

Перевірка автентичності відповідей DNS спирається на ланцюг довіри зони. Батьківська зона зберігає DS-запис із відбитком ключа підпису дочірньої зони, резолвер звіряє за нею отриманий підпис і тягне впевненість униз по ієрархії до самого домену. Розрив на будь-якій ланці — і відповідь вважається непідтвердженою, навіть якщо всі дані на місці.

Найчастіший обрив — розходження ключів підпису в реєстратора та в зоні. Ключі змінюють, а DS-запис публікують із затримкою або з попереднім відбитком, і чекати оновлення доводиться рівно стільки, скільки живе запис у кеші батьківської зони.

Окрема причина — прострочений підпис: зона підписується заздалегідь із запасом, і якщо перепідписування зупинилося, валідація обривається без жодної правки в конфігурації.

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

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

Що дає підписана зона: ефект у вимірюваних величинах

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

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

Час розслідування інцидентів скорочується кратно, бо факт підміни перестає бути предметом здогадів.

Раніше доводилося порівнювати відповіді з різних точок і від різних провайдерів, щоб довести сам факт; тепер достатньо побачити розходження підпису — і відразу зрозуміло, де причина: закінчений підпис, розсинхрон ключів у реєстратора або застаріла копія зони. Розбір укладається в хвилини, а не в години листування з кількома сторонами.

Окремо зникає клас відмов виду «сайт то відкривається, то ні»: отруєний запис у проміжному кеші не може бути відданий як валідний.

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

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

Заміри знімаються до і після ввімкнення підпису за одними й тими самими точками: частка відповідей, відбитих валідатором, кількість звернень «не відкривається», час від першого сигналу до закриття інциденту. Це ефект, який видно у звіті, а не лише в описі стандарту.

Варіанти підключення захисту: порівняння режимів

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

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

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

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

Порядок впровадження: від аудиту зони до передачі

DNSSEC — не одне налаштування, а ланцюг: якщо помилитися в порядку, зона перестає розв’язуватися в частини клієнтів, причому помітно це не відразу.

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

Етапи

1. Аудит DNS-зони. Інвентаризуємо всі записи та делеговані підзони, звіряємо копії зони на різних серверах, знаходимо конфлікти, через які підпис стане невалідним.
2. Схема делегування та ланцюг довіри. Визначаємо, хто передає зону батьківській зоні, де публікуються ключі та як підтверджується їхній зв’язок — без цього підпис не приймуть зовнішні резолвери.
3. Увімкнення підпису зони. Генеруємо ключі підпису, задаємо строки їхньої ротації та час життя підписів у кеші, синхронізуємо зону між усіма серверами.
4. Тестовий режим. Зона вже віддається з підписами, але ключ батьківській зоні не передано: видно, що відповіді формуються коректно, при цьому клієнти не зачеплені.
5. Публікація в батьківській зоні. Після підтвердження тесту публікуємо ключ — із цього моменту зона вважається підписаною, а відкат можливий лише узгодженою дією.
6. Перевірка з різних резолверів. Опитуємо публічні, локальні та розподілені резолвери: відповіді підтверджуються, відмов немає, поведінка однакова в усіх.
7. Передача регламенту. Віддаємо документ із порядком ротації ключів, діями при збої підпису та точками моніторингу, навчаємо команду на реальних сценаріях.

Політики, ключі та документація: що залишається у вас

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

• Карта зон і піддоменів — перелік зон, їхніх точок делегування та відповідності записам у реєстратора: видно, де закінчується ваша відповідальність і починається зона провайдера.
• Схема ланцюга довіри — від кореневої зони до підписаних записів, із зазначенням, де зберігаються батьківські та дочірні ключі і як вони пов’язані.
• Політика зміни ключів — строки життя ключів підпису та ключів підпису ключів, порядок публікації нового запису в реєстратора, хто ініціює планову зміну і що робити при компрометації.
• Розмежування ролей доступу до зони — хто змінює ключі, хто лише записи, хто має доступ на читання; окремий обліковий запис для аварійних робіт.
• Регламент перевірок — що і як часто звіряємо: валідність підпису, строки життя ключів, збіг даних у реєстратора та в самій зоні.
• Документація інфраструктури DNS — адреси серверів, схема резервування, місця зберігання ключів і порядок відновлення з резервної копії.
• Інструкція на випадок інциденту — покрокове зняття підпису з зони при аварії та повернення до робочого стану без простою домену.

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

Кейс: переведення зони на підпис без втрати трафіку

Вихідний стан

У роботу надійшла жива зона: основний домен, кілька десятків піддоменів під пошту, API та внутрішні сервіси, строк життя записів — від пари хвилин до доби. Зона не була підписана, тому будь-який проміжний резолвер міг підмінити відповідь, і з боку власника це ніяк не виявлялося.

Окремий ризик — перший для домену DS у батьківській зоні: помилка в ланцюгу довіри вимикає весь домен, а не один запис. Тому до публікації зняли базові заміри: час відповіді авторитетних серверів, розподіл запитів за типами та частку трафіку від валідувальних резолверів.

Заміри та перевірки на резолверах

Підписану версію зони зібрали на окремому стенді та прогнали через зовнішні перевірки ланцюга, включно з Google Public DNS. DS у реєстратора опублікували лише після чистого проходження — крок незворотний на час, що дорівнює строку життя делегування.

Після ввімкнення частка відповідей із помилкою перевірки залишилася нульовою, приріст часу відповіді вклався в одиниці відсотків, кількість звернень «відкривається не в усіх» не зросла.

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

Контрольний обхід резолверів і перевірку ланцюга повторюємо за розкладом: довіра ламається тихо, і без регулярної перевірки про це дізнаються від клієнтів.

Налаштування DNSSEC при зміні реєстратора: що врахувати

Так, зміна реєстратора при ввімкненому DNSSEC проходить без простою — за умови, що порядок дій дотримано жорстко.

DS-запис живе в батьківській зоні й указує на конкретний ключ підпису, тому поки вона посилається на старий ключ, а сервери віддають новий, валідувальні резолвери повертають SERVFAIL — для клієнтів це виглядає як повна відмова домену.

Порядок такий: заздалегідь знизити TTL і вичекати старий інтервал, перенести зону разом із приватною частиною ключів KSK/ZSK (або усвідомлено згенерувати нові), підняти новий майданчик і переконатися, що він віддає DNSKEY і RRSIG, потім змінити DS через нового реєстратора і лише після оновлення батьківської зони гасити стару.

Реєстровий інтерфейс, через який публікується DS, визначає ICANN, але строки застосування змін у кожного реєстру свої — їх уточнюють до початку робіт.

Типові помилки переходу — зняти DS раніше за публікацію нового ключа, перенести лише публічну частину, не змінити TTL і строк життя підпису, забути прибрати старі NS з делегування: частина резолверів продовжить ходити на майданчик без підпису.

Технічні сумніви: розбір частих ситуацій

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

Піддомен делеговано іншій команді — що буде з перевіркою?

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

Тому ми на старті збираємо карту делегувань і за кожним піддоменом вирішуємо: підписуємо самі, домовляємося з власником або залишаємо як є. Це фіксується в документації, щоб зміна відповідального через пів року не перетворилася на аварію.

Сумісність із поштою та сторонніми сервісами

Поштові записи підписуються разом із зоною, і на роботу MX це не впливає — ламається зазвичай не пошта, а резолвери, які не вміють розбирати розрослі відповіді.

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

Якщо сервіс-підрядник не підтримує перевірку підписів, проблему вирішує підписана проміжна зона, а не відмова від DNSSEC.

Як перевірити ланцюг довіри до запуску в бій?

Ми проганяємо контрольний сценарій на тестовій копії зони: корінь — батьківська зона — наша зона, звіряючи на кожному кроці дайджест DS із ключем і строк дії підписів.

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

Обговоримо вашу зону та повернемося з оцінкою і планом

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

• Повний перелік зон і піддоменів, включно з тими, що делеговані на інші сервери або обслуговуються в підрядників: пропущена зона залишиться без підпису, і її трафік продовжить ходити незахищеним.
• Схема делегування: хто тримає батьківську зону, де публікуються записи про ключі, чи є проміжні ланки та зони-заглушки на боці реєстратора.
• Доступи, які знадобляться в роботі: панель реєстратора для публікації записів про ключі, сервери з DNS-сервісом, репозиторій конфігурацій, система моніторингу.
• Поточний стан: чи ввімкнено DNSSEC на частині зон, як зберігаються ключі, з якою періодичністю змінюються, хто відповідає за продовження.
• Перелік зовнішніх сервісів і резолверів, які зав’язані на ваші домени, — частина з них може не підтримувати перевірку підпису, і це з’ясовується до увімкнення, а не після.

На розборі ми проходимо по зонах згори вниз: відзначаємо, де увімкнення зачіпає батьківську зону, де потрібна ручна операція в панелі реєстратора, де є ризик короткої перерви в розв’язанні імен.

За підсумком ви отримуєте схему делегування з позначеними точками контролю, порядок увімкнення та точку відкату на кожному кроці.

Опишіть вашу задачу та додайте те, що вже є під рукою, — повернемося з оцінкою і планом робіт.