Основи отруєння DNS-кешу: зміцніть резолвер без надмірностей

Що таке отруєння кешу насправді (і що ним не є)

«Отруєння DNS-кешу» — це коли рекурсивний резолвер зберігає фальшиву відповідь і віддає її клієнтам, доки вона не закінчиться (або не буде видалена).
Ключове слово — кеш. Атакуючому не потрібно ламати ваш авторитетний DNS-сервер, щоб завдати шкоди; йому достатньо,
щоб ваш резолвер повірив у брехню досить довго.

Це відрізняється від:

• захоплення на рівні реєстратора (хтось змінює NS-записи в реєстратора). Це не отруєння кешу; це компроміс облікового запису.
• підміни на шляху (MITM, що змінює відповіді DNS). Це мережна атака; кешування може її посилити, але корінь проблеми — перехоплення трафіку.
• помилкова конфігурація (неправильні A/AAAA записи, застарілі TTL, сюрпризи зі split-horizon). З вигляду клієнта це ідентично.
• шторм NXDOMAIN (багато негативних відповідей). Це не отруєння; але боляче.

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

Радіус ураження формується двома рішеннями, які ви контролюєте:

• Хто може робити запити до вашого резолвера? Якщо у вас відкритий резолвер, ви перетворюєте чужі проблеми на свої.
• Наскільки строго резолвер перевіряє відповіді? Валідація DNSSEC і розумні правила bailiwick (сфера відповідальності) роблять багато спроб отруєння марними.

Короткий жарт №1: DNS як офісні плітки: як тільки неправильна річ потрапляє в кеш, усі її повторюють з повною впевненістю.

Як працюють атаки: від вгадувань до стійкості

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

Складові, що роблять отруєння можливим

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

Але «важче» не означає «неможливо». Атакувальники шукають:

• NAT-пристрої, що колапсують порти (рандомізація портів нівелюється проміжними пристроями).
• сайд-канали, що витокують інформацію про порт чи ID.
• слабкі налаштування форвардера (форвардери, що приймають сміття або не перевіряють DNSSEC).
• помилково налаштовані резолвери, що приймають out-of-bailiwick додаткові записи (класичний вектор отруєння).
• довгі TTL, що роблять одну перемогу тривалою.

Чому «additional section» важлива (і чому bailiwick — серйозне слово)

Відповіді DNS можуть містити додаткові записи в секції «additional», наприклад glue A-записи для NS.
Резолвер має бути вибірковим щодо того, що він кешує звідти. Правило «bailiwick» — кешувати додаткові дані лише якщо вони в межах
повноважень сервера, що їх надав, і навіть тоді — обережно.

Отруєння часто намагається підсунути щось на кшталт:

• A-запис для www.victim.com у відповіді, яка не має бути авторитетною для цього імені.
• NS-запис, що спрямовує victim.com на контрольований нападником сервер імен, плюс glue для цього nameserver.

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

DNSSEC змінює правила гри — якщо ви справді валідируєте

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

Увімкнення валідації DNSSEC — як пристібнути ремінь безпеки. Це не робить вас невразливими, але альтернатива — сподіватися на добру фізику.

Цитата, бо операції — контактний вид спорту: «Сподівання — не стратегія». — Вінс Ломбарді.

Цікаві факти та історичний контекст (коротко й конкретно)

• DNS старший за веб: DNS стандартизований у 1980-х; HTTP з’явився пізніше. Модель загрози була «кампусна мережа», не «глобальний противник».
• 2008 рік став переломним: розкриття Дена Камінського показало практичне отруєння кешу в масштабі, що змусило масово патчити й рандомізувати.
• Рандомізація вихідних портів стала дефолтом після того часу, бо 16-бітні ID були вгадувані при достатній кількості спроб.
• «0x20 encoding» існує: деякі резолвери рандомізують регістр букв у запитах для додаткової ентропії; це хитро, але не заміна валідації.
• NAT може підривати безпеку: деякі старі NAT-пристрої переписували вихідні порти передбачувано, зменшуючи ентропію.
• Підписування DNSSEC задумували в 1990-х, але реальне розгортання зайняло роки через операційну складність і управління ключами.
• Коренева зона була підписана у 2010, що зробило end-to-end валідацію DNSSEC життєздатною без кастомних трюків довіри.
• Негативне кешування стандартизоване (SOA minimum / negative TTL). Воно важливе для масштабу й часто викликає питання «чому ще не резолвиться?».
• Резолвери — це потенційні DDoS-інструменти, коли відкриті: не отруєння, але пов’язано: відкрита рекурсія робить вашу інфраструктуру чужою зброєю.

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

Ви на виклику. Щось пахне як DNS. Не вирішуйте все одразу. Робіть це по порядку і зупиняйтесь, коли знайдете «димлячий кратер».

Спочатку: визначте, чи резолвер бреше, чи upstream змінюється

1. Запитайте свій резолвер і відомий зовнішній резолвер для одного й того ж імені та порівняйте відповідь і TTL.
2. Перевірте статус валідації DNSSEC (увімкнено чи ламається?).
3. Прослідкуйте делегацію (вас спрямовують на несподівані NS-сервери?).

По-друге: шукайте стійкість кешу та охоплення

1. Перевірте поведінку TTL: неправильна відповідь відраховується (кеш) чи коливається (upstream)?
2. Перевірте кілька клієнтів/субмереж: це один вузол резолвера, один сайт чи скрізь?
3. Перевірте, чи залучено форвардера: багато «резолверів» — це просто форвардери з додатковими кроками.

По-третє: підтвердіть, що це не самозавдане

1. Пошукайте в diff управління конфігами DNS-зміни (форвардери, views, ACL, перемикання DNSSEC).
2. Перевірте колізії split-horizon (внутрішня зона перекриває зовнішню).
3. Проінспектуйте поведінку NAT/файрволу, якщо підозрюєте оф-пат отруєння (перепис портів, таймаути UDP).

Мета: відокремити «отруєний кеш» від «авторитетна правда змінилася» від «ми самі щось зламали». Це три різні класи інцидентів.

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

Це навмисно практично. Запускайте команди на клієнтській машині й на хості резолвера. Порівнюйте виводи. Приймайте рішення.
Я використаю 10.0.0.53 як IP внутрішнього рекурсивного резолвера і resolver1 як його hostname.

Завдання 1 — Підтвердити, яким резолвером насправді користується хост

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54

Що це означає: Цей хост відправляє DNS на 10.0.0.53 (первинний) і 10.0.0.54 (вторинний).
DNSSEC тут стосується stub-резолвера і може показувати «unsupported», навіть якщо рекурсія валідує з боку upstream.

Рішення: Якщо «Current DNS Server» не ваш бажаний резолвер, зупиніться й виправте налаштування DHCP/systemd-resolved.
Дебаг отруєння на не тій машині — шлях до звинувачення місяця.

Завдання 2 — Порівняти відповідь вашого резолвера з відомим зовнішнім джерелом

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  296  IN  A  203.0.113.50

cr0x@server:~$ dig @1.1.1.1 www.example.com A +noall +answer +ttlid
www.example.com.  300  IN  A  93.184.216.34

Що це означає: Ваш резолвер повертає іншу IP-адресу, ніж публічний резолвер. Це або отруєння, split-horizon, або розбіжність upstream.

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

Завдання 3 — Перевірити, чи неправильна відповідь кешується (TTL відраховується)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  296  IN  A  203.0.113.50

cr0x@server:~$ sleep 5; dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  291  IN  A  203.0.113.50

Що це означає: Зменшення TTL вказує, що резолвер віддає відповідь із кешу.

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

Завдання 4 — Прослідкувати делегацію, щоб побачити, звідки приходять відповіді

cr0x@server:~$ dig +trace www.example.com A
; <<>> DiG 9.18.24 <<>> +trace www.example.com A
;; global options: +cmd
.                       3600    IN      NS      a.root-servers.net.
...
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
www.example.com.        300     IN      A       93.184.216.34

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

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

Завдання 5 — Запитати у відповіді статус валідації DNSSEC

cr0x@server:~$ dig @10.0.0.53 www.example.com A +dnssec +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42012
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.com.  300  IN  A  93.184.216.34

Що це означає: Ви не бачите прапора ad (Authenticated Data). Це може означати, що валідація DNSSEC вимкнена, не підтримується для цього імені або ваш резолвер не є валідуючим.

Рішення: Якщо ви очікуєте валідацію — підтвердіть це на резолвері. Якщо ні — вирішіть, чи це прийнятно у 2025 році (зазвичай ні).

Завдання 6 — В Unbound перевірити, чи DNSSEC увімкнено й працює

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 2
modules: 2 [subnetcache validator]
uptime: 18432 seconds
options: reuseport control(ssl)

Що це означає: Список модулів включає validator, що добре — DNSSEC валідація скомпільована і активна.

Рішення: Якщо ви не бачите validator, ви не валідуєте. Виправте конфігурацію, перш ніж сперечатися про отруєння.

Завдання 7 — В BIND9 підтвердити рекурсію й хто має до неї доступ

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,120p'
options {
        recursion yes;
        allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };
        allow-query-cache { 10.0.0.0/8; 192.168.0.0/16; };
        dnssec-validation auto;
        minimal-responses yes;
        ...
};

Що це означає: Рекурсія увімкнена (ок), але обмежена внутрішніми мережами (також ок). dnssec-validation auto; — звичайний безпечний дефолт.

Рішення: Якщо allow-recursion = any; або відсутній — це проблема безпеки. Відкрита рекурсія запрошує до зловживань і збільшує вашу експозицію.

Завдання 8 — Перевірити патерни SERVFAIL (часто DNSSEC або upstream проблеми)

cr0x@server:~$ dig @10.0.0.53 badsig.example A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61457
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: SERVFAIL може означати помилку валідації, таймаут або проблему upstream. Якщо корелює з DNSSEC-зонами, найчастіше це валідація.

Рішення: Перевірте логи резолвера на помилки DNSSEC; не вимикайте валідацію просто щоб «полагодити» продакшен. Це як вирішити проблему сигналізації диму, вийнявши батарейки.

Завдання 9 — Переконатися, що резолвер не форвардить до ненадійного або зламаного upstream

cr0x@server:~$ sudo ss -uapn | grep -E ':(53)\b'
UNCONN 0      0         10.0.0.53:53         0.0.0.0:*    users:(("unbound",pid=1187,fd=6))
UNCONN 0      0         10.0.0.53:49322      8.8.8.8:53   users:(("unbound",pid=1187,fd=9))
UNCONN 0      0         10.0.0.53:42617      1.1.1.1:53   users:(("unbound",pid=1187,fd=10))

Що це означає: Цей резолвер робить вихідні UDP/53 запити до публічних резолверів. Це дизайн форвардингу, а не повної рекурсії.

Рішення: Вирішіть, чи форвардинг навмисний. Якщо форвардите, ви успадковуєте поведінку upstream і втрачаєте можливість повноцінної end-to-end валідації та діагностики.

Завдання 10 — Інспектувати поведінку NAT, що може зменшувати ентропію портів

cr0x@server:~$ sudo conntrack -L -p udp --dport 53 2>/dev/null | head
udp      17 25 src=10.0.0.53 dst=1.1.1.1 sport=42617 dport=53 src=1.1.1.1 dst=203.0.113.10 sport=53 dport=42617 [ASSURED]
udp      17 25 src=10.0.0.53 dst=8.8.8.8 sport=49322 dport=53 src=8.8.8.8 dst=203.0.113.10 sport=53 dport=49322 [ASSURED]

Що це означає: Ви бачите UDP-потоки і вихідні порти. Якщо ви багаторазово спостерігаєте послідовні або повторювані порти через NAT, ви втрачаєте ентропію.

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

Завдання 11 — Перевірити статистику Unbound на наявність аномалій кешу

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'num.cachehits|num.cachemiss|num.query|unwanted|cache'
num.query=1842099
num.cachehits=1320091
num.cachemiss=522008
unwanted.queries=183
unwanted.replies=91
msg.cache.count=76231
rrset.cache.count=54012

Що це означає: Високий відсоток cache hits — нормально. Зростання unwanted.replies може вказувати на те, що приходять підроблені відповіді, які не відповідають очікуваним запитам.

Рішення: Якщо unwanted.replies стрибкають — розслідуйте мережеві підробки або зламані upstream-пристрої. Це не доказ отруєння, але підказка, яку варто дослідити.

Завдання 12 — Захопити трафік DNS, щоб підтвердити, що на дроті

cr0x@server:~$ sudo tcpdump -ni any udp port 53 -vv -c 5
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
IP 10.0.0.53.42617 > 1.1.1.1.53: 42012+ A? www.example.com. (33)
IP 1.1.1.1.53 > 10.0.0.53.42617: 42012* 1/0/1 A 93.184.216.34 (49)
IP 10.0.0.53.49322 > 8.8.8.8.53: 1337+ DS? example.com. (29)
IP 8.8.8.8.53 > 10.0.0.53.49322: 1337 1/0/1 DS 370 13 2 49AAC11D... (68)
IP 203.0.113.66.53 > 10.0.0.53.42617: 42012 1/0/0 A 203.0.113.50 (49)

Що це означає: Третя сторона 203.0.113.66 присилає відповідь, що співпадає з ідентифікатором транзакції й портом для відкритого запиту.
Якщо ця IP не ваш upstream і вона приходить раніше за реальну — у вас серйозна проблема: підробка відбувається на шляху або через помилку маршрутизації/ACL.

Рішення: Ескалюйте негайно: мережна команда для ACL/маршрутизації, команда безпеки для інцидент-респонсу, і ізолюйте резолвер, якщо можете.

Завдання 13 — Перевірити BIND логи запитів на несподіваних клієнтів та зловживання рекурсією

cr0x@server:~$ sudo rndc querylog
query logging is now on

cr0x@server:~$ sudo tail -n 5 /var/log/named/named.log
client @0x7f3c9c0a: query: randomstring.badness.example IN A +E(0)K (198.51.100.77)
client @0x7f3c9c0a: query: www.example.com IN A +E(0)K (10.10.14.22)
client @0x7f3c9c0a: query: api.internal.corp IN A +E(0)K (10.20.1.9)

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

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

Завдання 14 — Перевірити, чи не витікають внутрішні зони назовні (views/split horizon)

cr0x@server:~$ dig @10.0.0.53 api.internal.corp A +noall +answer
api.internal.corp.  60  IN  A  10.55.0.21

cr0x@server:~$ dig @1.1.1.1 api.internal.corp A +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11610

Що це означає: Внутрішнє ім’я існує лише внутрішньо. Добре. Але якщо зовнішній резолвер повертає щось — у вас колізія або витік.

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

Завдання 15 — Перевірити, чи відкидає резолвер out-of-bailiwick сміття (тест на сталість)

cr0x@server:~$ dig @10.0.0.53 ns1.example.com A +noall +authority +additional
example.com.     172800  IN  NS  a.iana-servers.net.
example.com.     172800  IN  NS  b.iana-servers.net.
a.iana-servers.net.  172800 IN A  199.43.135.53
b.iana-servers.net.  172800 IN A  199.43.133.53

Що це означає: Додаткова секція містить glue-записи для nameserver-ів. Це очікувано й є in-bailiwick glue для ланцюжка делегації.

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

Зміцнення резолвера, що дає результат

Зміцнення резолверів — це в основному мислення «deny by default» і зменшення неоднозначностей. Ви не намагаєтеся бути хитрими.
Ви намагаєтеся бути нудними, правильними й стійкими до нападників і до «малих покращень» колег.

1) Перестаньте запускати відкриту рекурсію (серйозно)

Обмежте, хто може робити запити і хто може виконувати рекурсію. Це дві різні ACL. Налаштуйте обидві правильно.
Якщо у вас відкритий резолвер, ви приваблюєте зловживання, створюєте плутані патерни трафіку і підвищуєте шанс, що підроблені пакети потраплять у ваш кеш.

• BIND: встановіть allow-recursion і allow-query-cache лише для внутрішніх мереж.
• Unbound: налаштуйте access-control для дозволених підмереж; відхиляйте все інше.

2) Увімкніть валідацію DNSSEC і не ставте її як опціон

Валідація DNSSEC — найефективніший захист від отруєння для підписаних зон. Вона перетворює «можливо» на «ні».
Так, це додає нові режими відмов (протерміновані підписи, зламані DS). Це нормально. Ми вміємо їх моніторити.

Чого не слід робити: вимикати DNSSEC під час збою й забути знову увімкнути. Так ви перейдете від «тимчасової нестабільності»
до «мовчазного компромісу».

3) Оновлюйте софт резолвера

Безпека резолверів змінюється: виправлення bailiwick, краща рандомізація, загартоване парсування, покращення QNAME мінімізації
і захисти від нових сайд-каналів. Старі версії накопичують гострі кути. Ви будете кровоточити.

4) Зберігайте ентропію end-to-end (порти, ID і мережа між ними)

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

5) Віддавайте перевагу повній рекурсії над сліпим форвардінгом (коли можете)

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

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

6) Увімкніть QNAME мінімізацію

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

7) Використовуйте rate limiting для стабільності, а не як чарівну безпекову таблетку

Rate limiting допомагає проти флуда і деяких брутфорс-патернів. Воно не «вирішить отруєння».
Але воно може зберегти резолвер живим достатньо довго, щоб ви відреагували, і зменшити ампліфікаційний потенціал.

8) Логуйте з наміром: стільки, щоб розслідувати, але не втопити системи

Щоденні логи запитів дорого коштують і шумлять. Використовуйте семплінг або тимчасові перемикання (rndc querylog, підвищення verbosity в Unbound),
а структуровані метрики тримайте завжди: відсоток cache hit, рівні SERVFAIL, unwanted replies, топ QNAME за об’ємом.

9) Зафіксуйте внутрішні зони й уникайте колізій

Split-horizon часто необхідний. Але це також зона, де виникає помилкова поведінка схожа на «отруєння»: різні відповіді за джерелом,
неправильні views, внутрішні зони, що затуляють публічні домени. Використовуйте чіткі суфікси, тестуйте зовні та автоматизуйте перевірки.

10) Вирішіть щодо EDNS, cookies і TCP fallback

EDNS збільшує розмір повідомлень DNS і можливості. Це добре, але взаємодіє з MTU, фрагментацією і middlebox-ами.
EDNS Cookies можуть додати стійкості проти підроблених відповідей у деяких сценаріях, але підтримка різна.
Переконайтеся, що TCP fallback працює: деякі атаки й відмови опираються на UDP-асумпції.

Короткий жарт №2: Щоразу, коли хтось каже «DNS простий», резолвер роняє фрагментований UDP-пакет і тихо будує помсту.

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

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

Компанія запускала два рекурсивні резолвери на сайті. В проєктній документації було «anycast», але реалізація була «два IP в DHCP».
Інженер припустив, що клієнти плавно перейдуть на інший резолвер, якщо один стане нездоровим.

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

Хибне припущення: команда вважала, що вторинний резолвер сховає проблеми первинного. Насправді більшість стеків клієнтів тримаються за перший сервер,
якщо він не відвалюється. Резолвер, що відповідає швидко — але неправильно — не викликає failover. Він стає авторитетним джерелом брехні для цієї групи клієнтів.

Виправлення не було героїчним. Вони перестали вважати «два IP» як високу доступність. Додали health checks резолверів, видаляли хворі вузли з DHCP-пулу,
стандартизували процедури очищення кешу. Найважливіше — збудували невеликий синтетичний чек, що порівнював відповіді з кожного резолвера проти зовнішнього trace.

Висновок постмортему був різким: «швидкі неправильні відповіді гірші за таймаути». Це стало вимогою дизайну, а не уроком.

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

Інша організація мала скарги на затримки з віддалених офісів. Хтось запропонував оптимізацію: форвардити весь DNS на пару центральних резолверів,
бо «кеші будуть лучше». Технічно — вірно. Операційно — пастка.

Форвард зробили по VPN. Об’єм запитів був ок, але EDNS-відповіді почали фрагментуватися, а шлях VPN мав нижчий ефективний MTU.
Частина фрагментів губилася. Деякі домени почали періодично падати з SERVFAIL або довго затримуватись через логіку ретраїв і TCP fallback.

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

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

Підсумок: кешування — не привід створювати єдину точку дивності. Особливо для DNS.

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

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

У третіх осіб SaaS-домен почав резолвитися на несподіваний IP для підмножини мереж. Публічні резолвери не погоджувалися між собою.
Валідуючі резолвери компанії повертали SERVFAIL для деяких відповідей і правильні відповіді для інших. Це виглядало як DNS-аутейдж для команд додатків.

Оскільки були метрики, SRE помітили зростання помилок валідації і «unwanted replies». Захоплення пакетів показало підроблені відповіді, що приходили швидше за легітимні на шляху одного провайдера.
Валідація DNSSEC відкидала підроблені дані. Наслідок — деградована резолюція (таймаути й ретраї), але не таємне перенаправлення користувачів до нападника.

Вони тимчасово перенаправили egress резолверів через іншого провайдера, зберігши валідацію увімкненою. Сервіс стабілізувався.
Пізніше ISP визнав проблему, сумісну з інтерференцією трафіку. Компанії не довелося казати клієнтам «можливо, ми вас відправляли не туди».

Нудна практика була не просто «DNSSEC увімкнено». Це було «DNSSEC увімкнено, моніториться й важко відключається». Нудно — добре. Нудно масштабується.

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

1) Симптом: Деякі користувачі потрапляють на неправильний IP, інші в порядку

Причина: Один вузол резолвера має отруєний/застарілий кеш, або клієнти прив’язані до першого DNS-сервера.

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

2) Симптом: Неправильна відповідь тримається години після «виправлення DNS»

Причина: Довгий TTL у кеші рекурсивних резолверів; негативне кешування; кешування у проміжних форвардерах; або додатки кешують DNS локально.

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

3) Симптом: Раптовий сплеск SERVFAIL для популярних доменів

Причина: Помилки валідації DNSSEC (зламаний DS-ланцюжок, прострочені підписи) або таймаути/фрагментація upstream.

Виправлення: Перевірте логи на помилки валідації; підтвердіть EDNS/MTU-шлях; переконайтеся в TCP fallback; не вимикайте валідацію без чіткого плану.

4) Симптом: CPU резолвера в порядку, але клієнти бачать таймаути

Причина: Втрата пакетів, файрвол відкидає фрагменти, таймаути стану UDP; інколи conntrack вичерпується.

Виправлення: tcpdump на резолвері; перевірте conntrack; дозвольте DNS TCP/53; налаштуйте EDNS buffer або path MTU; виправте мережеві ACL.

5) Симптом: Публічні IP з’являються в логах резолвера як клієнти

Причина: Відкрита рекурсія, що доступна з інтернету, або неправильне маршрутизування VPN; інколи помилка у cloud security group.

Виправлення: Закрийте рекурсію ACL; блокуйте UDP/TCP 53; перевірте cloud SG/NACL; переконайтеся, що ви не рекламували IP резолвера випадково.

6) Симптом: Резолвер повертає «правильний» A-запис, але TLS падає через невідповідність сертифіката

Причина: DNS-відповідь вказує на неправильний хост (отруєння або split-horizon), або CDN змінює edge і ваші припущення щодо пінінгу застаріли.

Виправлення: Порівняйте з +trace і кількома резолверами; перевірте, чи ви не перекриваєте зону внутрішньо; перевірте авторитетні записи.

7) Симптом: Проблеми лише з великими відповідями (TXT, DNSKEY, деякі HTTPS/SVCB)

Причина: EDNS-фрагментація відвалюється; проблеми path MTU; зламані middlebox-и; блокований TCP.

Виправлення: Переконайтеся, що TCP/53 працює end-to-end; налаштуйте EDNS buffer; віддавайте перевагу сучасним версіям резолверів з розумними дефолтами.

8) Симптом: Сплеск запитів на випадкові субдомени (наприклад, a1b2c3.example.com)

Причина: Спроба обійти кеш, DDoS або малварний біконинг; також може бути некоректний сервіс-дискавері.

Виправлення: Використовуйте RPZ або локальну політику для блокування шкідливих патернів; впровадьте rate limiting; ідентифікуйте джерела IP; координуйтеся з командою безпеки.

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

Фаза 1 — Оцінити основу безпеки резолвера (1–2 дні)

1. Інвентарізуйте резолвери: IP-адреси, версії, чи вони рекурсивні або форвардять, і куди йде їх egress.
2. Підтвердіть ACL рекурсії: лише внутрішні мережі можуть виконувати рекурсію; інші отримують відмову.
3. Увімкніть валідацію DNSSEC: валідируйте на резолвері, а не тільки на клієнтах.
4. Переконайтесь, що TCP/53 дозволено: як inbound від клієнтів (якщо потрібно), так і outbound від резолвера.
5. Підтвердіть, що рандомізація портів переживає NAT: перевірте conntrack/flows; виправте передбачувані відображення.
6. Увімкніть метрики: відсоток cache hit, SERVFAIL, NXDOMAIN, unwanted replies, гістограми латентності.

Фаза 2 — Додайте запобіжні механізми, що запобігають «тимчасовій» небезпеці (1–2 тижні)

1. Конфіг як код: резолвери керуються через нормальний pipeline, а не ручними SSH-правками.
2. Контроль змін для перемикань DNSSEC: будь-яке відключення вимагає терміну і відповідальної особи.
3. Синтетичні перевірки для кожного вузла: порівнюйте з +trace для невеликого набору доменів; сигналізуйте про розбіжності.
4. Короткочасний перемикач логування запитів: операційний playbook для вмикання логів на 15 хвилин з безпечним зберіганням.

Фаза 3 — Зміцнення без надмірностей (постійно)

1. Надавайте перевагу повній рекурсії, якщо політика не примушує форвардити. Якщо форвардите — документуйте довіру і моніторте upstream.
2. Мінімізуйте складність split-horizon: тримайте внутрішні зони малими й зрозумілими; уникайте накладання публічних доменів.
3. Каденція патчів: вважайте оновлення резолверів як оновлення безпеки, бо так і є.
4. Тренування на столі: симулюйте «неправильну DNS-відповідь» і «відмову валідації DNSSEC» та відпрацюйте відповіді.

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

1) Чи існує отруєння DNS-кешу у 2025 році?

Так, але прості версії майже вимерли на сучасних резолверах з гарною рандомізацією і правилами bailiwick.
Залишковий ризик — це помилки конфігурації, довіра при форвардінгу, втрата ентропії через NAT, підміна на шляху та «вимкнена валідація».

2) Якщо я використовую DoH/DoT, чи я в безпеці від отруєння кешу?

DoH/DoT захищає шлях клієнт→резолвер від підміни на шляху. Але це не автоматично DNSSEC-валідація, і це не захищає, якщо сам резолвер скомпрометований або неправильно налаштований.
Це покращення транспорту, а не джерело істини.

3) Який єдиний крок зміцнення найефективніший?

Увімкніть валідацію DNSSEC на рекурсивному резолвері і тримайте її увімкнутою. Потім обмежте рекурсію лише внутрішнім клієнтам.
Ці дві зміни прибирають цілі класи проблем.

4) Чому мій резолвер повертає SERVFAIL, коли публічні резолвери повертають IP?

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

5) Як відрізнити отруєння від split-horizon DNS?

Split-horizon зазвичай стабільний залежно від джерела мережі й конфігурованих зон. Отруєння часто показує розбіжності між резолверами,
несподівані зміни делегацій і аномалії на кшталт unwanted replies. Використовуйте +trace та порівнюйте внутрішні й зовнішні відповіді.

6) Чи слід очищувати кеші під час підозри на отруєння?

Іноді так — після того, як ви зафіксували докази. Очищення може знищити докази (tcpdump, логи, кешовані RRset).
Якщо ви спочатку очистите, а потім почнете розслідування, ваш постмортем буде творчим оповіданням.

7) Чи завжди довгі TTL погані?

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

8) Чи вирішує проблему запуск кількох резолверів?

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

9) Що щодо «0x20 encoding» і інших трюків для ентропії?

Вони можуть допомогти в специфічних випадках, але не є основним захистом. Розглядайте їх як приправу, а не як головну страву.
DNSSEC-валідація, правильна рандомізація й ACL — це головне.

10) Як уникнути надмірної інженерії?

Не будуйте кастомну платформу безпеки для DNS. Запускайте сучасний резолвер (Unbound або BIND), валідируйте DNSSEC, закрийте рекурсію,
моніторьте ключові метрики й тренуйтеся в реагуванні на інциденти. Більшість команд помиляються у базі, а не через відсутність екзотичних фіч.

Висновок: практичні подальші кроки

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

1. Цього тижня: перевірте ACL рекурсії, підтвердіть, що валідація DNSSEC увімкнена, і виконайте «порівняння із зовнішнім» для ваших ключових доменів.
2. Наступного тижня: додайте синтетичний моніторинг для кожного резолвера на розбіжності відповідей і помилки валідації; зробіть «відключення DNSSEC» контролюваною зміною з терміном.
3. Цього кварталу: модернізуйте версії резолверів, проведіть аудит NAT/egress на предмет втрати ентропії і спростіть split-horizon зони.

Якщо ви зробите тільки одну річ: припиніть вважати «швидкі неправильні відповіді» за здоров’я. DNS — це інфраструктура. Ставтесь до неї серйозно, бо все інше від неї залежить.