DNS «bogus/validation failed»: практичне усунення проблем DNSSEC у провайдера

Що насправді означає «bogus/validation failed»

«Bogus» — це не настрій. Це вердикт. Валідуючий резолвер має криптографічні докази того, що відповідь, яку він отримав, не відповідає тому, що підписав власник зони, або що резолвер не може побудувати довірений ланцюжок від кореня до запису, який ви запитали.

Ця різниця важлива:

• «Insecure» означає «DNSSEC відсутній у цій зоні». Резолвер повертає відповіді як звичайно.
• «Secure» означає «валідовано». Резолвер повертає відповіді як звичайно.
• «Bogus» означає «валідація не пройшла». Резолвер повертає SERVFAIL, бо повернення недовірених даних підриває сенс DNSSEC.

Валідація DNSSEC не відпрацьовує з кількох причин, які згортаються в дві групи:

1. Розриви ланцюга довіри: неправильний/відсутній DS, невідповідність DNSKEY, невдалі rollover ключів, неправильний алгоритм, невірний key tag, відсутні підписи, некоректні докази NSEC/NSEC3.
2. Проблеми реальності: зсув часу, усічення UDP + невдала відкатка на TCP, середні пристрої, що ламають EDNS0, некоректні налаштування резолверів, кеші з застарілими даними під час rollover.

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

Парафраз ідеї від Werner Vogels (надійність та експлуатація): Все ламається, і ваше завдання — проектувати та експлуатувати, ніби це норма.

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

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

Це порядок дій, який найбільш швидко приведе вас до справжнього вузького місця з мінімальними маневрами. Дотримуйтеся його. Блукання випадковими резолверами о 3-й ночі — шлях до дебагу вашого власного Wi‑Fi.

1) Підтвердьте, що проблема пов’язана з DNSSEC (а не загальний збій DNS)

• Запитайте відомий валідуючий резолвер і відомий невалідувальний резолвер.
• Якщо домен працює без валідації, але падає з валідацією — ви у світі DNSSEC.

2) Визначте, де розривається ланцюг довіри

• Перевірте DS у батьківській зоні.
• Перевірте DNSKEY у дочірній зоні.
• Перевірте, чи існують RRSIG і чи в межах вони вікон дійсності.

3) Швидко виключіть «проблеми реальності»

• Синхронізація часу на резолверах (timedatectl), MTU/фрагментація, усічення UDP, проблеми з EDNS0.
• Переконайтеся, що ваш резолвер не застряг на застарілих trust anchors або не кешує старі набори DNSKEY.

4) Застосуйте безпечну міру пом’якшення, поки виправляєте upstream

• Якщо ви керуєте валідуючими резолверами для користувачів: використовуйте Negative Trust Anchor (NTA) для постраждалої зони, щоб тимчасово відновити доступність.
• Якщо ви — власник зони: виправте DS/DNSKEY і підписи коректно; не «вимикайте DNSSEC» просто так, якщо не можете чисто видалити DS спочатку.

Правило рішення: Якщо ви не можете виправити корінь проблеми за 30 хвилин, а це впливає на клієнтів — пом’якшіть. Потім виправте правильно.

Факти та історія, що важливі під час інцидентів

1. DNSSEC було специфіковано наприкінці 1990-х, але широке впровадження зайняло роки через операційну складність, що переважала криптографію в реальному житті.
2. Коренева зона була підписана в 2010 році, що зробило валідацію «від кінця до кінця» практичною в масштабі — до того доводилося вручну збирати trust anchors.
3. DS запис живе в батьківській зоні (наприклад .com), отже ваш реєстратор є частиною межі безпеки, подобається вам це чи ні.
4. Ротація ключів — це шаблон №1 людських помилок у DNSSEC: таймінг, кешування і деталі «який ключ що підписує» мають значення.
5. Агілність алгоритмів — реальна: старі алгоритми (наприклад RSA/SHA-1) стали неприйнятними; міграція алгоритмів може зламати валідатори при необережності.
6. NSEC3 існує здебільшого через побоювання zone walking; він також додає складності й має власні режими відмов (помилки зі сіллю/ітераціями не сприяють відмовостійкості).
7. EDNS0 дозволив більші DNS-відповіді через UDP; одночасно це породило клас проблем «middlebox ламає DNS», які проявляються як відмови DNSSEC.
8. Був великий root KSK rollover (2018), який виявив, скільки резолверів були неправильно налаштовані або застарілі — наочний урок з операційної гігієни.
9. Деякі резолвери за дизайном відмовляються «закрито»: коли валідація не пройшла, вони обирають відмову замість потенційної підміни кешу. Саме в цьому суть, але це змінює ваш план реагування на інцидент.

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

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

Завдання 1 — Побачити симптом, видимий користувачу: SERVFAIL проти NOERROR

cr0x@server:~$ dig +noall +comments +answer www.example.com A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12014

Значення: Резолвер не зміг надати відповідь, якій довіряє. Це не обов’язково NXDOMAIN; можливо, валідація DNSSEC, таймаут upstream або збій рекурсії.

Рішення: Негайно порівняйте з іншим резолвером і з поведінкою без валідації, щоб підтвердити, що це валідація.

Завдання 2 — Порівняйте валідуючі й невалідувальні резолвери

cr0x@server:~$ dig +noall +answer www.example.com A @8.8.8.8
www.example.com. 300 IN A 93.184.216.34
cr0x@server:~$ dig +noall +comments +answer www.example.com A @9.9.9.9
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5112

Значення: Різні резолвери — різні результати. Це часто вказує на відмінності в валідації DNSSEC, стан кешів або транспортні особливості.

Рішення: Перейдіть до DNSSEC-специфічних запитів (+dnssec, delv) і перевірте ланцюг DS/DNSKEY.

Завдання 3 — Запитайте DNSSEC-записи і подивіться на біт AD

cr0x@server:~$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN RRSIG A 13 3 300 20260101000000 20251201000000 12345 example.com. ...

Значення: ad вказує, що резолвер валідовано відповідь. Якщо ви ніколи не бачите ad від валідуючого резолвера, можливо, він не валідуює або не може валідувати.

Рішення: Якщо ваш резолвер не ставить AD, а публічні резолвери ставлять, налагодьте конфігурацію резолвера / trust anchors першочергово.

Завдання 4 — Використайте delv для пояснення від валідатора

cr0x@server:~$ delv www.example.com A
; fully validated
www.example.com. 300 IN A 93.184.216.34

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

Рішення: Якщо delv каже «fully validated», але ваш продакшн-резолвер повідомляє bogus, підозрюйте стан кешу, зсув часу або проблеми в ПЗ резолвера.

Завдання 5 — Зловіть реальну причину відмови DNSSEC у delv

cr0x@server:~$ delv broken.example A
; validation failed: no valid signature found
; resolution failed: DNSSEC validation failure

Значення: Зона відповіла, але підписи не пройшли перевірку проти DNSKEY, або потрібного RRSIG немає/він минув.

Рішення: Перевірте набір DNSKEY і часові вікна RRSIG; дивіться на невдалий rollover або перерву в підписуванні.

Завдання 6 — Перевірте DS у батька (контрольна точка ланцюга довіри)

cr0x@server:~$ dig +noall +answer example.com DS @a.gtld-servers.net
example.com. 86400 IN DS 12345 13 2 8B4F...A1C9

Значення: Батько публікує DS, що вказує на DNSKEY дочірньої зони (за key tag, алгоритмом, дайджестом).

Рішення: Якщо DS існує, але DNSKEY дочірньої не відповідає — буде bogus. Виправте DS (у реєстратора/батька) або відновіть ключі в дочірній зоні так, щоб вони збігалися з DS.

Завдання 7 — Перевірте DNSKEY у дочірній зоні

cr0x@server:~$ dig +noall +answer example.com DNSKEY @ns1.example.net
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN DNSKEY 256 3 13 AwEAAc9...ZSK...

Значення: Ви маєте бачити принаймні один KSK (flag 257) і один ZSK (256) для типових налаштувань. Алгоритми мають збігатися з DS.

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

Завдання 8 — Перевірте час у RRSIG (прості випадки — прострочені підписи)

cr0x@server:~$ dig +dnssec +noall +answer example.com SOA @ns1.example.net
example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 3600
example.com. 3600 IN RRSIG SOA 13 2 3600 20251231120000 20251201000000 12345 example.com. ...

Значення: RRSIG має час початку й закінчення дії. Якщо ваш процес підписування зламався, підписи минуть — і валідатори почнуть падати.

Рішення: Якщо підписи прострочені/майже прострочені — терміново виправте автоматизацію підписування і повторно підпишіть зону. Якщо часи «в майбутньому», перевірте зсув годин на авторитетних серверах або на підписувачі.

Завдання 9 — Перевірте час на вашому резолвері (так, досі)

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-31 02:21:10 UTC
           Universal time: Wed 2025-12-31 02:21:10 UTC
                 RTC time: Wed 2025-12-31 02:21:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active

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

Рішення: Якщо синхронізація часу некоректна — виправте NTP/chrony перед тим, як чіпати налаштування DNSSEC. Не «дебагуйте криптографію» при некоректному годиннику.

Завдання 10 — Читайте логи Unbound за конкретною помилкою

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 20
... unbound[1123]: info: validation failure <example.com. A IN>: no keys have a DS with algorithm 13
... unbound[1123]: info: resolving example.com. A
... unbound[1123]: info: error: SERVFAIL example.com. A IN

Значення: Цей рядок — золото: він каже, що резолвер очікував відповідності між DS і алгоритмом, якої немає.

Рішення: Перевірте алгоритм DS у батька і алгоритм DNSKEY у дитини. Це часто ботчений rollover алгоритму або застарілий DS.

Завдання 11 — Читайте логи BIND (named) для «bogus» і ID ключів

cr0x@server:~$ sudo journalctl -u named --since "10 min ago" | tail -n 30
... named[905]: validating example.com/A: no valid signature found
... named[905]: resolving example.com/A: got insecure response; treating as bogus

Значення: BIND дає схожу картину. «No valid signature found» часто означає відсутній/прострочений RRSIG або невірний набір DNSKEY.

Рішення: Підтвердіть наявність RRSIG і їхню дійсність від авторитетних серверів безпосередньо. Якщо відсутні — виправте підписування. Якщо присутні — шукайте невідповідність між DNSKEY і тим, ким підписано RRSIG.

Завдання 12 — Запитуйте авторитетні сервери напряму (обхід рекурсії)

cr0x@server:~$ dig +norecurse +dnssec example.com DNSKEY @ns1.example.net
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 20251231120000 20251201000000 12345 example.com. ...

Значення: aa підтверджує, що сервер авторитетний і повернув підписані DNSKEY. Якщо авторитетний сервер не містить RRSIG/DNSKEY — у вас проблема з підписуванням або публікацією.

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

Завдання 13 — Перевірте усічення й відкатку на TCP

cr0x@server:~$ dig +dnssec +noall +comments example.com DNSKEY @ns1.example.net +bufsize=512
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39011
;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Значення: tc означає усічену UDP-відповідь. Резолвер має повторити через TCP. Якщо TCP блокується — відновлення може не відбутися і валідація загадково впаде.

Рішення: Переконайтеся, що TCP/53 дозволений до авторитетних серверів і від резолверів. Якщо ви часто бачите tc, подумайте про розмір відповідей (менше ключів, правильна гігієна rollover) і MTU-шлях.

Завдання 14 — Підтвердьте TCP/53-з’єднуваність, коли UDP усічено

cr0x@server:~$ dig +tcp +dnssec +noall +answer example.com DNSKEY @ns1.example.net
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN DNSKEY 256 3 13 AwEAAc9...ZSK...

Значення: Якщо TCP працює, а UDP усічено — мережа має дозволяти fallback на TCP. Деякі «засоби безпеки» ламають це й називають фічею.

Рішення: Якщо TCP блокується — змініть політику фаєрвола. Не вимикайте DNSSEC, щоб пристосуватися до сломаного middlebox.

Завдання 15 — Використайте Negative Trust Anchor (NTA) в Unbound для пом’якшення

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 2
modules: 2 [ subnetcache validator iterator ]
uptime: 86400 seconds
options: control(ssl)
cr0x@server:~$ sudo unbound-control neg_anchor_add example.com
ok
cr0x@server:~$ sudo unbound-control list_neg_anchors
example.com

Значення: Ви повідомили валідатору, щоб тимчасово трактувати цю зону як insecure, обходячи помилки валідації DNSSEC для неї.

Рішення: Використовуйте це лише як обмежену тимчасову міру. Створіть завдання на видалення NTA після виправлення upstream. Додайте моніторинг, щоб це не жило вічно.

Завдання 16 — Промийте кеш резолвера після upstream-виправлень (обережно)

cr0x@server:~$ sudo unbound-control flush_zone example.com
ok

Значення: Старі DNSKEY/DS/негативні кеш-записи можуть продовжувати підтримувати збій після того, як upstream виправлено.

Рішення: Очищайте лише постраждалу зону, якщо можливо. Повне очищення кешу в години піку — самостійний DDoS проти вашого upstream.

Жарт №1: Збої DNSSEC — відмінний спосіб єднання команди: ви всі будете мовчки дивитися на одні й ті самі шістнадцяткові рядки, сумнівно оцінюючи свої рішення в житті.

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

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

Компанія мала чітке розуміння меж власності: команда додатка відповідає за додаток, платформа — за Kubernetes, мережа — за DNS. Домен керувався маркетингом через аккаунт у реєстратора, в який ніколи не заходив жоден інженер. Це здавалося нормальним, бо авторитетний DNS хостився у відомого провайдера і «DNSSEC увімкнено».

Потім задачка оновлення сертифіката почала падати. Не через ACME, а тому, що воркер поновлення не міг послідовно резолвити endpoint API DNS-провайдера. Іноді з ноутбуків працювало, іноді не працювало в продакшені. У каналі інциденту з’явилися звичні підозри: NAT-шлюзи, egress-фаєрволи, VPC-резолвер, «можливо IPv6».

Хибне припущення було тонким: «Якщо DNS-провайдер здоровий, значить DNSSEC теж в порядку». Насправді DS у батьківській зоні було змінено під час робочого процесу «підвищення безпеки» у реєстратора. Ніхто цього не помітив, бо авторитетний DNS продовжував віддавати записи нормально, а невалідувальні резолвери й далі резолвили. Лише валідуючі резолвери почали повертати SERVFAIL.

Вони довели це, запитавши DS з TLD-серверів і порівнявши з набором DNSKEY. DS вказував на key tag, який більше не існував. Зона була підписана, провайдер був у порядку, але ланцюг довіри був порушений на рівні реєстратора. Виправлення не вимагало геройського інженерного подвигу — потрібно було зайти в аккаунт реєстратора, виправити DS так, щоб збігався з поточним KSK, і дочекатися осадження кешів.

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

Міні-історія 2: Оптимізація, що обернулася проти

Платформна команда хотіла зменшити латентність DNS і залежність від зовнішніх сервісів. Розумно. Вони розгорнули локальні валідуючі резолвери на кожному node pool і примусили піди їх використовувати. Також вони посилили фаєрволи, бо «навіщо DNS потрібен по TCP?». У їхній моделі загроз TCP/53 виглядав підозрілим.

Через кілька місяців домен партнера змінив ключі і тимчасово став віддавати більшу відповідь DNSKEY. По UDP вона часто усікалась. Локальні резолвери пробували повторити через TCP. Фаєрвол блокував. Валідація сипалася періодично, і оскільки резолвери були локальні, радіус ураження був великий: всі робочі навантаження на тому node pool бачили спорадичні відмови доступу до API партнера.

On-call годинами ганявся за «випадковою нестабільністю мережі», бо графіки втрат пакетів були в нормі, а авторитетні DNS-сервери доступні по UDP. Підказка була в логах резолвера: повторювана усічення та невдачі TCP-повторів, за якими слідувала bogus валідація і SERVFAIL.

Помилкою не було мати локальні резолвери; це було хорошою практикою. Помилкою було припустити, що DNS — це тільки UDP, і трактувати TCP як опціональний. DNSSEC робить великі відповіді більш поширеними. Усічення — нормальне явище. Відкат на TCP — не розкіш, а необхідність.

Вони виправили це, дозволивши TCP/53 egress, і додали канарчу перевірку, яка спеціально тестує запит DNSKEY по TCP з кожного кластера. Ця перевірка виявила наступну зміну фаєрвола до її деплою.

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

Інша організація керувала своїм авторитетним DNS з окремим пайплайном підписування. Нічого особливого. Але у них була одна нудна річ: кожна зміна DNSSEC вимагала префлайту, який порівнював DS, DNSKEY і дійсність RRSIG з трьох незалежних мереж. Не просто «в моєму ноуті резолвиться», а реальна валідація.

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

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

Жодного збою. Жодної драми. Корінь проблеми, що ніколи не став інцидентом, був «ми припустили, що поширення однорідне». Так ним не є. Їхня нудна практика перетворила непередбачуваний інтернет на контрольований процес розгортання.

Жарт №2: Інтернет не робить «однорідного поширення», він робить «згодом, але з думками».

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

1) Симптом: Деякі резолвери повертають NOERROR, інші — SERVFAIL

Корінна причина: Різниця у валідації DNSSEC (один валідуючий, інший ні), або кеші перебувають у різних станах під час rollover.

Виправлення: Використайте delv і dig +dnssec для підтвердження валідації. Перевірте відповідність DS і DNSKEY. Після виправлення upstream промийте постраждалі зони на своїх резолверах.

2) Симптом: Все поламалося відразу після «вимкнення DNSSEC»

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

Виправлення: Видаліть DS у реєстратора/батька спочатку (або одночасно), продовжуйте віддавати DNSKEY/RRSIG поки DS не зникне, потім вимикайте підписування.

3) Симптом: Unbound каже «no keys have a DS with algorithm X»

Корінна причина: Несумісність алгоритму/дайджесту DS з опублікованими DNSKEY; часто після алгоритмічного rollover або помилкового оновлення DS.

Виправлення: Перерахувати DS з відповідного KSK і опублікувати правильний DS у батька. Переконайтеся, що дитина публікує цей KSK.

4) Симптом: «no valid signature found», але DNSKEY існує

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

Виправлення: Повторно підпишіть зону; підтвердіть, що підписи охоплюють усі критичні RRset (SOA, NS, A/AAAA тощо). Перевірте синхронізацію часу на підписувачі та авторитетних серверах.

5) Симптом: Працює для малих запитів, падає на DNSKEY або ANY

Корінна причина: Усічення UDP плюс блокований TCP, або проблеми EDNS0/фрагментації, що призводять до невдач великих DNSSEC-відповідей.

Виправлення: Дозвольте TCP/53; перевірте шляховий MTU; уникайте надмірних відповідей, очищаючи застарілі ключі і не публікуючи непотрібний DNSKEY-багаж.

6) Симптом: Збій виглядає «випадковим» по різних сайтах

Корінна причина: Split-horizon DNS повертає різні DNSKEY/RRSIG залежно від джерела, або anycast-ноди несинхронні, або різні авторитетні набори за геополітикою.

Виправлення: Забезпечте узгодженість матеріалів DNSSEC на всіх авторитетних вузлах/edge. Уникайте split-horizon для підписаних зон, якщо ви точно не знаєте, що робите.

7) Симптом: Валідатори повідомляють «NSEC/NSEC3 proof failed» для NXDOMAIN

Корінна причина: Зламані негативні відповіді: відсутні/некоректні NSEC/NSEC3 записи або підписи під час збоїв підписування.

Виправлення: Повторно підпишіть зону і переконайтеся, що підписувач генерує коректні негативні докази. Перевірте, чи авторитетні сервери віддають однаковий ланцюжок NSEC/NSEC3.

8) Симптом: Лише ваші внутрішні резолвери падають; публічні резолвери працюють

Корінна причина: Ваші резолвери мають застарілі trust anchors, некоректну конфігурацію валідації, поганий форвардинг або зламану синхронізацію часу.

Виправлення: Перевірте конфіг резолвера, оновлення trust anchors, NTP і чи ви форвардите до резолвера, який обрізає DNSSEC-записи.

Чеклісти / покроковий план

Чекліст A — Ви оператор резолверів (керуєте валідуючими резолверами)

1. Підтвердьте, що тригер — DNSSEC: порівняйте результати з вашим резолвером і зовнішнім валідуючим резолвером за допомогою dig +dnssec і перевірте біт AD.
2. Зберіть докази: логи резолвера (Unbound/BIND), DS від батька, DNSKEY від дитини, часові вікна RRSIG для постраждалих RRset.
3. Виключіть локальне середовище: синхронізацію часу, доступність TCP/53, поведінку EDNS0, фрагментацію пакетів, чи форвардери обрізають записи.
4. Прийміть рішення про пом’якшення: Якщо бізнес-наслідок високий і upstream не фіксить негайно — додайте NTA з мінімальним охопленням (бажано точну зону, а не весь TLD).
5. Чітко комунікуйте: «У нас відмова валідації DNSSEC для зони X; вплив на сервіс; міра пом’якшення застосована; власник upstream повідомлений.» Не кажіть просто «DNS впав.»
6. Приберіть пом’якшення: після виправлення upstream і перевірки з кількох мереж; промийте кеш зони; видаліть NTA; підтвердіть повернення біт AD.

Чекліст B — Ви власник зони (контролюєте авторитетний DNS і DNSSEC)

1. Визначте тип відмови:
   • Якщо несумісність DS: DS у батька не збігається з KSK дитини.
   • Якщо відсутні/прострочені підписи: зламався пайплайн підписування або публікації.
   • Якщо транспорт: відповіді усікаються і TCP десь блокується.
2. Виправте коректність DS/DNSKEY першочергово: опублікуйте правильні ключі; оновіть DS; тримайте перехідний період при rollover; не видаляйте старі ключі занадто швидко.
3. Перевірте негативні відповіді: NXDOMAIN має бути підписано коректними NSEC/NSEC3 доказами.
4. Керуйте TTL як доросла людина: зниження TTL пришвидшить зміни, але також може збільшити навантаження і виявити нестійку поведінку резолверів під час інцидентів.
5. Координуйтеся з реєстратором: Зміни DS — це продакшн-зміни. Ставтеся до них як до продакшну.

Чекліст C — Ви застрягли, бо «upstream не фіксить швидко»

1. Локально пом’якшіть: NTA (Unbound) або еквівалентна політика обходу, де доречно.
2. Мінімізуйте радіус ураження: обходьте тільки постраждалу зону, а не вимикайте валідацію глобально.
3. Встановіть термін закінчення: календарне нагадування, тікет і алерт на моніторинг, якщо NTA лишається після дедлайну.
4. Ескалуйте з доказами: надайте виводи DS, DNSKEY і точне повідомлення про помилку валідатора. Постачальники реагують краще на докази, ніж на емоції.

FAQ

1) Що означає «bogus» у термінах DNSSEC?

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

2) Чому деякі резолвери все ще резолвлять «bogus» домен?

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

3) Чи вимикати DNSSEC на моєму резолвері — це гарна екстрена міра?

Як останній засіб, тимчасово, і лише при явному прийнятті ризику. Краще: застосуйте NTA для конкретної зони. Це відновить сервіс, залишивши DNSSEC для решти.

4) Ми «вимкнули DNSSEC» у зоні, але користувачі отримали більше відмов. Чому?

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

5) Як зсув часу може спричинити помилку валідації DNSSEC?

RRSIG має час початку й закінчення дії. Якщо годинник резолвера неправильний, дійсні підписи можуть виглядати «простроченими» або «ще не дійсними». Виправляйте NTP насамперед.

6) У чому різниця між DS і DNSKEY в операційному сенсі?

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

7) Чому TCP/53 важливий для DNSSEC?

DNSSEC додає підписи і ключі, що збільшує розмір відповідей. UDP може усікатися; резолвери повторюють через TCP. Якщо TCP/53 блокується, великі підписані відповіді можуть падати.

8) Чи потрібно промивати кеш резолверів після виправлення DNSSEC?

Зазвичай так, принаймні для постраждалої зони. Резолвери можуть кешувати DNSKEY, стан, пов’язаний з DS, і негативні відповіді. Віддавайте перевагу очищенню конкретних зон замість повного скидання кешу.

9) Який безпечний спосіб валідувати з кількох точок зору?

Запустіть delv або dig +dnssec мінімум з двох мереж (наприклад, ваш дата-центр і VM у хмарі) і порівняйте DS/DNSKEY та поведінку біта AD.

10) Якщо авторитетні сервери відповідають правильно, чому валідатори можуть падати?

Бо DS у батька може бути неправильним, або підписи можуть не проходити перевірку навіть якщо вони існують. Також проміжні транспортні проблеми можуть перешкодити валідаторам надійно отримати необхідні записи.

Висновок: наступні кроки щоб уникнути повторення

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

Зробіть це далі

1. Додайте DNSSEC-канарку, яка запускає delv (або еквівалент) проти критичних доменів з принаймні двох мереж і алертить про відмови валідації — не лише про NXDOMAIN/таймаут.
2. Документуйте власність DS: хто може змінювати DS у реєстратора, як проходить затвердження, як виконувати відкат. Якщо відповідь «маркетинг» — виправляйте оргструктуру або доступи.
3. Зробіть TCP/53 обов’язковим для резолверів. Якщо хтось хоче його блокувати — нехай доведе, що розуміє усічення і поведінку EDNS0 перш ніж міняти політику.
4. Практикуйте ротації ключів з процедурою, яка включає зовнішні перевірки і явні періоди перекриття. «Просто поміняємо ключі» — найшвидший шлях до нового інциденту.
5. Віддавайте перевагу таргетованим пом’якшенням (NTA на зону) замість глобального вимкнення валідації. Якщо мусите обійти — встановіть термін і алерт.

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