DNSSEC NSEC3: міфи — коли допомагає і коли лише шкодить продуктивності

NSEC3 в одному екрані: що це і чого не є

DNSSEC підписує не лише записи, які існують. Він також має надати криптографічний доказ для записів, яких нема. Якщо резолвер запитує does-not-exist.example, ви не можете просто відповісти «ні». Без доказу атакувальник може підробити негативні відповіді і змусити цілі імена зникнути.

Саме для цього існують NSEC і NSEC3: криптографічне заперечення існування. Вони дозволяють авторитарному серверу довести — криптографічно — що запитуване ім’я (або тип) не існує в зоні.

NSEC (прямолінійний)

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

Недолік: NSEC дає можливість тривіального перерахунку зони («zone walking»). Будь-хто може послідовно опитувати імена й відновити весь набір імен власників у зоні, навіть якщо AXFR заблоковано.

NSEC3 (хешований)

NSEC3 замінює відкриті імена хешованими. Замість зв’язування a.example → b.example він зв’язує
HASH(a) → HASH(b). Негативні відповіді містять NSEC3-записи з хешованими іменами. Це має ускладнити перерахунок зони, змушуючи атакувальника вгадувати імена й хешувати їх (можливо з кількома ітераціями й сіллю), щоб збігтися з тим, що є в зоні.

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

Найкоротша корисна ментальна модель: NSEC швидший і протікає; NSEC3 повільніший і менше протікає, але не робить зони секретною.

Міфи про NSEC3, які не вмирають

Міф 1: «NSEC3 запобігає перерахунку зони, отже припиняє розвідку.»

NSEC3 перешкоджає лише тривіальному перерахунку зони. Він не зупиняє вгадування імен. Якщо в організації використовують
vpn, mail, autodiscover, api, dev, stage, prod,
і ви думаєте, що хеш це зупинить… погані новини.

Атакувальникам не потрібно ходити зоною, коли ви вже назвали речі як людина. Вони вгадуватимуть. Вони будуть брутфорсити.
Вони використовуватимуть словники. Вони звертатимуться до журналів certificate transparency та пасивного DNS. NSEC3 лише підвищує вартість сліпого перерахунку.

Міф 2: «Більше ітерацій NSEC3 завжди означає більше безпеки.»

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

Галузь відійшла від високих ітерацій, бо реальна користь тонка, а витрати реальні. Високі значення ітерацій не захищають від очевидних імен.
Вони захищають від… когось, хто вгадує ваші випадкові 20-символьні мітки. Якщо це ваша основна модель загрози — добре. Якщо ні — ви платите за порожню квартиру.

Міф 3: «NSEC3 завжди «безпечніший» за NSEC.»

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

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

Міф 4: «NSEC3 виправить SERVFAIL проблеми після ввімкнення DNSSEC.»

Якщо ви отримуєте SERVFAIL після вмикання DNSSEC, скоріш за все у вас зламані підписи, відсутні DS-записи, прострочені RRSIG,
неправильний вибір алгоритму, зламана ротація ключів або проблеми з MTU/фрагментацією. Перемикання з NSEC на NSEC3 не лікує; це як поміняти шини, бо загорівся індикатор двигуна.

Жарт №1 (коротко, по суті): NSEC3 — це як тоновані вікна в машині без гальм. Він змінює, що бачать зовнішні, а не чи зупиняєтеся ви.

Міф 5: «Якщо ми не використовуємо NSEC3, ми не відповідаємо вимогам.»

Більшість документів з вимогами цікавить коректне розгортання DNSSEC та управління ключами. NSEC3 рідко є обов’язковим. Деякі організації обирають його як політику «щоби зменшити перерахунок». Це вибір, а не загальна вимога.

Коли NSEC3 дійсно допомагає

1) Ваші імена зон справді невгадувані і вас цікавить розкриття імен

Якщо ви використовуєте випадкові мітки (наприклад: токени для клієнтів, довгі UUID-подібні імена хостів або структури делегування, що зберігають приватність), NSEC3 може суттєво підвищити вартість їх перерахунку. У таких нішах ланцюг NSEC у відкритому вигляді — це невиправдана помилка.

2) Ви ворожому середовищі розвідки і ваші імена дисципліновані

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

3) Ви керуєте підписаним TLD або великою публічною зоною і маєте політичний тиск

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

4) Ви можете дозволити собі експлуатаційні витрати

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

Де NSEC3 шкодить продуктивності (і чому)

Збільшення розміру пакетів: негативні відповіді товстішають

DNSSEC вже збільшує розмір відповідей через RRSIG і DNSKEY. Негативні відповіді можуть бути ще гіршими, бо доказ заперечення існування вимагає додаткових записів (NSEC/NSEC3 плюс їхні підписи). Відповіді з NSEC3 часто містять кілька NSEC3-записів для покриття доказів «closest encloser» і відмови wildcard, і кожен несе хешовані імена та параметри.

Великі UDP-відповіді провокують фрагментацію, а фрагменти губляться, це викликає повтори і перехід на TCP. Ви думали, що ввімкнули «більше безпеки»; насправді ви ввімкнули «більше стану на фаєрволах і балансувальниках».

Вартість CPU: хешування та підписування — не безкоштовні

NSEC3 використовує хешування (SHA-1 у початковому дизайні). Авторитарні сервери зазвичай препрораховують ланцюги NSEC3 під час підписування, але динамічні зони, часті повторні підписування або погані інструменти можуть перекласти роботу у шлях обслуговування або збільшити churn підписів.

Навіть при препрорахунку складніше будування доказів для негативних відповідей підсилює кодові шляхи й шаблони доступу до пам’яті. На завантаженому авторитетному флоті це виявиться як вищий CPU на запит і нижчий відсоток попадань у кеш (бо літає більше різних негативних доказів).

Біль для резолверів: валідація та повтори ускладнюються

Валідатори не люблять великі, фрагментовані відповіді. Вони люблять послідовні, кешовані відповіді. NSEC дає чистіші властивості кешування для відсутності записів, бо він простий і стабільний. Хешований характер NSEC3 разом з опцією opt-out (в деяких розгортаннях) може призвести до більшої роботи резолверів, більше запитів і більше часу на проходження доказів.

Операційне відлагодження: люди не читають хеші

З NSEC ви можете поглянути на відповідь і зрозуміти, що доводиться. З NSEC3 ви пучите очі на base32-кубики і думаєте, чи випадково ви не викликали демонів.

Жарт №2 (коротко, по суті): Відлагоджувати NSEC3 візуально — як розбирати інцидент з пам’яттю за сирими hex-дампами. Технічно можливо. Духовно — нерозумно.

Мідлбокси: та частина інтернету, що все ще ненавидить вас

DNSSEC залежить від EDNS(0) для більших UDP-буферів. Деякі мережі досі неправильно обробляють EDNS, фрагментовані UDP або великі DNS-відповіді. NSEC3 може частіше штовхати вас за порогом розміру, перетворюючи «рідкісний кутовий випадок» на «щоденний інцидент».

Opt-out: пастки продуктивності та політики

NSEC3 opt-out був розроблений, щоб зменшити навантаження підписування для зон з великою кількістю незахищених делегацій (поширено у реєстрів). Він може зменшити кількість записів і розмір відповідей у таких випадках. Але він також ускладнює семантику довіри. Якщо ваша команда не може чітко пояснити opt-out аудитору та on-call, не використовуйтесь його легковажно.

Факти та історія: як ми сюди потрапили

• NSEC з’явився першим: автентифіковане заперечення спочатку використовувало NXT, потім NSEC, який прямо показував порядок імен у зоні.
• Перерахунок зони не був сюрпризом: це була очевидна властивість NSEC, і спільнота роками дискутувала, чи має це значення.
• NSEC3 введено для подолання перерахунку: він додав хешування (плюс сіль і ітерації), щоб ускладнити масове розкриття.
• NSEC3 використовує SHA-1: не тому, що це «сучасно», а тому, що стандарт узгоджували, коли SHA-1 був прагматичним вибором для цієї задачі.
• Ітерації стали пультом: ідея — підняти вартість оффлайн вгадування; на практиці це створило драму налаштувань.
• Великі відповіді стали справжнім ворогом: із впровадженням DNSSEC оперативні збої часто виникали через розмір UDP/фрагментацію, а не лише через криптографію.
• Opt-out задумували для реєстрів: щоб зробити NSEC3 здійсненним для зон з величезною кількістю незахищених делегацій.
• Операційні інструменти відставали: ранні впровадження DNSSEC страждали через недостатньо зрілі робочі процеси моніторингу та відлагодження.
• Багато операторів тепер віддають перевагу простоті: для багатьох зон урок галузі — «використовуйте NSEC, якщо нема причини інакше».

Один вислів, бо він належить до кожної розмови в опсах. Werner Vogels (CTO Amazon) сказав: «Everything fails, all the time.» Цей підхід застосовується й тут: проєктуйте вибір DNSSEC навколо режимів відмов, які ви зможете витримати, а не навколо теоретичної досконалості.

Плейбук швидкої діагностики

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

Перший крок: підтвердьте, чи проблеми стосуються негативних відповідей або всього підряд

• Візьміть вибіркові запити для існуючих імен і для NXDOMAIN-імен. Якщо NXDOMAIN непропорційно повільний або частіше викликає TCP, NSEC3 — головний підозрюваний.
• Подивіться на розміри відповідей. Якщо ви регулярно вище ~1232 байт, ви в зоні «фрагментаційного рулетку» для багатьох мереж.

Другий крок: перевірте фрагментацію, повтори та перехід на TCP

• Захопіть трафік на авторитарному краю. Якщо бачите повторні запити, обірвані (TC=1) відповіді або багато TCP/53 сесій, ви платите податок розміру.
• Перевірте поведінку EDNS буферів з реальних клієнтських мереж. Не довіряйте одній точці зору на чистій корпоративній LAN.

Третій крок: перевірте ланцюг DNSSEC та докази заперечення

• Використайте валідуючий резолвер і інструменти, що показують доказ заперечення існування. Підтвердіть дійсність RRSIG і коректне покриття NSEC3.
• Шукайте помилки ротації ключів або прострочення підписів. Вони маскуються під «продуктивність», бо викликають повтори й fallback-шляхи.

Четвертий крок: ізолюйте витрати на стороні сервера

• Слідкуйте за CPU авторитарів і QPS під навантаженням. Якщо CPU росте з ростом NXDOMAIN, можливо виконується динамічна робота NSEC3 або ви страждаєте від промахів кешу.
• Перевірте, чи не «смикається» ваш підписувач (занадто часте пересписування, надто багато ключів, занадто коротка валідність підписів або погані зміни параметрів NSEC3).

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

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

Завдання 1: Порівняйте розмір та прапори для позитивних і негативних відповідей

cr0x@server:~$ dig +dnssec +bufsize=1232 www.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 www.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 18 msec
;; MSG SIZE  rcvd: 412

cr0x@server:~$ dig +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1129
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 3600 900 1209600 300
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...
6JQ2K7...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 6K5... NS SOA RRSIG DNSKEY NSEC3PARAM
6JQ2K7...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...
9F8P1...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 B0T... A AAAA RRSIG
9F8P1...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 44 msec
;; MSG SIZE  rcvd: 1216

Що це означає: NXDOMAIN приблизно в 3 рази більший і повільніший, і він фліртує з межею буфера 1232 байти.

Рішення: Розглядайте негативні відповіді як основний ризик продуктивності. Почніть тестувати обрізання і фрагментацію наступними кроками.

Завдання 2: Перевірте поведінку обрізання (TC) з меншим EDNS буфером

cr0x@server:~$ dig +dnssec +bufsize=512 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9001
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message truncated

Що це означає: З меншим буфером сервер встановлює TC=1 і очікує, що клієнт повторить запит по TCP.

Рішення: Якщо багато клієнтів поводяться так (зламаний EDNS, малі буфери), ви побачите сплески TCP. Плануйте пом’якшення.

Завдання 3: Підтвердіть роботу TCP fallback і виміряйте його

cr0x@server:~$ dig +tcp +dnssec does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7711
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; Query time: 96 msec
;; MSG SIZE  rcvd: 1216

Що це означає: TCP працює, але коштує ~2–5× більше затримки порівняно з UDP у багатьох середовищах.

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

Завдання 4: Перевірте наявність NSEC vs NSEC3 у зоні

cr0x@server:~$ dig +dnssec example.com NSEC3PARAM @ns1.example.net

;; ANSWER SECTION:
example.com. 300 IN NSEC3PARAM 1 0 10 A1B2C3D4
example.com. 300 IN RRSIG NSEC3PARAM 13 2 300 20260204000000 20260114000000 12345 example.com. ...

Що це означає: Зона використовує NSEC3 з алгоритмом 1, прапором 0, 10 ітераціями і сіллю A1B2C3D4.

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

Завдання 5: Подивіться, чи негативні відповіді включають кілька NSEC3-записів

cr0x@server:~$ dig +dnssec +norecurse nohost.sub.example.com A @ns1.example.net

;; AUTHORITY SECTION:
... NSEC3 ...
... NSEC3 ...

Що це означає: Ви отримуєте докази closest-encloser і відмови для wildcard. Це нормально, і це збільшує розмір.

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

Завдання 6: Перевірте QPS і CPU авторитарних серверів під час сплесків NXDOMAIN

cr0x@server:~$ sudo rndc stats
cr0x@server:~$ sudo tail -n 12 /var/named/data/named_stats.txt
++ Incoming Requests ++
[View: default]
                17642 QUERY
                 8810 NXDOMAIN
++ Name Server Statistics ++
               1420010 IPv4 requests received
                  9901 TCP requests received

Що це означає: NXDOMAIN — велика частка запитів, і TCP-запитів немало.

Рішення: Розглядайте NXDOMAIN як навантаження. Подумайте про обмеження частоти відповідей для зловмисних шаблонів, звуження використання wildcard і зменшення розміру негативних відповідей.

Завдання 7: Перевірте фрагментацію UDP на інтерфейсі сервера

cr0x@server:~$ sudo tcpdump -ni eth0 port 53 and udp -vv -c 6
tcpdump: listening on eth0, link-type EN10MB
12:00:01.100000 IP 198.51.100.20.53534 > 203.0.113.53.53: UDP, length 67
12:00:01.100500 IP 203.0.113.53.53 > 198.51.100.20.53534: UDP, length 1492
12:00:01.100520 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 1492:1480@0+
12:00:01.100540 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 220@1480

Що це означає: Ви надсилаєте фрагментовані UDP-відповіді. Деякі мережі відкидають фрагменти. Це стає джерелом випадкових збоїв DNS.

Рішення: Зменште розмір UDP-відповідей (політика та вибір підписування), або налаштуйте стратегію EDNS/MTU. Не ігноруйте фрагменти у 2026 році.

Завдання 8: Тестуйте з валідуючим резолвером, щоб відділити «авторитарне» від «валідації»

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

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

Що це означає: ad показує, що резолвер успішно провалідирував DNSSEC.

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

Завдання 9: Використайте delv, щоб валідовати й показати, чому ім’я не проходить

cr0x@server:~$ delv +vtrace does-not-exist.example.com A @9.9.9.9
; fully validated
does-not-exist.example.com. 300 IN A ; negative response, NXDOMAIN

Що це означає: Негативний доказ пройшов валідацію end-to-end.

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

Завдання 10: Перевірте DS у батька (класична перевірка «чому SERVFAIL?»)

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

;; ANSWER SECTION:
example.com. 86400 IN DS 12345 13 2 3A1B...C9
example.com. 86400 IN RRSIG DS 13 1 86400 20260204000000 20260114000000 9999 com. ...

Що це означає: Батьківська зона публікує DS. Валідатори будуть вимагати підписи для example.com.

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

Завдання 11: Перевірте вікна дійсності RRSIG (зсув часу та прострочення)

cr0x@server:~$ dig +dnssec example.com SOA @ns1.example.net | grep RRSIG
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...

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

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

Завдання 12: Виміряйте розподіл латентності авторитарного сервера під навантаженням

cr0x@server:~$ sudo dnstap-read /var/log/dnstap/dnstap.log | head -n 6
2010-01-01 12:00:01.100 CQ example.com/A udp 198.51.100.20:53534
2010-01-01 12:00:01.101 CR example.com/A NOERROR 1ms 412b
2010-01-01 12:00:02.200 CQ does-not-exist.example.com/A udp 198.51.100.21:53535
2010-01-01 12:00:02.260 CR does-not-exist.example.com/A NXDOMAIN 60ms 1216b

Що це означає: NXDOMAIN повільніший і більший. Це підпис (гра слів) витрат на доказ заперечення існування плюс мережеві ефекти.

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

Завдання 13: Перевірте параметри NSEC3 у BIND (якщо ви там підписуєте)

cr0x@server:~$ grep -R "nsec3param" -n /etc/bind
/etc/bind/named.conf.local:42:    auto-dnssec maintain;
/etc/bind/named.conf.local:43:    inline-signing yes;
/etc/bind/named.conf.local:44:    nsec3param 1 0 10 A1B2C3D4;

Що це означає: Inline signing увімкнено і параметри NSEC3 явно задані.

Рішення: Якщо ви успадкували цю конфігурацію — поставте її під сумнів. Якщо у вас немає причини для NSEC3, видаліть параметр і перейдіть на NSEC (планована зміна), або зменшіть ітерації.

Завдання 14: Перевірте проблеми сумісності EDNS з «поганого шляху» клієнтської мережі

cr0x@server:~$ dig +dnssec +edns=0 +bufsize=4096 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5150
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; MSG SIZE  rcvd: 1216

Що це означає: З цієї точки EDNS працює, але це не доводить, що воно працює для мобільних операторів, корпоративних проксі чи застарілих пристроїв.

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

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

Міні-історія 1: Інцидент через хибне припущення («NSEC3 зупинить розвідку, отже ми в безпеці»)

Середня SaaS-компанія мала публічну зону з багатьма внутрішніми зручними іменами випадково опублікованими: jenkins,
grafana, vpn, staging-api. Нічого безпосередньо експлойтабельного, але багато крихт.
Безпековий огляд вказав на «перерахунок зони через NSEC» як витік інформації.

Команда швидко і ввічливо відповіла: увімкнули NSEC3, підняли ітерації «для безпеки», запустили. Обвелися кругом і пішли далі. Ніхто не поставив незручне запитання: «Якщо хтось може вгадати наші імена, чого ми насправді досягли?»

Через кілька тижнів на них обрушилася хвиля цілеспрямованих атак зі спробами підбору паролів проти тих самих сервісів, які зона «сховала». Атакувальник нічого не перелічував. Він вгадав імена, перевірив їх через DNS, а потім спробував типові креденшали. NSEC3 зробив свою роботу — запобіг чистому скрапінгу — але не захистив від реальної загрози, яка була нудною та передбачуваною.

Постмортем був болючим, бо виправлення не було «підкрутити ітерації». Виправлення — менеджмент імен і контроль експозиції: забрати внутрішні сервіси з публічного DNS, помістити адмін-ендпоїнти за VPN і перестати публікувати зручні CNAME, що ведуть до UI управління.
NSEC3 не був неправильним; неправильним було припущення.

Операційний підсумок: компанія лишила NSEC3, бо скасування виглядало б як «зниження безпеки». Тим часом on-call тихо помітив, що найбільший помітний ефект проекту — стрибок у розмірах DNS-відповідей і іноді TCP fallback.

Міні-історія 2: Оптимізація, що обернулась проти («піднімемо ітерації NSEC3 до місяця»)

Велике підприємство з глобальним авторитарним флотом DNS вирішило стандартизувати NSEC3 всюди. Вони справді хвилювалися про масовий перерахунок делегованих піддоменів і мали на це політичну аргументацію.

Хтось запропонував значно підвищити кількість ітерацій NSEC3 «щоб уповільнити атакувальників». Здавалося розумним. Хешування ж дешеве, правда? А їхній кластер мав запас по ресурсам у спокійному стані.

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

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

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

Міні-історія 3: Нудна, але правильна практика, що врятувала день (чіткий моніторинг і дисципліна «вміститися в UDP»)

Фінансова компанія працювала з DNSSEC роками з мінімальною драмою. Їхній секрет не в екзотичній крипто-наві. Він у дисципліні:
моніторинг розмірів відповідей, передбачуване управління ключами та писаний план перевірки відмов.

Вони обрали NSEC для більшості зон. Для кількох зон, де NSEC3 дійсно давав користь, вони тримали консервативні параметри і уникали надмірних ітерацій. Ще важливіше: у них було SLO: «DNSSEC-відповіді мають вміщатися в обраний UDP-бюджет для більшості негативних відповідей.» Якщо зміна вносилася і відповідь ставала більша — це вважали регресією.

Одного дня DDoS-кампанія змінила тактику з об’ємного трафіку на NXDOMAIN-флуд проти їхньої публічної зони. Атака була банальною; це були високочастотні сміттєві запити, спрямовані на примус дорогих негативних відповідей.

Оскільки в них були базові метрики, вони розпізнали шаблон за хвилини: стрибок частки NXDOMAIN, збільшення розміру відповідей у хвості,
зростання TCP fallback, тренд CPU авторитарних серверів вгору. Вони увімкнули обмеження частоти відповідей для зловмисних джерел, відрегулювали кешування та фільтрацію на вході і повернулись до стабільності. Ніяких героїв. Жодних ночних Slack-повідомлень «чому DNS ламається?».

Перевага: команда змогла обґрунтувати свої «нудні» рішення жорсткими даними. NSEC не була ідеологією; це був усвідомлений вибір на користь надійності, що зменшив розмір негативних відповідей і полегшив кешування.

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

1) Симптом: випадкові таймаути, особливо в мобільних мережах

Корінна причина: фрагментовані UDP DNSSEC-відповіді (часто NXDOMAIN з NSEC3), які відкидають мережі або мідлбокси.

Виправлення: зменшити розмір відповідей (віддати перевагу NSEC там, де прийнятно; знизити складність NSEC3; уникати зайвих додаткових даних) і тестувати з меншими EDNS буферами.

2) Симптом: раптове зростання TCP/53 підключень після ввімкнення DNSSEC

Корінна причина: TC=1 обрізання через розмір відповіді і повтор резолвером по TCP; іноді посилюється малими EDNS-буферами.

Виправлення: моніторити частоту TC; налаштувати так, щоб типові відповіді вкладалися у UDP-бюджет; забезпечити масштабування та захист авторитарного TCP.

3) Симптом: валідатори повертають SERVFAIL для неіснуючих імен, але існуючі імена працюють

Корінна причина: зламані докази заперечення існування (поганий ланцюг NSEC3, некоректне підписування, застарілий стан inline-signed).

Виправлення: валідовати за допомогою delv +vtrace; чисто пересписати; забезпечити послідовні трансфери зон підписаного контенту; уникати часткових змін параметрів.

4) Симптом: сплески CPU авторитарів корелюють з NXDOMAIN-атаками

Корінна причина: дорога побудова негативних відповідей, погане кешування або робота підписувача, що витікає в шлях обслуговування.

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

5) Симптом: «Ми ввімкнули NSEC3 і від безпеки інцидентів побільшало»

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

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

6) Симптом: переривчасті SERVFAIL під час ротацій ключів

Корінна причина: пропускна здатність підписувача і затримка пропагування; зміни параметрів NSEC3 під час ключових подій; занадто тісні вікна часу підписів.

Виправлення: розділяйте зміни параметрів і ротації ключів; подовжуйте вікна валідності за потреби; моніторте чергу підписувача і стан публікації.

7) Симптом: різна поведінка резолверів (деякі валідуюють, деякі падають)

Корінна причина: відмінності path MTU, обробки EDNS або застарілий/зламаний кеш; не завжди «баг резолвера».

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

8) Симптом: «Перерахунок зони все ще можливий, навіть з NSEC3»

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

Виправлення: ставтеся до публічного DNS як публічного. Видаліть чутливі імена, зробіть їх випадковими, якщо треба, і не припускайте, що NSEC3 робить усе секретним.

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

Контрольний список рішення: чи повинна ця зона використовувати NSEC3?

1. Перелічіть загрозу: чи намагаєтеся ви запобігти масовому перерахунку справді невгадуваних імен, чи просто уникнути незручностей?
2. Оцініть передбачуваність імен: якщо мітки — загальні слова, NSEC3 не зупинить вгадування.
3. Оцініть обсяг NXDOMAIN: зони з великою часткою NXDOMAIN (опечатки, сканери, бот-трафік) більше платять за NSEC3.
4. Встановіть UDP-бюджет: оберіть ціль (часто 1232) і тестуйте негативні відповіді проти нього.
5. Підтвердіть зрілість інструментарію: чи може ваша команда швидко валідовувати і відлагоджувати збої NSEC3?
6. Майте план відкату: зміни параметрів і механізми заперечення існування потребують поетапного розгортання і моніторингу.

План розгортання: перемикання NSEC ↔ NSEC3 без самонанесених болів

1. Спочатку база: виміряйте розміри відповідей, співвідношення NXDOMAIN, частоту TCP/53 і хвильову латентність.
2. Тестуйте з кількох мереж: включіть мобільні та «корпоративні проксі» шляхи.
3. Стадійність зміни: канарьте одну зону або піднабір authority; дивіться на TC=1 і кількість фрагментів.
4. Не змішуйте з ключовими подіями: не змінюйте параметри NSEC3 під час KSK/ZSK ротацій. Тримайте змінні окремо.
5. Слідкуйте за негативним кешуванням: перевіряйте частоту запитів резолверів після зміни; не сподівайтеся лише на кеші.
6. Репетируйте відмови: потренуйтеся відлагоджувати SERVFAIL і помилки доказів разом з командою on-call.

Операційний чекліст: робіть DNSSEC нудним (найвище визнання)

1. Моніторьте розміри DNS-відповідей (особливо NXDOMAIN) та перцентили, а не лише середні значення.
2. Моніторьте частоти TCP/53, TC-біт та кількість UDP-фрагментів.
3. Створіть оповіщення за горизонтом прострочення підписів (RRSIG близькі до закінчення).
4. Тримайте годинник підписувачів синхронізованими (NTP) та перевіряйте час на підписувачах і авторитетах.
5. Документуйте runbook для ротації ключів і проводьте їх у робочі години, коли можливо.
6. Тримайте дефолтні EDNS буфери розумними; уникайте великих буферів, що провокують фрагментацію в інтернеті.
7. Припускайте, що буде NXDOMAIN-флуд; майте готові обмеження частоти та засоби протидії зловживанням.

Поширені питання (FAQ)

1) Чи NSEC3 обов’язковий для DNSSEC?

Ні. DNSSEC вимагає автентифікованого заперечення існування, але це може бути реалізовано через NSEC або NSEC3. Багато зон успішно працюють з NSEC.

2) Чи робить NSEC3 мою зону «приватною»?

Ні. Він ускладнює масовий перерахунок, але не цілеспрямоване виявлення. Якщо імена вгадувані — вони з’ясовуються.

3) Чому NXDOMAIN відповіді стають такими великими з DNSSEC?

Тому що сервер повинен включити доказ. Цей доказ містить записи заперечення (NSEC/NSEC3) і їхні підписи, а часто ще й SOA та його підпис. NSEC3-докази можуть включати кілька записів.

4) Чи варто підвищувати ітерації NSEC3 заради більшої безпеки?

Лише якщо у вас є чітка модель загроз, яка отримує від цього вигоду, і ви протестували вплив на підписування та обслуговування. Інакше тримайте консервативно або уникайте NSEC3.

5) Який найпростіший спосіб визначити, чи NSEC3 спричиняє проблеми продуктивності?

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

6) Якщо я перейду з NSEC3 на NSEC, чи зламаються валідатори?

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

7) Чи NSEC завжди швидший за NSEC3?

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

8) Що щодо NSEC3 opt-out — чи варто його використовувати?

Opt-out існує головно для зон з багатьма незахищеними делегаціями (як у деяких реєстрів), щоб зменшити кількість записів і операційний тягар.
Він також ускладнює семантику гарантій. Якщо ви не можете пояснити його дія аудитору і on-call, не використовуйте його без вагомої причини.

9) Наша команда безпеки хоче NSEC3, щоб «атакувальники не дізналися піддомени». Що їм сказати?

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

10) Яка найпоширеніша помилка DNSSEC, що виглядає як проблема продуктивності?

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

Висновок: що робити далі (практично, не духовно)

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

Наступні кроки, які приносять реальні результати:

1. Заміряйте поведінку NXDOMAIN у вашій зоні: розміри, затримки, частота TCP fallback і сигнали фрагментації.
2. Визначте, чи перерахунок справді проблема для вашої зони. Якщо імена вгадувані — вирішіть експозицію імен, а не лише докази заперечення.
3. Визначте UDP-бюджет і застосовуйте його як регресійний тест для змін DNS, особливо для змін DNSSEC.
4. Якщо використовуєте NSEC3, тримайте параметри консервативними і розділяйте зміну параметрів від ротацій ключів.
5. Операціоналізуйте валідацію: runbook-и, тестування з кількох точок і оповіщення про закінчення підписів та стрибки TCP.

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