DNSSEC (DNS Security Extensions) — набір розширень протоколу DNS, який додає криптографічні підписи до DNS-записів. Це захищає від атак типу DNS Cache Poisoning та DNS Spoofing.
Навіщо потрібен DNSSEC
Без DNSSEC зловмисник може підмінити DNS-відповідь і перенаправити користувачів на підроблений сайт (навіть якщо у вас HTTPS). Атака називається DNS Hijacking або Cache Poisoning.
З DNSSEC кожен DNS-запис підписаний цифровим підписом. Якщо відповідь змінена — підпис не збіжиться і запит буде відхилений.
Як працює DNSSEC
- Зона підписується парою ключів: ZSK (Zone Signing Key) та KSK (Key Signing Key)
- DS-запис (Delegation Signer) публікується в батьківській зоні (.com, .ua)
- Резолвер з підтримкою DNSSEC перевіряє підпис при кожному запиті
- Якщо підпис невалідний — SERVFAIL, запит відхилений
DNSSEC: вмикати чи ні
| Вмикати | Не вмикати |
|---|---|
| Фінансові сайти | Складне налаштування DNS |
| Державні ресурси | Часта зміна DNS-провайдера |
| Медичні портали | Немає підтримки у провайдера |
| Корпоративні мережі | Невеликий особистий блог |
Перевірка DNSSEC
# Перевірити підпис домену
dig example.com DNSKEY +dnssec
# Онлайн-валідатор
# dnsviz.net — візуальна карта DNSSEC-ланцюгаУвімкнення DNSSEC у ZevsHost
- Увійдіть в Особистий кабінет → Домени → керування доменом
- Розділ DNSSEC → увімкнути
- Система автоматично створить DS-записи та ключі
- DS-запис буде опублікований у реєстрі зони
Алгоритми підпису: Algorithm 8, 13 і 15
У DS- та DNSKEY-записах є числовий параметр Algorithm — він визначає криптографічний алгоритм підпису зони. Від нього залежить, чи зможе резолвер взагалі перевірити підпис.
| Algorithm | Назва | Статус | Де трапляється |
|---|---|---|---|
| 5 | RSASHA1 | Застарілий, не рекомендований для нових зон | Старі зони, підписані до 2015 року |
| 8 | RSASHA256 | Повністю підтримується, але більші ключі | Зони, підписані BIND/PowerDNS за замовчуванням до 2019–2020 року |
| 13 | ECDSAP256SHA256 | Поточний стандарт де-факто | Нові зони в cPanel, Cloudflare, більшості реєстрів |
| 15 | ED25519 | Сучасний, компактні підписи, підтримується не всіма старими резолверами | Свіжі впровадження на BIND 9.16+, Knot DNS |
Зміна алгоритму для вже підписаної робочої зони — не одноразова операція: потрібно опублікувати новий DNSKEY, дочекатися завершення TTL старих записів у всіх резолверів світу, і лише потім оновити DS-запис у реєстратора. Пропуск паузи між кроками дає тимчасовий статус Bogus для частини користувачів.
SERVFAIL і Bogus — у чому різниця
Обидва статуси виглядають як «сайт не відкривається», але означають різне:
- SERVFAIL — резолвер не зміг отримати відповідь узагалі: прострочений підпис, недоступний авторитетний сервер, або помилка в самій зоні
- Bogus — резолвер отримав відповідь, але підпис не пройшов перевірку: DS у реєстрі не збігається з реальним DNSKEY зони
# Перевірити статус валідації явно, через delv (входить у BIND)
delv example.com A
# Очікуваний вивід за наявності проблеми:
# resolution failed: bogusdelv на відміну від dig повідомляє причину відмови текстом, а не просто кодом SERVFAIL — це перший інструмент для діагностики, а не здогадок за логами резолвера.
Коли DNSSEC не варто вмикати
- Зона часто переїжджає між DNS-провайдерами — розсинхронізація DS під час кожної міграції створює ризик вищий за користь
- Реєстратор домену технічно не підтримує публікацію DS-записів (актуально для частини ccTLD) — увімкнення на боці хостингу не дасть захисту
- Немає процесу ротації ключів і моніторингу строку дії RRSIG — забутий прострочений підпис повністю зупинить резолвінг домену
- Використовується DNS з агресивним failover за IP за секунди — DNSSEC ускладнює налагодження таких сценаріїв, див. DNS failover
- Домен обслуговується з TTL менше 60 секунд для швидкого перемикання — за такого TTL операційні помилки в DNSSEC проявляються швидше, ніж встигає відреагувати моніторинг
Перевірка ланцюга довіри після зміни реєстратора
# Перевірити DS-запис, видимий у батьківській зоні
dig example.com DS +short
# Перевірити повний ланцюг від кореня
dig +trace example.com A
# Звірити Key Tag у DS із тегом чинного DNSKEY
dig example.com DNSKEY +shortПісля трансферу домену до нового реєстратора DS-запис фізично зберігається в реєстрі TLD, а не в реєстратора — тому зміна реєстратора сама собою DNSSEC не ламає. Ламає її самостійна дія підтримки нового реєстратора, яка іноді очищає DS-записи «про всяк випадок» під час трансферу — це варто уточнювати заздалегідь.