DNSSEC: Помилка ротації, що одночасно виводить з ладу пошту й веб

February 15, 2026 • February 15, 2026 • Читання: 6 хв • Views: 0

Було корисно?

Коли DNSSEC дає збій, режим відмови жорсткий: резолвери не «трохи» падають. Вони валідовують, їм не подобається те, що вони бачать, і вони повертають SERVFAIL. Ваш сайт виглядає мертвим. Ваш API здається недоступним. А електронна пошта — часто маршрутизована через ті самі MX і пов’язані записи домену — тихо перестає приходити.

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

Що реально ламається, коли ламається DNSSEC

DNSSEC не «ламає DNS» загалом. Він ламає резолюцію для валідувальних резолверів. Цей нюанс важливий, бо ваші внутрішні рекурсивні резолвери, ISP ваших клієнтів і публічні резолвери можуть поводитись по-різному одночасно. Дехто валідовує. Дехто — ні. Дехто налаштований невірно і валідовує «інколи» залежно від апстріму. Так виникає найгірший тип інциденту: частково, залежно від географії і резолвера.

Коли ваш домен стає bogus (термін DNSSEC для «криптографічно недійсний»), валідувальні резолвери припиняють відповідати. Вони повертають SERVFAIL для записів у ураженій зоні:

Веб ламається, бо запити A/AAAA для www або апексу не вдаються.
API ламається, бо сервіс-дискавері перестає працювати.
Пошта ламається, бо MX-запити не вдаються, крім того TXT-записи для SPF/DMARC можуть не відповідати, і деякі MTA трактують це як фатальну помилку або відкладають доставку на години.
Аутентифікація ламається, бо метадані OIDC/SAML, callback-домени та хости для перевірки токенів часто знаходяться в тій самій зоні.
Видача сертифікатів ламається, бо ACME-челенджі залежать від DNS або HTTP досяжності, що починається з DNS-резолюції.

Є й кумедний, але гіркий бік: ви можете й надалі резолвити свій домен з ноутбука через невалідуючий резолвер і зробити висновок «DNS в порядку». Саме так отримують постмортеми, де корінь проблеми — зіскриншот.

Факти та історичний контекст для постмортему

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

DNSSEC задумали в 1990-х після атак на кеш для того, щоб DNS потребував автентичності, а не лише доступності.
Root zone підписали в 2010, важливий рубіж, який зробив глобальну валідацію DNSSEC реалістичною без кастомних trust-anchor.
Перша ротація KSK у кореневій зоні відбулася в 2018, після років планування, затримок і ретельного вимірювання готовності резолверів.
DNSSEC не шифрує DNS; він підписує його. Конфіденційність — інша проблема (зараз її вирішують DoT/DoH на транспортному рівні).
DNSSEC додає розмір відповіді, що історично підвищувало ризик фрагментації і викликало проблеми з path MTU/фаєрволами — особливо до широкого впровадження коректної обробки EDNS0.
NSEC і NSEC3 існують частково тому, що потрібен підписаний доказ відсутності; треба підписаний спосіб сказати «такого імені немає».
Воркфлоу реєстраторів/реєстрів різняться, і багато інцидентів спричинені не криптографією, а чергами тикетів, особливостями UI та часом поширення змін.
TTL і правила кешування визначають тривалість інциденту. Навіть після виправлення DS, зламаний стан може тривати, поки не закінчаться кеші.
Деякі поштові системи обробляють помилки DNS інакше: транзитна DNS-помилка може перетворитися на години відкладеної пошти, потім вибух повторних спроб і тихі видалення, якщо черги переповняться.

Ланцюг довіри в операційних термінах (не крипто-театр)

Забудьте на хвилину білові папери. У продакшені DNSSEC — це ланцюг постачання:

Зона батька публікує запис DS для вашої зони.
Ваша дитяча зона публікує записи DNSKEY. Один із них — KSK (key-signing key), один або більше — ZSK (zone-signing keys). У багатьох реалізаціях це просто прапори та операційні ролі.
Записи вашої зони підписані RRSIG. Валідатори перевіряють підписи за допомогою DNSKEY і порівнюють дайджести з DS у батька, щоб упевнитися в уповноваженні ключа.

Суть: батько поручається за дитину, публікуючи DS. Якщо DS і DNSKEY перестануть збігатися, валідатори не відмахнуться. Вони позначать зону як bogus і припинять відповідати.

Операційний висновок простий і суворий: ротація DNSSEC — це розподілена зміна щонайменше між двома адміністративними доменами (ваша зона й батько/реєстр), плюс кешуючий шар всього інтернету. Тому «просто міняти ключі щотижня» — не ознака зрілості; це ознака того, що вам подобається уникальна хвилювання.

Цитата з надійності, яку варто повісити на стіну — бо відмови DNSSEC зазвичай є провалами процесу:

«Надія — не стратегія.» — Gene Kranz

Помилка при ротації, яка вбиває веб і пошту

Класичний мелтдаун — це така послідовність:

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

Це проста версія. Реалістична версія має більше способів нашкодити вам:

Ви публікуєте новий DNSKEY, але ще не підписали зону ним правильно (або занадто рано перестали публікувати старі підписи).
Ви оновили DS, але використали неправильний тип дайджесту або невірний key tag, бо вивід інструмента був неправильно витлумачений.
Ви оновили DS через UI реєстратора, але UI прийняв його, водночас мовчки обрізав, переформатував або затримав подання в реєстр.
Ви використовуєте DNS-провайдера, який автоматизує DNSSEC, і ви змінили провайдера без координації вилучення/додавання DS.
Ви змінили nameserver-и або мігрували DNS-хостинг і припустили, що DNSSEC «переїде зоною». Ні — він не перейде, якщо ви не перебудуєте ланцюг і не погодите DS.

Ротації DNSSEC — це місце, де «пошта і веб вмирають разом» стає дуже буквальним. Веб падає, бо клієнти не можуть резолвити A/AAAA. Пошта падає, бо відправники не можуть знайти MX і можуть трактувати це як тимчасову помилку, що відкладає пошту і накопичує повторні спроби. Ще гірше: ваші TXT для _dmarc та SPF можуть стати недоступними, і залежно від політики відправника відсутність може непередбачувано вплинути на доставлюваність.

Жарт №1: DNSSEC — як швейцар із мікроскопом. Чудова безпека, доки ви не написали своє ім’я з помилкою і вам не заборонять вхід на власну вечірку.

Чому ця помилка така катастрофічна: валідатори fail-closed

DNSSEC створено, щоб захищати від підробки. Якби валідатори приймали «можливо валідно», атака могла б експлуатувати невизначеність. Тому валідація — fail-closed. Ваші записи або підписані правильно й ланцюжок веде до DS батька, або вони вважаються недостовірними.

Це не предмет торгу й не «баг у резолверах». Це суть. Ваше завдання — зробити ротації нудними.

Дві ротації, які треба розрізняти: ZSK vs KSK

Багато команд переживуть помилку ротації ZSK з меншим радіусом ураження, бо зміни ZSK не потребують оновлення DS у батька (при умові, що KSK лишається стабільним і DNSKEY RRset підписано коректно). Ротації KSK, за визначенням, — ті, що вимагають координації з батьком.

Операційне правило великого пальця:

Ротація ZSK: ваша зона, ваші підписи, ваші TTL. Переважно під вашим контролем.
Ротація KSK: ваша зона та лінія DS у батька/реєстру, плюс кешування. Ви вже не єдина «доросла» сторона в кімнаті.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через хибні припущення

Середня SaaS-компанія вирішила мігрувати авторитетний DNS від одного провайдера до іншого. План включав зниження TTL, тестування парності записів і поступову зміну NS у реєстратора. Здавалося, хід дій — підручниковий — поки під час cutover не почався потік заявок до сапорту: «сайт впав», «не можу увійти», «пошта повертається».

На чергуванні почали з традиційних підозрюваних: балансири навантаження, WAF, TLS-сертифікати. Усе було зелене. Потім клієнт надіслав скриншот: SERVFAIL з резолвера їхнього ISP. Це звузило поле до DNS. У компанії власні офісні резолвери все ще працювали, бо їхні внутрішні рекурсивні резолвери були налаштовані без DNSSEC-валидації. War room витратив годину на суперечки, чи «DNSSEC взагалі важливий», бо «ми ніколи не мали проблем».

Хибне припущення було простим: команда думала, що DNSSEC «прикріплений до домену» у реєстратора й буде працювати після переміщення nameserver-ів. Насправді DS батька все ще вказував на DNSKEY старого провайдера. Новий провайдер відповідав іншим DNSKEY. Валідатори бачили DS, що не збігається з child DNSKEY, і відмовляли.

Виправлення теж було простим, але болісним операційно: або видалити DS (вимкнути DNSSEC), або опублікувати правильний DNSKEY і оновити DS під нього. Оновлення через UI реєстратора довго доходило до реєстру. У цей вікно кеші утримували помилковий стан. Веб був недоступний для частини інтернету; пошта стояла в черзі й потім доставлялась із запізненням, створюючи хвилю проблем у другорядних системах.

Action item постмортему, який мав значення, був не «будь обережним з DNSSEC». Це було: ставитися до міграцій хостингу DNS як до двофазного комміту з координацією DS. DNSSEC потрібно явно переносити, перевіряти і моніторити. Це не чекбокс; це ланцюг.

Міні-історія 2: Оптимізація, що відігралася навпаки

Команда підприємства прагнула зменшити операційне навантаження, автоматизувавши ротацію криптоключів. Вони встановили агресивний графік — часто міняти ключі DNSSEC, як по годиннику. Автоматизація була вражаюча: пайплайни, інтеграція з HSM, алерти якщо підписи відсутні. Команда пишалася. І треба було б пишатися. Потім прийшла реальність.

Перші ротації були лише ZSK і пройшли гладко. Потім хтось «оптимізував», включивши KSK-ротацію в ту саму автоматизацію. Скрипт згенерував нові ключі і запушив оновлені DNSKEY до авторитетного сервісу. Він також використовував API реєстратора для оновлення DS. Але API мав особливості: приймав DS-пейлоад у форматі, трохи відмінному від того, що видавав інструмент. API повернув успіх, але фактично зберіг некоректний DS. Зона стала bogus для валідувальних резолверів.

Найгірше було в таймінгу. Автомат працював ночами. Оновлення DS «успішно» за логами, а скрипт раніше видалив старий KSK, щоб зменшити «захаращення ключів». Валідація зламалась, і шлях відкату не був тривіальним, бо старий ключ вже повернули з HSM-слота, який використовувався системою. Все ще існувало, але відновлення вимагало оператора HSM і вікна змін. Публічний інтернет не виявив співчуття.

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

Міні-історія 3: Нудна практика, що врятувала день

Ритейлер з високим сезонним трафіком мав звичку, якою ніхто не хвалився: вони зберігали ранбуки з скриншотами UI реєстратора для DS, точними командами для обчислення DS з DNSKEY і календарем запланованих DNSSEC-подій. Також була постійна політика: не чіпати DNSSEC у періоди піку. Нудно. Правильно.

Одного ранку їхній DNS-провайдер мав проблему, що потребувала екстреної міграції на вторинні авторитетні nameserver-и, розміщені в іншому місці. Це могло стати кошмаром DNSSEC. Натомість команда вже мала попередньо опубліковану вторинну DNS-настройку, включно з підписаними зонами на обох провайдерах з однаковим KSK, і вони тестували валідацію тижнями раніше.

Під час інциденту вони поміняли NS у батька з мінімальним впливом TTL. Оскільки ключі та підписи DNSSEC залишились однаковими і DS лишився валідним, валідувальні резолвери ніколи не побачили зламаний ланцюг. Клієнти не спостерігали масових SERVFAIL. Пошта продовжувала текти. Єдиним реальним болем був сам процес зміни, а не вплив на клієнтів.

Урок: нудна операційна дисципліна перемагає креативність. Якщо ваш план DNSSEC спирається на «ми просто швидко виправимо», ви вже програли.

Швидкий план діагностики

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

Перший крок: визначте, чи це валідація DNSSEC (не просто DNS)

Запитайте з DNSSEC і подивіться на SERVFAIL від валідувального резолвера.
Порівняйте з невалідуючим шляхом (або явно вимкніть перевірку в запиті), щоб підтвердити: записи існують, але валідація не проходить.
Перевірте точку ланцюга, в якій відбувається провал: це підписи дитини, DNSKEY чи DS у батька?

Другий крок: підтвердіть, чи DS у батька відповідає child DNSKEY

Отримайте DS з погляду батька.
Отримайте DNSKEY з авторитетних серверів дитини.
Обчисліть DS з DNSKEY і порівняйте.

Третій крок: вирішіть аварійну тактику

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

Жарт №2: DNS — це телефонний довідник, DNSSEC — нотаріус. Якщо нотаріус оголосив страйк, ніхто не зможе зателефонувати нікому.

Практичні завдання: команди, виводи та рішення (12+)

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

Task 1: Check if a validating resolver returns SERVFAIL

cr0x@server:~$ dig +dnssec www.example.com A @1.1.1.1

; <<>> DiG 9.18.24 <<>> +dnssec www.example.com A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1203
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 42 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Feb 04 10:12:01 UTC 2026
;; MSG SIZE  rcvd: 56

Що це означає: Валідувальний публічний резолвер не може надати відповідь. SERVFAIL узгоджується з DNSSEC bogus, але також може бути наслідком апстрім-помилок.

Рішення: Негайно протестуйте з другого валідувального резолвера, потім порівняйте з невалідуючим шляхом.

Task 2: Compare against another validating resolver to rule out a single resolver issue

cr0x@server:~$ dig +dnssec www.example.com A @8.8.8.8

; <<>> DiG 9.18.24 <<>> +dnssec www.example.com A @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5550
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 31 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

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

Рішення: Запитайте авторитетні сервери безпосередньо, щоб перевірити, чи записи існують і чи є DNSKEY/RRSIG.

Task 3: Query authoritative nameserver directly for the record

cr0x@server:~$ dig www.example.com A @ns1.dns-provider.net +norecurse

; <<>> DiG 9.18.24 <<>> www.example.com A @ns1.dns-provider.net +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2086
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10

Що це означає: Авторитетний сервер має запис і відповідає NOERROR. Отже «DNS існує». Проблема ймовірно в валідації (ланцюг/signatures), а не у відсутності записів.

Рішення: Далі отримайте DNSKEY і підписи з авторитетного сервера.

Task 4: Fetch DNSKEY from authoritative and verify it’s being served

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse

; <<>> DiG 9.18.24 <<>> example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3919
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 300 IN DNSKEY 257 3 13 ( ...KSK_PUBLIC_KEY... ) ; key id = 20345
example.com. 300 IN DNSKEY 256 3 13 ( ...ZSK_PUBLIC_KEY... ) ; key id = 48711
example.com. 300 IN RRSIG DNSKEY 13 2 300 20260212000000 20260201000000 20345 example.com. ( ... )

Що це означає: DNSKEY RRset присутній і підписаний (RRSIG над DNSKEY існує). Значення key id/key tag важливі для порівняння з DS.

Рішення: Порівняйте DS у батька з KSK (flag 257) дайджестом. Якщо DS не збігається — знайдено «ядерну» проблему.

Task 5: Fetch DS from the parent view

cr0x@server:~$ dig example.com DS @a.gtld-servers.net +norecurse

; <<>> DiG 9.18.24 <<>> example.com DS @a.gtld-servers.net +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6421
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 86400 IN DS 14567 13 2 8A1C5F2D1B3E1B4C4F...C0FFEE

Що це означає: Батько (TLD) публікує DS з key tag 14567. Якщо ваш поточний KSK key tag — 20345, це невідповідність викликає підозру (не завжди автоматично означає помилку, але часто таке і є).

Рішення: Обчисліть DS з KSK, який ви подаєте, і порівняйте дайджест/ключовий тег.

Task 6: Compute DS from DNSKEY and compare with parent DS

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +short > /tmp/example.com.dnskey
cr0x@server:~$ dnssec-dsfromkey -2 /tmp/example.com.dnskey
example.com. IN DS 20345 13 2 3B7F2E0B7C7C0C2B7A...BADA55

Що це означає: DS, який ви обчислили з поточного KSK (20345), не збігається з DS у батька (14567 … C0FFEE). Це зламаний ланцюг довіри.

Рішення: Або відновіть старий KSK/DNSKEY, що відповідає DS у батька, або оновіть DS у батька на нове значення. Вибирайте залежно від того, що можна зробити швидше й безпечніше.

Task 7: Prove the zone is “bogus” using a validator tool (Unbound)

cr0x@server:~$ unbound-host -D example.com

example.com has address 203.0.113.10 (secure)
example.com has no AAAA record (secure)

Що це означає: Якщо ви бачите (secure), валідація пройшла. Якщо ви бачите (bogus) або помилки щодо DS/DNSKEY — у вас відмова DNSSEC.

Рішення: Якщо bogus: фокусуйтеся на DS/DNSKEY/підписах. Якщо secure, але проблеми лишаються: маєте іншу DNS або прикладну проблему.

Task 8: Check for missing or expired signatures on key records

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse | sed -n '/RRSIG DNSKEY/,$p'

example.com. 300 IN RRSIG DNSKEY 13 2 300 20260212000000 20260201000000 20345 example.com. ( ... )

Що це означає: RRSIG має час закінчення і початку дії. Якщо expiration вже в минулому (або inception у майбутньому через зсув годинника при підписуванні), валідатори відхиляють підпис.

Рішення: Якщо підписи прострочені/ще не дійсні: запустіть повторне підписування з правильним часом і впевніться в синхронізації годинників підписувача.

Task 9: Check SOA serial and propagation across authoritative nameservers

cr0x@server:~$ for ns in ns1.dns-provider.net ns2.dns-provider.net; do dig example.com SOA @$ns +norecurse +short; done
ns1.dns-provider.net. hostmaster.example.com. 2026020401 3600 600 1209600 300
ns1.dns-provider.net. hostmaster.example.com. 2026020309 3600 600 1209600 300

Що це означає: Різні SOA serial-значення вказують на несумісні версії зони між авторитетними серверами. З DNSSEC, невідповідність може бути фатальною, якщо підписи/ключі різняться.

Рішення: Зупиніть розгортання, виправте розповсюдження зони/AXFR/CI пайплайн і впевніться, що всі auth-сервери віддають однакові DNSKEY і підписані RRset, перед тим як чіпати DS.

Task 10: Check if resolvers are getting truncated responses (TCP fallback issues)

cr0x@server:~$ dig +dnssec example.com DNSKEY @1.1.1.1

;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53026
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: DNSKEY-відповіді можуть бути великими. Транкація — нормальна; fallback на TCP має працювати. Якщо фаєрволи блокують TCP/53, валідатори можуть падати.

Рішення: Якщо підозрюєте, що TCP/53 блокується між резолверами і вашими авторитетними серверами — перевірте політику мережі і дозвольте TCP/53.

Task 11: Validate MX resolution from a validating resolver

cr0x@server:~$ dig +dnssec example.com MX @9.9.9.9

; <<>> DiG 9.18.24 <<>> +dnssec example.com MX @9.9.9.9
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49990
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: Маршрутизація пошти порушена. Навіть якщо ваш поштовий провайдер здоровий, відправники не можуть знайти, куди надсилати пошту.

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

Task 12: Check SPF and DMARC TXT resolution (deliverability side-effects)

cr0x@server:~$ dig +dnssec example.com TXT @1.1.1.1 +short
cr0x@server:~$ dig +dnssec _dmarc.example.com TXT @1.1.1.1 +short

Що це означає: Порожній вивід з SERVFAIL (бачно у повному виводі) означає, що політичні записи недоступні. Деякі відправники трактують це як тимчасову помилку; інші знижують рівень примусового застосування; деякі відкладають доставку.

Рішення: Якщо DNSSEC зламаний — виправлення валідації має пріоритет. Не «налаштовуйте DMARC» під час криптографічної авариї.

Task 13: Confirm DS state via WHOIS-like tool output is not enough—use DNS

cr0x@server:~$ dig example.com DS +trace

; <<>> DiG 9.18.24 <<>> example.com DS +trace
.			518400	IN	NS	a.root-servers.net.
...
com.			172800	IN	NS	a.gtld-servers.net.
...
example.com.		86400	IN	DS	14567 13 2 8A1C5F2D1B3E1B4C4F...C0FFEE

Що це означає: +trace показує шлях делегації і DS, що реально опублікований у DNS, а не те, що стверджує панель управління.

Рішення: Трактуйте DNS як істину. Якщо панель суперечить — ескалюйте до реєстратора/реєстру та додайте trace-вивід. Не продовжуйте ротації ключів у цей час.

Task 14: For BIND operators—check signing status and key publication locally

cr0x@server:~$ rndc signing -list example.com
Done signing with key 20345/RSASHA256
Done signing with key 48711/RSASHA256

Що це означає: BIND вважає, що зона підписана певними ключами. Якщо це не збігається з тим, що подає авторитет, — розгортання неконсистентне.

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

Типові помилки: симптом → корінь → виправлення

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

1) Symptom: SERVFAIL on validating resolvers; authoritative answers directly

Корінь: DS не відповідає child KSK DNSKEY (або DNSKEY RRset підписано неправильно).

Виправлення: Обчисліть DS з активного KSK і оновіть батька. Або відновіть попередній KSK/DNSKEY, що відповідає опублікованому DS. Не гадати — порівняйте дайджести.

2) Symptom: Works for some users, fails for others, flips over hours

Корінь: Кешування й різні TTL; неконсистентні авторитетні сервери; деякі резолвери закешували старі DS/DNSKEY.

Виправлення: Упевніться, що всі авторитетні сервери подають однакові підписані дані і ключі. Зачекайте TTL. В аварійному режимі — швидко відновіть ланцюг; потім дайте кешам зійтися.

3) Symptom: DNSKEY queries are slow or time out; lots of TCP retries

Корінь: UDP-фрагментація або заблокований TCP/53; великі відповіді DNSSEC; middlebox-и неправильно обробляють EDNS.

Виправлення: Дозвольте TCP/53 до авторитетних серверів. Налаштуйте розмір відповіді через EDNS. Уникайте мережевих політик, що ставлять під сумнів TCP/53.

4) Symptom: Suddenly bogus after a “routine” resign

Корінь: Зсув годинника підписувача або некоректні вікна валідності підписів, що роблять RRSIG недійсними.

Виправлення: Виправте NTP. Перепідпишіть. Перевірте часи RRSIG з авторитету за допомогою dig.

5) Symptom: Email bounces or defers while web seems “mostly fine”

Корінь: MX і TXT-запити падають для валідувальних резолверів; веб-клієнти можуть використовувати кеш або невалідуючі резолвери; MTA суворіші щодо повторних помилок.

Виправлення: Перевіряйте MX/TXT спеціально з основних валідувальних резолверів. Комунікуйте очікування затримок. Виправте ланцюг DNSSEC.

6) Symptom: Outage immediately after DNS provider migration

Корінь: DS все ще вказує на ключ старого провайдера; новий провайдер подає інші DNSKEY.

Виправлення: Плануйте міграції з урахуванням DNSSEC: або зберігайте KSK стабільним між провайдерами (якщо підтримується), або координуйте оновлення DS як крок cutover з валідаційними шлюзами.

7) Symptom: Zone is secure, but only a specific record type fails (e.g., TXT)

Корінь: Селективне підписування або зламаний NSEC/NSEC3 для доказу відсутності; або неконсистентне підписування для конкретного RRset на різних нодах.

Виправлення: Переконайтеся, що RRset має RRSIG і що докази відсутності послідовні. Перепідпишіть зону повністю; забезпечте консистентне розгортання.

8) Symptom: Panel shows DS updated, but trace still shows old DS

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

Виправлення: Використовуйте dig +trace як істину. Ескалюйте до реєстратора, додайте trace-вивід. Не продовжуйте крутити ключі в очікуванні.

Контрольні списки / покроковий план

План аварійного відкату (коли ви вже вогні)

Підтвердіть відмову валідації DNSSEC з двома валідувальними резолверами за допомогою dig +dnssec.
Запитайте авторитетні сервери безпосередньо, щоб підтвердити, що записи існують, і ізолювати валідацію.
Порівняйте DS і DNSKEY за допомогою dnssec-dsfromkey і запиту DS у батька.
Виберіть найшвидший безпечний шлях ремонту:
- Якщо у вас ще є старий KSK і ви можете його подати: перепублікуйте його і його підписи так, щоб він відповідав DS у батька.
- Якщо DS у батька можна оновити швидко і надійно: оновіть DS на новий KSK дайджест і перевірте через dig +trace.
- Якщо ніщо не є швидким: видаліть DS, щоб тимчасово вимкнути DNSSEC, задокументуйте рішення і сплануйте повторне увімкнення.
Проведіть валідацію після зміни за допомогою unbound-host -D або еквіваленту та кількох публічних резолверів.
Моніторьте черги пошти і повторні спроби. Очікуйте відкладеної доставки навіть після фікса через поведінку повторних спроб відправників.

Планована ротація KSK: нудний, але правильний runbook

Інвентаризуйте залежності: метод оновлення DS у реєстратора, часи реєстру, можливості DNS-провайдера, чи використовуєте CDS/CDNSKEY автоматизацію, і хто має доступ.
Знизьте TTL заздалегідь для DNSKEY і релевантних RRset, якщо платформа це безпечно підтримує. Робіть це за дні, а не хвилини до події.
Попередньо опублікуйте новий KSK (додайте новий DNSKEY поряд зі старим). Старий не видаляйте.
Підпишіть DNSKEY RRset коректно, щоб валідатори могли довіряти новому ключу, коли DS зміниться.
Обчисліть DS для нового KSK і нехай друга людина перевірить key tag, алгоритм, тип дайджесту і шістнадцятковий дайджест.
Оновіть DS у батька і відстежуйте реальну публікацію у DNS через dig +trace.
Чекайте через TTL і вікна поширення. Це не бюрократія; це фізика кешування.
Лише потім видаляйте старий KSK, коли впевнені, що новий DS універсально опублікований і валідація стабільна по резолверах.
Перевірка після ротації: валідуйте A/AAAA, MX, TXT, DNSKEY і неіснуюче ім’я (щоб протестувати NSEC/NSEC3) з кількох валідувальних резолверів.

Планована ротація ZSK: тримайте її рутинною

Попередньо опублікуйте новий ZSK у DNSKEY RRset.
Почніть підписувати обома ZSK (double-sign) під час переходу, якщо це підтримується.
Після того, як кеші збросяться, припиніть підписування старим ZSK.
Видаліть старий ZSK після безпечної затримки.

Питання й відповіді (FAQ)

1) Чому помилка DNSSEC відображається як SERVFAIL замість NXDOMAIN?

SERVFAIL означає, що резолвер не зміг сформувати дійсну відповідь. У DNSSEC «я отримав дані, але вони не піддались валідації» трактують як відмову, а не як «ім’я не існує». NXDOMAIN — це підписана заява про неіснування; SERVFAIL — «я тут ні за що не ручаюся».

2) Якщо я вимкну DNSSEC, видаливши DS, чи все одразу відновиться?

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

3) Чому веб і пошта падають одночасно?

Вони використовують ту саму DNS-зону. Веб потребує A/AAAA. Пошта потребує MX і зазвичай TXT для SPF/DMARC. Якщо валідувальні резолвери не можуть резолвити будь-що через bogus DNSSEC, обидва канали деградують одночасно.

4) Це тільки проблема ротації KSK?

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

5) Чи можна покладатися на «автоматичний DNSSEC» мого DNS-провайдера?

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

6) CDS/CDNSKEY — чи це може запобігти помилкам DS?

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

7) Як тестувати як клієнт, а не інженер з осоібними резолверами?

Використовуйте кілька публічних валідувальних резолверів і тестуйте з мереж, які ви не контролюєте (або принаймні різні рекурсивні стеки). Тестуйте також веб- і поштові записи: A/AAAA, MX, TXT і DNSKEY.

8) Чому пошта продовжувала падати після того, як DNS виправили?

Бо пошта — це store-and-forward. Відправники роблять повторні спроби при тимчасових помилках з backoff-логікою. Коли DNS знову працює, черги дренуються години. Якщо інцидент був довгим, деякі відправники могли припинити спроби або досягти лімітів черг.

9) Який найнадійніший «break glass» крок?

Найшвидший безпечний крок зазвичай — відновити останній відомо-гарний DNSKEY/набір підписів, що відповідає поточному опублікованому DS. Видалення DS вимикає DNSSEC і може допомогти, але це регресія в безпеці і має бути тимчасовою та документованою.

10) Як уникнути ефекту «в мене працює» під час інцидентів DNSSEC?

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

Наступні кроки, які можна зробити цього тижня

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

Зробіть валідацію видимою всередині: запустіть принаймні один валідувальний резолвер, якому ви довіряєте, і додайте однолайнерну перевірку в інструменти інцидентів на кшталт dig +dnssec проти нього.
Напишіть ваш DNSSEC ранбук: включіть метод оновлення DS, як обчислювати DS з DNSKEY, імена авторитетних серверів і варіанти відкату.
Практикуйтесь у непроизводчій зоні: зробіть повну репетицію KSK-ротації, де ви дійсно оновлюєте DS у батька і валідуєте через публічні резолвери.
Додайте моніторинг, що перевіряє статус «secure»: не лише «чи резолвиться A-record», а «чи резолвиться як secure з валідувальних резолверів».
Розділіть процеси ZSK і KSK: обертайте ZSK рутинно за потреби, а KSK ротуйте як планове обслуговування з явними шлюзами перевірки.
Припиніть міграції DNS без плану DNSSEC: якщо в плані проекту немає згадки про DS — план неповний.

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

Схожі статті

DNSSEC відмовляє випадково: налагодження помилок валідації без паніки