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

January 4, 2026 • February 3, 2026 • Читання: 6 хв • Views: 6

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

02:13. Половина вашого флоту може дістатися до API партнера; інша половина отримує SERVFAIL. Хтось каже «DNS не працює». Інший каже «це DNSSEC». Тягне перезавантажити резольвер і сподіватися, що ніхто не помітить.

Не робіть цього. «Випадкові» збої DNSSEC зазвичай детерміністичні. Вони виглядають випадково, бо різні резольвери, маршрути, кеші, MTU, годинники й стани ключів дають різні результати. Це польовий посібник для перетворення паніки на короткий список перевірок з командами, які ви можете виконати, поки інцидент-канал усе ще сперечається, чиї це зміни.

Що насправді означає «випадковий збій DNSSEC»

Валідація DNSSEC — це операція «так/ні»: або ланцюг довіри валідний для RRset у момент запиту, або ні. То чому це виглядає періодично?

Різні резольвери бачать різні дані. Стан кешу, негативне кешування, агресивний NSEC і попереднє отримання означають, що два резольвери можуть бути «правильними» й усе одно не погоджуватися хвилинами.
Різні шляхи по-різному обробляють великі UDP-пакети. Відповіді DNSSEC більші. EDNS0 збільшує розмір UDP-поля; деякі мережі втрачають фрагменти або блокують ICMP «Fragmentation needed». Результат: один клієнт робить повторний запит по TCP, інший — ні.
Час має значення. RRSIG має час початку й закінчення дії. Зсув годинника на валідаторі може перетворити дійсні підписи на «прострочені» або «ще не дійсні».
Різні стани довіри (trust anchor). Керовані довірчі якорі та поведінка RFC 5011 можуть спричиняти «працює тут, падає там» під час ротації ключів або після тривалої недоступності.
Відмінності в апстрімі. Якщо ваші резольвери пересилають запити на різні апстрими (або автоматично виявляють їх), ви можете порівнювати яблука з апельсином, який ще й у вогні.

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

Факти й історія, які важливі на практиці

Ось кілька конкретних пунктів, які не тривіальні — вони змінюють підхід до відлагодження:

Основні специфікації DNSSEC з’явилися у 2005 році (RFC 4033/4034/4035). Багато «успадкованих» інструментів DNS старіші за це й промовчують про важливе.
Корінь зони був підписаний у 2010 році. До того валідація закінчувалася на корені; після — зламаний ланцюг може поширюватися глобально.
Ролловери алгоритмів — реальні події, не теорія. DS-дайджести на базі SHA-1 (та старіші алгоритми) були виведені з використання; невідповідності часто виникають під час переходів.
DNSKEY і DS — це не те саме. DS знаходиться в батьківській зоні; DNSKEY — у дочірній. Якщо ви змінюєте ключі без оновлення DS, валідатори (правомірно) вважатимуть вашу зону «bogus».
Великі відповіді DNS історично були крихкими. DNS починався з 512-байтових UDP-відповідей; DNSSEC зробив «великі відповіді» звичайними, тому з’явився EDNS0 та більше fallback на TCP.
NSEC3 введено, щоб зменшити zone-walking. Це також ускладнює відповіді й збільшує їхній розмір; ви побачите це в доказах відсутності.
Деякі резольвери кешують рішення «bogus» на короткий час. Це може зробити коротку неправильну конфігурацію довшою, тому «ми виправили, але воно все ще падає» — реальна річ.
У 2018 році відбувся великий root KSK rollover. Він навчив усіх, що «керування довірчими якорями» — це експлуатаційна робота, а не галочка в списку.

Цитата, щоб не плекати ілюзій — інциденти карають за наївність:

«Надія — не стратегія.» — генерал Gordon R. Sullivan

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

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

1) Підтвердити, що це саме валідація DNSSEC (не звичайний DNS)

Візьміть одного клієнта, що падає, і одного відомо працездатного клієнта.
Запитайте один і той же резольвер за його IP без покладення на /etc/resolv.conf search-інструменти чи split DNS.
Порівняйте AD, RA та фактичний код відповіді (NOERROR, SERVFAIL, NXDOMAIN).

2) Визначити валідатор, що падає, і ізолювати його

Якщо у вас пул резольверів — перевіряйте по одному. Періодичність часто означає «підмножина».
Якщо ви пересилаєте до апстримів, тимчасово обійдіть пересилку (або тестуйте пряму рекурсію), щоб локалізувати місце, де валідація ламається.

3) Перевірте ланцюг: DS у батьку, DNSKEY у дочці, підписи валідні «зараз»

Використовуйте delv або drill -D, щоб примусити повний трасування валідації.
Шукайте невідповідності DS, відсутні RRSIG, прострочені підписи або непідтримувані алгоритми.

4) Перевірте MTU / фрагментацію / TCP fallback

Шукайте зразки «udp truncated», зростання TCP-запитів або таймаути лише в деяких мережах.
Тестуйте зменшення розміру EDNS, щоб відтворити проблему.

5) Перевірте час і довірчі якорі

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

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

Ментальна модель: де може падати валідація DNSSEC

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

Шар A: Транспорт (UDP/TCP, EDNS0, фрагментація)

DNSSEC часто збільшує розмір відповіді: набори DNSKEY, запис DS, RRSIG-и, докази NSEC/NSEC3. Якщо UDP-пакети фрагментуються і фрагменти втрачаються, резольвер може ніколи не зібрати відповідь, може робити повторний запит або вважати апстрим «lame».

Шар B: Цілісність даних (підписи та ланцюг довіри)

Валідація потребує шляху від довірчого якоря (зазвичай корінь) через DS та DNSKEY до RRset, який ви запитали. Зламайте DS-зв’язок, опублікуйте погані підписи або дайте підписам прострочитись — валідатор повинен повернути SERVFAIL (або внутрішньо «bogus»). Це й є сенс.

Шар C: Час (вікна дійсності RRSIG)

RRSIG inception/expiration нещадні. Валідатор з неправильним часом може анулювати цілком коректні зони. Це одна з небагатьох DNS-проблем, яку реально фіксує NTP, а не суперечки.

Шар D: Поведінка валідатора (кешування, RFC 5011, агресивний NSEC)

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

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

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

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

Завдання 1: Перевірити, чи резольвер валідує (прапорець AD)

cr0x@server:~$ dig @192.0.2.53 www.cloudflare.com A +dnssec +multi

; <<>> DiG 9.18.24 <<>> @192.0.2.53 www.cloudflare.com A +dnssec +multi
; (1 server found)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1122
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.cloudflare.com.  300 IN A 104.16.132.229
www.cloudflare.com.  300 IN RRSIG A 13 3 300 20260101000000 20251201000000 34505 cloudflare.com. ...

;; Query time: 21 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)

Значення: ad вказує, що резольвер валідований відповідь. Наявність RRSIG показує, що запитувалися DNSSEC-дані.

Рішення: Якщо у випадку помилки бракує ad або повертається SERVFAIL, копайте далі. Якщо повертається NOERROR без ad, резольвер може не валідовувати або налаштований на видалення AD.

Завдання 2: Підтвердити, що `SERVFAIL` — з валідації, а не таймаут апстриму

cr0x@server:~$ dig @192.0.2.53 broken.dnssec-failed.org A +dnssec +comments

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44110
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

Значення: SERVFAIL саме по собі неоднозначний. Важливо зіставити з журналами резольвера (завдання нижче) і протестувати валідуючим інструментом (delv).

Рішення: Якщо кілька різних імен дають SERVFAIL, підозрюйте стан резольвера або підключення. Якщо лише одна зона — підозрівайте DNSSEC-дані зони або проблеми MTU/шляху для відповідей цієї зони.

Завдання 3: Використати `delv`, щоб отримати пояснення валідації (локальний доказ)

cr0x@server:~$ delv @192.0.2.53 example.com A

; fully validated
example.com.  300 IN A 93.184.216.34

Значення: «fully validated» означає, що резольвер надав достатньо даних і валідація успішна.

Рішення: Якщо delv каже «resolution failed» або «bogus», вважайте це DNSSEC-проблемою доти, поки не доведено протилежне, і переходьте до перевірки ланцюга.

Завдання 4: Змусити `delv` показати, чому воно bogus

cr0x@server:~$ delv @192.0.2.53 bad.example A +rtrace

...
; validation failure <bad.example/A>: no valid RRSIG
; resolution failed: SERVFAIL

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

Рішення: «no valid RRSIG» зазвичай означає зламане підписування, прострочені підписи або те, що відповідь була урізана/втрачена і резольвер не отримав потрібні підписи.

Завдання 5: Порівняйте поведінку при вимкненому DNSSEC у запиті (контрольний тест)

cr0x@server:~$ dig @192.0.2.53 example.com A +nodnssec +multi

; <<>> DiG 9.18.24 <<>> @192.0.2.53 example.com A +nodnssec +multi
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5881
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  300 IN A 93.184.216.34

Значення: Якщо +nodnssec працює, а +dnssec — ні, причетні розмір/валідація DNSSEC. Якщо обидва падають — це простий DNS або транспорт.

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

Завдання 6: Перевірити DS у батьківській зоні (тест «чи вказує батько вірно?»)

cr0x@server:~$ dig @192.0.2.53 example.com DS +dnssec +multi

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19981
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  86400 IN DS 370 13 2 9F3E...C1A7
example.com.  86400 IN RRSIG DS 8 2 86400 20260101000000 20251201000000 12345 com. ...

Значення: Батько публікує DS. Дайджест і тег ключа мають відповідати DNSKEY у дочці. Тут ad — хороший знак: ланцюг від батька до цього рівня гаразд.

Рішення: Якщо DS відсутній — зона «insecure» (не підписана з точки зору батька). Якщо DS є, але не відповідає DNSKEY у дочці — буде bogus.

Завдання 7: Перевірити DNSKEY у дочці (тест «чи публікує дочка правильний ключ?»)

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

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5022
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  3600 IN DNSKEY 257 3 13 mGx...==
example.com.  3600 IN DNSKEY 256 3 13 tZk...==
example.com.  3600 IN RRSIG DNSKEY 13 2 3600 20260101000000 20251201000000 370 example.com. ...

Значення: Зазвичай видно KSK (флаг 257) і один або кілька ZSK (флаг 256). Вони повинні бути підписані, і підписи мають валідоватися.

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

Завдання 8: Примусити TCP, щоб відкинути фрагментацію UDP

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

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61001
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; Query time: 37 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (TCP)

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

Рішення: Мітегуйте, знижуючи EDNS UDP size на резольвері, дозволяючи DNS по TCP/853 належним чином або виправляючи мережевий шлях, що втрачає фрагменти/ICMP.

Завдання 9: Обмежити EDNS buffer size, щоб відтворити збій «велика відповідь»

cr0x@server:~$ dig @192.0.2.53 example.com DNSKEY +dnssec +bufsize=1232

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4555
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

Значення: 1232 — поширений «безпечний» розмір EDNS для уникнення фрагментації на типовому шляху. Якщо зменшення bufsize усуває збої, ви дізналися корисну річ про мережу.

Рішення: Встановіть консервативний EDNS-розмір на резольверах, якщо ви працюєте в проблемних мережах (VPN, overlay, готельний Wi‑Fi, деякі корпоративні фаєрволи).

Завдання 10: Перевірити журнали резольвера на явні помилки валідації (Unbound)

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 30
Dec 31 01:59:12 resolver-a unbound[912]: info: validation failure <example.com. DNSKEY IN>: signature expired
Dec 31 01:59:12 resolver-a unbound[912]: info: resolving example.com. DNSKEY IN
Dec 31 01:59:13 resolver-a unbound[912]: info: error: SERVFAIL example.com. A IN

Значення: Це не «випадково». Це «signature expired», що зазвичай означає, що оператор зони не встиг перезасвідчити, або ваш годинник неправильний.

Рішення: Спочатку перевірте локальний час (завдання 12). Якщо час в порядку — ескалюйте до власника зони з доказами.

Завдання 11: Перевірити журнали резольвера на помилки валідації (BIND named)

cr0x@server:~$ sudo journalctl -u named --since "10 min ago" | tail -n 40
Dec 31 02:01:22 resolver-b named[1044]: resolver: info: validating example.com/A: no valid signature found
Dec 31 02:01:22 resolver-b named[1044]: resolver: info: DNSKEY example.com is not secure
Dec 31 02:01:22 resolver-b named[1044]: resolver: info: client @0x7f... 198.51.100.27#51622 (example.com): query failed (SERVFAIL) for example.com/IN/A at query.c:...

Значення: «No valid signature found» часто корелює з невідповідністю DS, відсутнім RRSIG або урізаною відповіддю, коли резольвер не отримав потрібні підписи.

Рішення: Негайно протестуйте з +tcp і +bufsize=1232, щоб перевірити, чи це транспорт. Якщо ні — інспектуйте узгодженість DS/DNSKEY.

Завдання 12: Підтвердити правильність годинників (зсув часу валідатора)

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-31 02:06:41 UTC
           Universal time: Wed 2025-12-31 02:06:41 UTC
                 RTC time: Wed 2025-12-31 02:06:41
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Валідація DNSSEC залежить від правильного часу. Якщо System clock synchronized — «no», ви в небезпечній зоні.

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

Завдання 13: Виявити проблему з довірчим якорем (root key) за допомогою утиліти unbound-anchor

cr0x@server:~$ sudo unbound-anchor -a /var/lib/unbound/root.key
/var/lib/unbound/root.key has content
success: the anchor is ok

Значення: Це перевіряє, чи файл кореневого довірчого якоря присутній і має прийнятний вміст.

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

Завдання 14: Перевірити, чи ви пересилаєте (і тому успадковуєте поведінку чиїхось DNSSEC)

cr0x@server:~$ sudo unbound-control list_forwards
zone=.
forward-addr=203.0.113.9@53
forward-addr=203.0.113.10@53

Значення: Ви не робите повну рекурсію; довіряєте апстрим-форвардерам. Якщо вони валідовують інакше, фільтрують EDNS або ламають TCP-fallback, ваші результати будуть різними.

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

Завдання 15: Переконатися, що ваш резольвер справді намагається валідовувати DNSSEC

cr0x@server:~$ sudo unbound-control get_option val-permissive-mode
val-permissive-mode: no

Значення: Permissive mode може перетворювати жорсткі помилки на м’які. Зручно під час аварії; погано для безпеки та ясності діагностики.

Рішення: Тримайте permissive mode вимкненим у звичайному режимі. Якщо включили під час інциденту — зафіксуйте це, обмежте термін і заплануйте відкат.

Завдання 16: Виміряти співвідношення UDP vs TCP запитів (сигнал транспорту)

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'num.query.tcp|num.query.udp|num.answer.rcode.SERVFAIL'
num.query.udp=1849921
num.query.tcp=219004
num.answer.rcode.SERVFAIL=3812

Значення: Різкий сплеск TCP-запитів може вказувати на проблеми фрагментації UDP або навмисне усічення. Сплеск SERVFAIL, корельований з окремими зонами, вказує на проблеми ланцюга DNSSEC.

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

Завдання 17: Протестувати path MTU і поведінку фрагментації (швидко і грубо)

cr0x@server:~$ ping -M do -s 1472 198.51.100.53 -c 3
PING 198.51.100.53 (198.51.100.53) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1480
ping: local error: message too long, mtu=1480
ping: local error: message too long, mtu=1480

--- 198.51.100.53 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2041ms

Значення: На шляху існують обмеження MTU. UDP-DNS з великими EDNS-полями підозрілий. Це не доводить, що DNS-фрагменти відкидаються, але дає сильний натяк.

Рішення: Зменшіть EDNS UDP size на резольвері, переконайтеся, що TCP-fallback працює, і виправте обробку ICMP, де можливо.

Завдання 18: Переконатися, що авторитативні сервери доступні й консистентні

cr0x@server:~$ dig @ns1.example.net example.com DNSKEY +dnssec +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3101
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

Рішення: Запитайте кожен авторитативний сервер напряму. Непослідовні DNSSEC-дані між серверами — високовпевнена коренева причина «випадкових» збоїв.

Жарт №2: Відлагодження DNSSEC — це коли ви вчитеся відрізняти «розподілена система» від «розподіленого перекладання провини».

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

Тут ми перестаємо робити вигляд, що завжди «Інтернет винен», і називаємо типових підозрюваних.

1) Деякі клієнти отримують `SERVFAIL`, інші успішно

Симптом: Періодичні збої, прив’язані до офісу/VPN/регіону; повторні запити інколи вдаються.
Корінна причина: Втрати UDP-фрагментів, зламаний PMTUD або фаєрвол, що псуватиме EDNS0. DNSSEC-відповіді великі; шлях не лагідний.
Виправлення: Знизьте EDNS UDP size на резольверах (часто 1232), забезпечте дозвіл TCP/53 і виправте обробку ICMP на шляху. Перевірте dig +tcp і dig +bufsize=1232.

2) Все працювало до ролловера ключа, а потім «випадково» зламалося

Симптом: Зона, що була стабільною, тепер періодично bogus; деякі резольвери відновлюються швидше за інші.
Корінна причина: DS у батьку не відповідає активному KSK у дочці; або один авторитативний сервер ще віддає старі DNSKEY/RRSIG.
Виправлення: Перевірте DS у батька і DNSKEY у дитини. Переконайтеся, що всі авторитативні сервери віддають однакові підписані дані. Правильно повторіть кроки ролловера; не «просто вимикайте DNSSEC», якщо вам не подобається дзвінки від клієнтів.

3) Збої почалися після «закручування безпеки» в мережі

Симптом: DNS працює для маленьких записів; запити DNSKEY таймаутяться; TCP/53 заблокований.
Корінна причина: Фаєрвол блокує фрагменти, блокує TCP/53 або лімітує патерни «невідомого UDP», ненавмисно DoS-ить DNSSEC.
Виправлення: Дозвольте TCP/53 до резольверів, дозвольте повернення фрагментів або зменшіть EDNS size. Підтвердіть за статистикою: зростання TCP fallback, усічень або таймаути.

4) Помилки валідації з’являються лише на підмножині резольверів

Симптом: Резольвер A валідовує; резольвер B повертає SERVFAIL для того самого запиту.
Корінна причина: Різні довірчі якорі, застарілий root.key, зсув годинника, різні форвардери або різні версії/дефолти резольверів.
Виправлення: Стандартизуйте конфігурацію резольверів і керування довірчими якорями. Перевірте синхронізацію часу. Порівняйте unbound-anchor, версію та налаштування пересилання.

5) `NXDOMAIN` стає `SERVFAIL` під DNSSEC

Симптом: Невідоме ім’я повинно давати NXDOMAIN, але на валідувальних резольверах приходить SERVFAIL.
Корінна причина: Зламані докази відсутності (NSEC/NSEC3) або відсутні RRSIG-и на NSEC/NSEC3.
Виправлення: Перевірте delv +rtrace. Виправте підписування NSEC/NSEC3, переконайтеся в коректних параметрах і що всі авторитативні сервери віддають консистентні записи відсутності.

6) «Працює з публічними резольверами, але не з нашими»

Симптом: Публічні резольвери валідовують без проблем; ваші внутрішні валідуючі резольвери падають.
Корінна причина: Ваші резольвери пересилають на апстрим, який видаляє DNSSEC, змінює EDNS або ламає TCP-fallback; або внутрішня мережа відкидає фрагменти.
Виправлення: Тестуйте пряму рекурсію (без пересилки) на одному резольвері. Порівняйте EDNS buffer, поведінку TCP і журнали.

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

Міні-історія 1: Інцидент через неправильне припущення

Компанія A мала простий шар резольверів: два anycast VIP на регіон, Unbound за ними та «прості» форвардери до стороннього DNS-сервісу для кращого кешування. DNSSEC був увімкнений, бо команда безпеки мала квартальну галочку з словами «DNSSEC validation».

Партнер провів ротацію ключів DNSSEC. Нічого незвичного, просто рутинна гігієна. Через годину декілька аплікаційних подів в одному регіоні почали провалювати TLS-рукопотискання, бо не могли резолвити ім’я OCSP-респондера. Інцидент-канал заворушився.

Інженер на чергуванні припустив: «Якщо публічний Інтернет резолвить — наші резольвери зламались». Це припущення виявилося навпаки. Публічні резольвери не форвардили до тих самих апстримів, не стояли за тим самим фаєрволом і не підлягали тій самій обробці EDNS.

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

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

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

Компанія B мала глобальну мережу з «корисними» WAN-оптимізаторами. Хтось помітив, що DNS-трафік «галасливий» і вирішив «оптимізувати». WAN-команда впровадила політику, що знижувала пріоритет UDP-фрагментів під час перевантаження, бо «фрагментація часто марна».

Нічого не вибухнуло одразу. Більшість DNS-відповідей були маленькі. Але коли DNSSEC став поширеним серед постачальників, DNSKEY та деякі підписані TXT-записи почали фрагментуватися. Оптимізатори не скидали всі фрагменти — лише достатньо, щоб зробити проблему періодичною під навантаженням. Ідеально: баг, що найкраще відтворюється, коли ви найзавантаженіші.

Ситуацію ускладнювала поведінка fallback. Деякі резольвери швидко повторювали по TCP; деякі клієнти мали короткі таймаути; деякі middlebox-и ставилися до TCP/53 підозріло. Користувачі скаржилися на «випадкові DNS-збої», а перша реакція була додати ще резольверів.

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

Зрештою встановили консервативний EDNS UDP size і змінили WAN-політику, щоб не відмовлятися від фрагментів як таких. Нічого героїчного — просто визнали, що DNSSEC зробив «великі UDP» першокласним громадянином.

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

Компанія C нічого надмірного не робила. Вони запускали BIND-резольвери з суворим базовим конфігом, NTP скрізь, управління конфігами з детекцією дрейфу та канарний резольвер на регіон. Ще в них була звичка: щодня автоматизовані задачі запускали delv проти невеликого набору критичних зовнішніх доменів і кількох внутрішніх підписаних зон.

Одного вівторка оновлення DS у реєстратора клієнта пройшло неправильно. Зона все ще була підписана, але DS у батьку більше не відповідав KSK у дочці. Це означає: валідуючі резольвери повинні падати. Невалідуючі резольвери продовжували працювати, що пояснює розділений користувацький досвід.

Щоденний канарний тест вловив це за хвилини після зміни. Не тому, що компанія була ясновидящою — а тому що вони вимірювали статус валідації як SLO. У них був план дій, журнали централізовані, а докази вже у тікеті.

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

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

Покроково: ізолювати, чи це дані зони, конфіг резольвера чи мережа

Виберіть одне невдале ім’я й тип запису. Запишіть його. Не відлагоджуйте «DNS» у загальному вигляді.
Запитайте той самий резольвер напряму з хоста, що падає. Використайте dig @IP з +dnssec.
Повторіть з відомо-робочого хоста. Якщо результати різні — маємо відмінності шляху або вибору резольвера.
Спробуйте +tcp. Якщо TCP виправляє — дивіться UDP/EDNS/фрагментацію.
Спробуйте +bufsize=1232. Якщо це вирішує — мережевий шлях ворожий до великих UDP.
Запустіть delv +rtrace для отримання причини. Це швидше, ніж гадати.
Перевірте журнали резольвера на причини «bogus». Прострочені підписи, невідповідність DS, непідтримуваний алгоритм тощо.
Переконайтеся в синхронізації часу на резольвері. Якщо час неправильний — зупиніться і виправте його.
Запитайте DS у батька і DNSKEY у дочці. Переконайтеся, що вони узгоджені й консистентні між авторитативними серверами.
Визначте власника.
- Якщо DS/DNSKEY не співпадають: проблема власника зони/реєстратора.
- Якщо лише деякі резольвери падають: дрейф флоту, час або довірчі якорі у вас.
- Якщо TCP працює, а UDP ні: мережевий шлях/EDNS sizing.

Чекліст: що зібрати для ескалації (щоб це виправили)

Невдалий FQDN і тип запису (A/AAAA/TXT/DNSKEY/DS).
IP(и) резольверів, які протестували, і чи присутнє пересилання.
Вивід dig з +dnssec і з +tcp.
Вивід delv +rtrace, що показує причину (прострочений sig, невідповідність DS тощо).
Позначка часу і статус годинника/часової зони вашого резольвера.
Які авторитативні сервери опитані напряму і чи відрізнялися відповіді.

Часті питання

1) Чому збій DNSSEC відображається як `SERVFAIL`, а не як більш детальне повідомлення?

Бо DNS — протокол, створений для мінімалізму й кешування. Валідатори зазвичай не передають клієнту детальні помилки валідації. Резольвер знає «bogus», клієнт бачить «SERVFAIL». Для пояснення використовуйте журнали резольвера і delv.

2) Який найшвидший спосіб довести невідповідність DS/DNSKEY?

Опитайте DS у батька і DNSKEY у дитини, потім запустіть delv +rtrace. Якщо дайджест DS не відповідає жодному DNSKEY — валідатори будуть падати після злиття кешів.

3) Чи можна просто вимкнути валідацію DNSSEC під час інциденту?

Можна, але робіть це як контрольоване полум’я: обмежте час, задокументуйте і усвідомте, що втрачаєте. Часто кращою мірою для пом’якшення є зниження EDNS UDP size або забезпечення TCP/53 — виправити транспорт, а не відключати валідацію.

4) Чому публічні резольвери проходять, а наші ні?

Різні реалізації резольверів, різні стани довірчих якорів, різні маршрути мережі й політики. Публічні резольвери можуть мати кращу anycast-доступність, більш толерантний TCP fallback або просто не стояти за вашими фаєрвол-правилами.

5) Що насправді означає прапорець `AD`?

AD (Authenticated Data) встановлюється валідуючим резольвером, коли він вважає дані валідованими. Прапорець може бути відсічений або не встановлений залежно від конфігурації. Розглядайте його як сигнал, а не як беззаперечну істину; підсильте перевіркою через delv, коли це важливо.

6) Чи погано знижувати EDNS UDP size для продуктивності?

Іноді це підвищує кількість fallback-ів на TCP, що може додати затримку. Але трохи повільніша відповідь краще, ніж випадковий збій. Для багатьох корпоративних шляхів консервативний EDNS-розмір — практичний вибір.

7) Як дрейф часу може спричиняти лише періодичні збої?

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

8) У чому різниця між «insecure» і «bogus»?

Insecure означає, що немає ланцюга довіри (DS у батьку відсутній). Резольвер може відповідати без валідації. Bogus означає, що ланцюг очікується, але він не проходить (погані підписи, невідповідність DS/DNSKEY тощо). Bogus має припиняти відповіді.

9) Чи дійсно змішані флоти резольверів настільки важливі?

Так. За замовчуванням вони відрізняються: поведінка кешування, керування довірчими якорями, TCP fallback і логування. Якщо хочете передбачувану поведінку — стандартизуйте або принаймні документуйте відмінності й тестуйте обидва шляхи.

Висновок: наступні кроки, які можна впровадити цього тижня

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

Зробіть наступне:

Впровадьте швидкий план діагностики. Покладіть його в runbook на чергуванні і зробіть «dig +dnssec, dig +tcp, delv +rtrace» м’язовою пам’яттю.
Стандартизуйте базові налаштування резольверів. Одна версія, одна політика керування довірчими якорями, одна політика EDNS-sizing, один рівень логування під час інцидентів.
Визначте консервативний EDNS UDP size, якщо працюєте в проблемних мережах. Потім виміряйте співвідношення TCP, щоб знати витрати.
Моніторте результати валідації. Відстежуйте SERVFAIL по зонах, а не лише загальні показники. Запускайте щоденні канарні тести валідації критичних доменів.
Серйозно ставтеся до часу. Якщо ви запускаєте валідатори — ви керуєте годинниками. Робіть NTP-drift сигналом тривоги, а не приміткою в документації.